critical-review
Skill4 starsChanged 28 days agoMITView on GitHub
Delivers structured, adversarial feedback on a plan or design document, surfacing risks and gaps before implementation. Use when the user wants a plan or document reviewed.
5 other projects use a version of this.
Adopted by
Most recently taken up by
- JigneshAmmineni/agentic-engineering-workflowtheir own version, first seen Oct 25, 2026
- mido-99/Skillstheir own version, first seen Oct 15, 2026
- madebywild/agent-harnesstheir own version, first seen Oct 8, 2026
- yeisonrestrepo/code-conductortheir own version, first seen Oct 6, 2026
- parsoFish/skillstheir own version, first seen Sep 12, 2026
Other versions5 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 5
- yeisonrestrepo/code-conductor★ 17same name
- madebywild/agent-harness★ 16same name
- parsoFish/skills★ 1same name
- JigneshAmmineni/agentic-engineering-workflow★ 0same name
- mido-99/Skills★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository5 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- code-reviewSkill
- implement-batchSkill
- saveSkill
- security-auditSkill
The file
We split this skill into the rules it gives an agent
6 rules. 0 are common, 6 are distinctive, and 0 are very specific to this project.
0
Common
Most of the 5 edited versions we read keep these.
6
Distinctive
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 36
After all subagents complete, synthesize in the main session:
- Distinctive: line 39
If a subagent returned zero findings, note that to the user
- Distinctive: line 42
If the user approves incorporating feedback: the main session (not a subagent) updates the plan document with a new revision and notes what …
- Distinctive: line 54
Iterate until clean: After applying fixes, automatically start the next round:
- Distinctive: line 63
When the stop condition is met, inform the user the review is complete and the plan is ready for implementation.
- Distinctive: line 65
If the user does not approve changes at any point, present the findings as a reference, log the rejections (step 5), and end.
“Common” is measured: kept by at least 6 in 10 of the 5 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Critical Review
This skill must only be invoked from the main session, never from a subagent.
- Identify the target document:
a. If the user specified a file path or plan name, use that.
b. Else determine the project name: check
origingit remote (parse last path component, strip.git) → git root basename → working directory basename. If ambiguous, ask the user. c. List files in~/.claude/plans/<project-name>/, sorted by modification time (most recent first). If the directory does not exist or contains no.mdfiles, tell the user: "No plan files found in~/.claude/plans/<project-name>/. Please specify a file path to review." and stop. d. Confirm with the user: "I'll review<filename>. Correct?" Round 1 — Spawn 4 parallel subagents (all four on the latest, most capable model — omit the
modeloverride so each inherits the session model rather than pinning a version-specific name; plan adjudication is precision work where a weaker model's false positives cost more verification time than the savings, so don't downgrade to a cheaper tier;CLAUDE_CODE_SUBAGENT_MODELoverrides if set):- Agent 1 — Correctness & Logic: Logic errors, wrong assumptions, API misuse, spec violations, contradictions within the plan.
- Agent 2 — Edge Cases & Robustness: Boundary conditions, empty/malformed inputs, error handling gaps, crash scenarios, encoding/Unicode issues.
- Agent 3 — Feasibility & Performance: Over-engineering, unrealistic scope, dependency risks, library limitations, performance concerns, scaling issues.
- Agent 4 — Testing & Completeness: Coverage gaps, untested paths, missing integration tests, weak assertions, unaddressed requirements.
Each subagent's prompt MUST include these instructions verbatim:
Read the target plan document. Read at most 5 source files directly relevant to your review — prefer files explicitly named in the plan. Do NOT read the entire codebase.
Return findings as a numbered list, max 10 items, highest severity first. Each item must have exactly these fields:
- Severity: critical | major | minor
- Location: file path and section/function name
- Issue: one-sentence description
- Fix: one-sentence suggested fix
Return NO other text, except: if you encounter tool errors or cannot read required files, report that as your first finding with severity "critical" and location "tooling".
- After all subagents complete, synthesize in the main session:
- Deduplicate overlapping findings
- Prioritize by severity
- If a subagent returned zero findings, note that to the user
- Present a consolidated list to the user
- If the user approves incorporating feedback: the main session (not a subagent) updates the plan document with a new revision and notes what changed.
- Decision logging (runs after every user response — approval, rejection, or deferral):
Append each decision to
~/.claude/plans/<project-name>/decision-log.md. Create the file if it doesn't exist. Append-only — never overwrite existing entries. Format per entry:## YYYY-MM-DD — [Plan filename] - **Finding:** [1-sentence summary] - **Decision:** accepted / rejected / deferred - **Rationale:** [why — from the user's response or the discussion] - **Alternatives considered:** [if any were discussed] - Iterate until clean. After applying fixes, automatically start the next round:
- Spawn 2 parallel subagents that review ONLY the sections changed in the latest revision, both on the latest, most capable model (omit the
modeloverride so they inherit the session model; fix verification is high-stakes — don't downgrade to a cheaper tier;CLAUDE_CODE_SUBAGENT_MODELoverrides if set):- Agent A — Correctness, Logic & Edge Cases
- Agent B — Feasibility, Testing & Completeness
- Each subagent's prompt MUST include the same verbatim format template from step 2, modified to say: "Review ONLY the following changed sections: [list sections]. Read at most 3 source files relevant to the changes. Max 5 items."
- Synthesize, present to user, apply approved fixes, increment revision.
- Stop condition: a round produces 0 critical and 0 major findings. Minor-only findings do not block — note them and declare the plan ready.
- Safety valve: max 7 total rounds (1 initial + 6 follow-ups). If critical/major issues persist after 7 rounds, STOP — report what keeps recurring and flag to the user that the plan may need structural rework rather than incremental fixes.
- Spawn 2 parallel subagents that review ONLY the sections changed in the latest revision, both on the latest, most capable model (omit the
- When the stop condition is met, inform the user the review is complete and the plan is ready for implementation. Do not begin implementation unless the user explicitly requests it.
- If the user does not approve changes at any point, present the findings as a reference, log the rejections (step 5), and end. Do not modify any files.
Output Contract
The final synthesized report MUST include all of the following:
- Document reviewed: path to the plan or document
- Findings table: each finding with severity, location, issue, and fix
- Aggregate counts: total findings broken down by severity (critical/major/minor)
- Verdict: one of
clean(0 critical, 0 major) orneeds-revision(1+ critical or major) - Change summary (conditional): include only when revisions were applied; omit when user declines changes
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

