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.

Look for it under the project root (the current working directory) first — a project's own copy is how it customises its paths, so it always wins. Only if the project has none (AB Method installed as a plugin rather than with npx ab-method), read the bundled default: ../../../.ab-method/structure/index.yaml relative to this SKILL.md. Either way, every path the index names is relative to the project root, never to the folder the bundled file lives in.

"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>/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.