agentleFS
kimon1230kimon1230/claude_extensions/skills/critical-review/SKILL.md

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

  • Other versions5 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 5

    1. yeisonrestrepo/code-conductor★ 17same name
    2. madebywild/agent-harness★ 16same name
    3. parsoFish/skills★ 1same name
    4. JigneshAmmineni/agentic-engineering-workflow★ 0same name
    5. 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.

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
  1. Distinctive:

    After all subagents complete, synthesize in the main session:

    line 36
  2. Distinctive:

    If a subagent returned zero findings, note that to the user

    line 39
  3. Distinctive:

    If the user approves incorporating feedback: the main session (not a subagent) updates the plan document with a new revision and notes what …

    line 42
  4. Distinctive:

    Iterate until clean: After applying fixes, automatically start the next round:

    line 54
  5. Distinctive:

    When the stop condition is met, inform the user the review is complete and the plan is ready for implementation.

    line 63
  6. Distinctive:

    If the user does not approve changes at any point, present the findings as a reference, log the rejections (step 5), and end.

    line 65

“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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Critical Review

This skill must only be invoked from the main session, never from a subagent.

  1. Identify the target document: a. If the user specified a file path or plan name, use that. b. Else determine the project name: check origin git 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 .md files, 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?"
  2. Round 1 — Spawn 4 parallel subagents (all four on the latest, most capable model — omit the model override 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_MODEL overrides 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".

  3. 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
  4. If the user approves incorporating feedback: the main session (not a subagent) updates the plan document with a new revision and notes what changed.
  5. 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]
  6. 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 model override so they inherit the session model; fix verification is high-stakes — don't downgrade to a cheaper tier; CLAUDE_CODE_SUBAGENT_MODEL overrides 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.
  7. 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.
  8. 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) or needs-revision (1+ critical or major)
  • Change summary (conditional): include only when revisions were applied; omit when user declines changes

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.