plan-critic git:20261004.cccdee6A

Immutable. This exact content never changes and is served at /api/v1/blob/9fce05ced693fbbe.

---
name: plan-critic
description: >
  Critiques a draft implementation plan with pre-mortem, inversion,
  load-bearing-assumption and consistency checks; returns findings,
  suggested amendments, and a confidence verdict. Use when the user asks to
  review, challenge, or stress-test a plan before implementation.
license: MIT
metadata:
  author: André Cunha
---

# /plan-critic

Find weaknesses in a draft plan before code is written. Attack the plan's
outcome, not its writing quality, formatting, or template completeness.

## Input

- Draft plan (markdown)
- Read-only repo access: `docs/adr/`, `docs/product-context/`, source code,
  module-level `AGENTS.md`

## Steps

### 1. Gather context

- ADRs in `docs/adr/` relevant to the affected areas
- Product docs in `docs/product-context/`
- Module `AGENTS.md` in directories the plan touches

### 2. Load lenses

Lenses direct extra attention while applying the methods (step 3). They are
not a separate checklist; no severity or structure required.

- Base lens (any project handling personal data): **personal-data leakage**
  — new data or rendering paths reaching public surfaces, logs, analytics,
  or URLs
- Project lenses, first match wins:
  1. Repo-root `AGENTS.md` (not module-level) → *Review & Planning Guidance*
     → "Planning guidance" entry → read the file it names
  2. No such section/entry → `docs/agent-rules/plan-critic.md`
  3. Entry names a missing file → treat as no file found, and say so
     specifically in Confidence
- Any doc found (lens-format file, style guide, handbook, product docs)
  applies the same way
- No file found → base lens alone

<!-- When the product grows consent and retention/deletion flows, add lenses
     here: consent lifecycle (not-given / withdrawn / re-consent) and right
     to erasure (cascade, TTL, or explicit reason to retain). -->

### 3. Apply ALL four methods

Each yields findings or an explicit "no concerns surfaced by this method,
because [reason]". Never skip silently.

1. **Pre-mortem**: assume it shipped 30 days ago and caused a production
   incident, support escalation, or regulatory complaint
   - Write 2–3 failure scenarios, 1–2 sentences each
   - Per scenario: does the plan address it, and how? Unaddressed → finding
2. **Inversion**: read the plan as a recipe for failure
   - List 2–3 things an adversarial implementer could do while technically
     following the plan that yield a broken or unsafe feature
3. **Load-bearing assumptions**: list the 3 most load-bearing (user
   behaviour, data shape, system state, regulation, third-party behaviour,
   scale)
   - Per assumption: what if wrong? Is the plan robust? If not, flag
4. **Consistency**: check ADRs and product docs/vision
   - Flag contradictions the plan does not acknowledge

## Output

Markdown, concerns first, in this 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, phrased as suggestions, not edits — the developer decides.]

### Confidence
[HIGH / MEDIUM / LOW, with one sentence of justification.]
```

## Constraints

- Never rewrite the plan or present a revised version; amendments go only in
  *Suggested Plan Amendments*
- Write no files
- Propose no implementation code
- Empty section → per-method justification (step 3)