# Critique Plan > Pre-implementation critic. Spins up a read-only domain critic that challenges a drafted plan — a task's missions or a roadmap's task graph — against the ubiquitous language, CONTEXT.md, and ADRs, and pushes back ONLY on genuine conflicts. Silent when the plan is sound. Use before implementing (from create-task / create-roadmap) or standalone to stress-test a plan against the project's domain model. - Skill: `ayoubben18/critique-plan` (Agent Skill) - Install (CLI): `npx skillmds@latest add ayoubben18/critique-plan` - Raw SKILL.md: https://api.skillmd.com/api/skills/ayoubben18/critique-plan/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Product & Planning - Author: ayoubben18 (https://skillmd.com/u/ayoubben18) - Updated: 2026-09-10 - Page: https://skillmd.com/skills/ayoubben18/critique-plan --- # Critique Plan (pre-implementation) Stress-test a **drafted plan** against the project's domain model **before** any code is written. This skill produces **pushbacks, not suggestions** — it never gold-plates a plan that is already sound. > **Silence is the expected outcome.** A plan that speaks the canonical language and respects the > documented decisions gets a one-line "No objections." Do not manufacture concerns to look thorough. **ALWAYS check `.ab-method/structure/index.yaml` FIRST** for where the domain model lives — paths are user-configurable. "The plan" is the drafted **mission list** (from create-task), the **task DAG** (from create-roadmap), or whatever the user pastes in (standalone). ## Process ### 1. Load the domain model Read only what exists; skip missing files silently (don't flag them or offer to create them): `UBIQUITOUS_LANGUAGE.md`, `CONTEXT.md` (or `CONTEXT-MAP.md` + each `src//CONTEXT.md`), `docs/adr/`, and `docs/architecture/*`. ### 2. Spin up ONE read-only domain critic (subagent) Spawn a single subagent — `domain-critic` — with the plan verbatim, the files from Step 1, and the rule that it is **read-only**: it returns pushbacks as text and edits nothing. Isolating it keeps the critique out of the planning context. Its brief: **Fire ONLY on a genuine conflict**, one of: - **Terminology drift** — the plan names a concept differently from the glossary/`CONTEXT.md`, or reuses a canonical term for a new meaning. - **Wrong bounded context** — work placed in the wrong context, or a unit that straddles a documented boundary. - **Contradicts an ADR** — reverses a recorded decision *and* the friction is real enough to reopen it. Cite `ADR-NNNN`. - **Bad graph seam** (roadmap) — a `depends-on` edge crosses a seam the wrong way, two "independent" tasks share a domain concept, or a task is mis-scoped (an epic, or a single mission dressed as a task). - **Reinvents a named concept** — introduces a new abstraction for something the domain model names. For each, return **What** (the mission/task/decision), **Conflicts with** (the exact term / `CONTEXT.md` section / `ADR-NNNN`), **Why it matters** (concrete cost, not taste), **Suggested resolution**. > Example pushback: *"Mission 3 calls it `archiveOrder`, but the glossary defines archiving as retention > only — this mission also stops billing, which is **Cancellation**. Rename to `cancelOrder` so the code > matches the domain, or the two concepts will blur across the codebase."* **A parked question is not a gap.** If the plan carries `⚠️ UQ-n` markers, read the task's `unresolved-questions.md` and pass it to the critic as context. A recorded black box is a *decision the user made* — to ship a placeholder rather than guess — so the critic must not fire on "this mission is underspecified" or "the answer to UQ-1 should be X". It fires only if the **placeholder itself** conflicts with the domain model: it contradicts an ADR, quietly redefines a canonical term, or the parked question turns out to be a terminology question wearing a behaviour costume (those aren't parkable — they belong in `CONTEXT.md`). A marker with no matching entry is worth one line: the plan claims a black box that isn't recorded anywhere. **Out of scope for this critic:** implementation quality, performance, tests, code style, "you could also…" ideas — anything not anchored in the domain model. Those belong to the post-implementation [review-implementation](../review-implementation/SKILL.md) skill. With nothing anchored, the critic returns exactly: `No objections — the plan is consistent with the domain model.` ### 3. Surface pushbacks — advisory, never blocking Bring the pushbacks back into the planning session. The user resolves each their way: - **Accept** → amend the plan (rename, re-scope, fix the edge, move contexts) right there. - **Dismiss** → drop it. If the dismissal rests on a **load-bearing reason** a future planner would need in order not to re-raise it, offer to record an ADR ([../domain-model/ADR-FORMAT.md](../domain-model/ADR-FORMAT.md)). Skip ephemeral ("not now") and self-evident reasons. When a resolution sharpens a term, update `CONTEXT.md` inline ([../domain-model/CONTEXT-FORMAT.md](../domain-model/CONTEXT-FORMAT.md)) — same discipline as `/domain-model`. If the critic returned "No objections," say so in one line and move on. Don't pad it. `/domain-model` is a full interactive re-grill of the design; `critique-plan` is a **single-pass, silent-by-default gate** — one critic, real conflicts only, then straight back to the workflow.