Review Plan

Read a plan artifact and run a plan adherence review against the spec it was derived from. The spec plus its acceptance criteria are the contract; the plan is a disposable compiler-IR derived from that contract. This skill checks the plan against the spec, sorts the result into one of four outcomes, auto-fixes the plan in place when the plan is at fault and loops until adherent, and routes spec-fault findings to the human in a references-first review record without ever patching the plan to paper over a spec gap. The review is mode-agnostic — it judges plan-against-spec however the plan was authored (autonomously or by a human). By default it does not walk findings with the user one-at-a-time, but it honors an invocation that asks it to check in or walk the findings interactively; it does not commit.

Why This Review Must Be Trustworthy

In this workflow the human reads and approves the spec; the plan is a disposable intermediate the human never needs to read. A human may review the implementation, but they do not audit the plan — which is exactly why this machine adherence review carries the weight. If it clears a plan that silently drifted from the spec, the drift reaches implementation unseen. The contract being enforced is the spec, not the plan: a finding always traces back to "does the plan deliver what the spec promised?".

Inputs

This skill accepts ONE required input and ONE strongly-recommended input:

1. (Required) A plan artifact path — plans/NNN[-<desc>]/plan.md inside the thread root. The path may be passed thread-relative or repo-relative. Loose-granularity plans and strict-granularity plans are both accepted — the ## Loose vs Strict Detection step below selects which ambiguity check applies.
2. (Strongly recommended) The spec path the plan was derived from — specs/NNN[-<desc>]/spec.md inside the thread root. The spec is the contract this review judges the plan against. When NOT supplied, ASK the user which spec the plan derives from before proceeding — an adherence review with no contract has nothing to check the plan against. Only if the thread genuinely holds no spec (a planning-without-spec exception the user confirms) does the review fall back to the structural checks alone, with an ## Open Questions note that adherence could not be assessed.

If the plan path is not supplied, ASK the user which plan to review — do not pick by recency. If the thread holds multiple plan lineages (plans/001/, plans/002-cli/) and the user's reference is vague ("the plan", "the auth plan"), ASK which lineage is intended. There is NO "most recent lineage" or "highest NNN" fallback. Each lineage holds exactly one alive plan.md (plans carry no version — version lives only on the spec), so "which version" never arises; but "which lineage" can, and silently picking by number would hide a real decision (which lineage the user means) behind a sort order. The same lineage-resolution rule applies to the spec input.

The literal folder plans/NNN[-<desc>]/ is the canonical location plan artifacts land in. If the path passed is not a plan.md under a plans/ lineage folder, refuse and ASK the user to confirm — a plan not under plans/ is either a misplaced draft (still in .wip/, not yet emitted) or not actually a plan. If the supplied spec path is not a spec.md under a specs/ lineage folder, ASK the user to confirm.