How do I install the Fagan Inspection skill?

Run npx skillmds@latest add 45ck/fagan-inspection in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Fagan Inspection safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Fagan Inspection?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Fagan Inspection free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Fagan Inspection?

45ck (@45ck) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Fagan Inspection by 45ck — Agent Skill

Name: Fagan Inspection
Author: 45ck

Fagan Inspection

Formal defect-finding inspection of the current change set using Fagan steps. Use when the user asks for a Fagan inspection, deep review, code review, defect review, regression review, or a structured findings-first assessment of a diff, branch, staged changes, PR, or working tree. Uses parallel domain reviewers when supported and outputs a consolidated defect log plus verification.

45ck f6f62b5 2 files · 3.3 KB Updated Sep 17, 2026

File contents

Run a formal Fagan Inspection on the current change set. Optimize for defect discovery and verification.

Operating rules

Default to review mode, not implementation mode. Do not edit code unless the user explicitly asks for rework after the inspection.
Prefer findings about bugs, regressions, missing tests, design risks, and operational hazards over summaries.
When subagents are available, use them only for independent domain reviews. Keep scope selection, synthesis, severity decisions, and final reporting local.
Keep commands non-interactive. Prefer fast local discovery (rg, targeted file reads, tests relevant to changed files).

A) Scope

Prefer existing chat context for intent + acceptance criteria.
If missing, derive scope from git: status, staged/unstaged diff, and PR-range diff vs base (origin/main or origin/master).
Summarize impacted modules/files + externally visible behavior changes.

B) Plan (you decide domains dynamically)

Define Entry Criteria (must be true to start) and Exit Criteria (must be true to finish).
Choose only the reviewer domains needed for this change (examples: correctness, security, performance, reliability, API/design, tests, docs, ops, data/migrations, concurrency, UI).
If parallel subagents are supported, spawn one reviewer per independent domain; otherwise run domains sequentially.
Keep at most one reviewer per file cluster or concern area to avoid duplicated work.

C) Preparation (domain reviews)

Each domain reviewer outputs defects in this schema:

Title
Severity: MAJOR | MINOR
Domain
Location: file:line or symbol
What/Why + Evidence/Repro
Fix: specific change
Verify: test/command/scenario

D) Inspection meeting (synthesis)

De-duplicate, re-severity, prioritize.
Produce a single defect log + rework plan.
Reject weak findings that lack a concrete failure mode, evidence path, or actionable fix.

E) Rework + follow-up

Only change code if permissions/approval mode allows; otherwise give patch-level edits.
Fix MAJOR first; add/update tests/docs for behavior changes; re-run relevant checks/tests; confirm Exit Criteria.

OUTPUT: Fagan Inspection Report (Markdown)

Findings first, ordered by severity, with file references and concise evidence.
Scope & intent source (chat or git)
Entry/Exit criteria
Overview + top risks
Defect log (table: ID | Sev | Domain | Location | Title | Status | Fix/Next)
Rework summary (if applied)
Verification evidence (commands/tests)

If no defects are found, say that explicitly and list residual risks or testing gaps.

---name: fagan-inspectiondescription: Formal defect-finding inspection of the current change set using Fagan steps. Use when the user asks for a Fagan inspection, deep review, code review, defect review, regression review, or a structured findings-first assessment of a diff, branch, staged changes, PR, or working tree. Uses parallel domain reviewers when supported and outputs a consolidated defect log plus verification.---Run a formal **Fagan Inspection** on the current change set. Optimize for defect discovery and verification.## Operating rules- Default to review mode, not implementation mode. Do not edit code unless the user explicitly asks for rework after the inspection.- Prefer findings about bugs, regressions, missing tests, design risks, and operational hazards over summaries.- When subagents are available, use them only for independent domain reviews. Keep scope selection, synthesis, severity decisions, and final reporting local.- Keep commands non-interactive. Prefer fast local discovery (`rg`, targeted file reads, tests relevant to changed files).## A) Scope- Prefer existing chat context for intent + acceptance criteria.- If missing, derive scope from git: status, staged/unstaged diff, and PR-range diff vs base (`origin/main` or `origin/master`).- Summarize impacted modules/files + externally visible behavior changes.## B) Plan (you decide domains dynamically)- Define **Entry Criteria** (must be true to start) and **Exit Criteria** (must be true to finish).- Choose only the reviewer domains needed for this change (examples: correctness, security, performance, reliability, API/design, tests, docs, ops, data/migrations, concurrency, UI).- If parallel subagents are supported, spawn one reviewer per independent domain; otherwise run domains sequentially.- Keep at most one reviewer per file cluster or concern area to avoid duplicated work.## C) Preparation (domain reviews)Each domain reviewer outputs defects in this schema:- **Title**- **Severity:** MAJOR | MINOR- **Domain**- **Location:** file:line or symbol- **What/Why + Evidence/Repro**- **Fix:** specific change- **Verify:** test/command/scenario## D) Inspection meeting (synthesis)- De-duplicate, re-severity, prioritize.- Produce a single defect log + rework plan.- Reject weak findings that lack a concrete failure mode, evidence path, or actionable fix.## E) Rework + follow-up- Only change code if permissions/approval mode allows; otherwise give patch-level edits.- Fix MAJOR first; add/update tests/docs for behavior changes; re-run relevant checks/tests; confirm Exit Criteria.## OUTPUT: Fagan Inspection Report (Markdown)1. Findings first, ordered by severity, with file references and concise evidence.2. Scope & intent source (chat or git)3. Entry/Exit criteria4. Overview + top risks5. Defect log (table: ID | Sev | Domain | Location | Title | Status | Fix/Next)6. Rework summary (if applied)7. Verification evidence (commands/tests)If no defects are found, say that explicitly and list residual risks or testing gaps.

Frequently asked questions