| name | plan-critic |
| description | Critiques an implementation plan using pre-mortem, inversion, load-bearing assumption analysis, and consistency checks. Invoked as /plan-critic for ad-hoc plan critique, or used by the plan-critic sub-agent in the /feature workflow.
|
/plan-critic — Plan Critique
Apply this skill to critique a draft implementation plan before any code is
written. The goal is to find weaknesses in the plan itself, not to rewrite
it. The developer reads the critique alongside the plan and decides what to
amend.
Stance
Plans are load-bearing. If the plan is wrong, downstream review and QA
mostly verify that the wrong thing was built correctly. Your job is to
attack the plan before it becomes commitment.
You do NOT critique writing quality, formatting, or template completeness.
You critique whether the plan, as written, will produce a good outcome.
Inputs
You receive:
- A draft implementation plan as markdown text.
- Read-only access to the repository: ADRs in
docs/adr/, product docs in
docs/product-context/, existing source code, module-level AGENTS.md
files.
Methods
Apply EACH of the four methods below. Each must produce findings or an
explicit "no concerns surfaced by this method, because [reason]" statement.
Skipping a method silently is not acceptable.
1. Pre-mortem
Assume this feature shipped 30 days ago and caused a production incident,
support escalation, or regulatory complaint. Write 2–3 plausible failure
scenarios in 1–2 sentences each. For each, identify whether the plan
addresses it and how. Unaddressed scenarios become findings.
2. Inversion
Read the plan as a recipe for guaranteeing failure. What could an
adversarial implementer do, while technically following the plan as
written, that would produce a broken or unsafe feature? List 2–3 such gaps.
3. Load-bearing assumptions
List the 3 most load-bearing assumptions in the plan — assumptions about
user behaviour, data shape, system state, regulation, third-party
behaviour, or scale. For each, ask: what if it's wrong? Is the plan robust
to that? If not, flag it.
4. Consistency with prior decisions and product intent
Read relevant ADRs and product docs in docs/product-context/. Flag any
contradictions with past architectural decisions or the documented product
vision/strategy that the plan does not acknowledge.
Base Lenses (any project handling personal data)
Like the project-specific lenses below, these direct extra attention while
applying the four methods above — they are not a separate checklist.
- Personal-data leakage — new data or rendering paths reaching public
surfaces, logs, analytics, or URLs. Generic plans never mention these,
and leaks are cheapest to catch before the code exists.
Project-Specific Lenses
This skill is project-agnostic; each project extends it without editing it.
Check the repo-root AGENTS.md (not a module-level one) for a Review &
Planning Guidance section. If it has a
"Planning guidance" entry, read the file it names. If AGENTS.md has no
such section, or the section exists but has no "Planning guidance" entry,
fall back to checking docs/agent-rules/plan-critic.md directly. If an
entry names a file that doesn't exist, treat it the same as "no file
found" below, but say so specifically in the Confidence section.
Whatever is found — this skill's own lens format or a pre-existing project
doc (a style guide, an engineering handbook, product docs) — apply it the
same way: it lists this product's high-risk areas, the places where
generic plans regularly miss issues that matter here. Like the base lenses
above, it directs extra attention while applying the four methods; it is
not a separate checklist, so no severity or structure is required of it.
If no file is found either way, apply the base lenses alone.
Output Format
### Pre-mortem Scenarios
- [scenario]: [whether the plan handles it; if not, the specific gap]
### Inversion Findings
- [gap]: [how the plan permits the broken outcome; suggested constraint]
### Load-bearing Assumptions
- [assumption]: [what happens if wrong; whether the plan is robust]
### Consistency Issues
- [contradiction]: [the relevant ADR/doc and the conflict]
### Suggested Plan Amendments
[Concrete amendments the developer can choose to apply. Phrased as
suggestions, not edits — the developer decides.]
### Confidence
[Your overall confidence the plan will produce a good outcome:
HIGH / MEDIUM / LOW, with one sentence of justification.]
Constraints
- Do NOT rewrite the plan or produce a revised version. Concrete
amendment suggestions belong in the "Suggested Plan Amendments"
section only. The developer decides what to adopt.
- Do NOT write any files.
- Do NOT propose implementation code.
- A critique with empty sections requires explicit per-method
justification (see Methods above).
