plan-review

Fresh context, via pd-plan-critic. The author of a plan is the worst reviewer of it.

Machine first, then the model. In that order, and the order is the point.

1. The mechanical failures

pdkit plan check <n>

Sections present; Owns exclusive between tasks; Done when a command rather than prose; every R-ID closed by a task and every task pointing at a real R-ID; e2e coverage decided; Slice hypothesis written; no [NEEDS DECISION] left.

None of these need judgment, and none of them should cost any. An Opus asked to intersect two lists of paths is an Opus that can fail to; pdkit plan check cannot. Red here means the plan gets redone rather than patched — these are the requirements from /pd:plan, not preferences.

2. The question nothing else asks

Give pd-plan-critic the plan and the report from step 1, so it does not spend its context rediscovering what a grep already found.

What it is for: is this task necessary at all, and does something already do it? podman-desktop is large, utilities get duplicated between packages/main and packages/renderer, and reviewers push back on it. Catching that here costs a conversation; catching it in review costs a rewrite.

3. The report

plan-review.md under the issue. Structure it as: what must change before approval, what is worth discussing, and what the reviewer could not judge from the plan alone.

An empty "must change" section is a valid result. A critic that finds something wrong with every plan is one nobody reads by the third time.

State

None. plan check failing is not a state transition — it is a plan that goes back to /pd:plan. Approval stays a human action, and only after it: pdkit ids freeze <n> and pdkit state <n> --to plan-approved.

Next

/pd:exec <issue>, once approval has been given and the state moved. It is spelled exec rather than implement — the state it produces is implemented, and that is the one place in the chain where the state and the command are not the same word.

In a new session. Exec is the longest phase in the chain — several turns per task, for every task — and whatever this one leaves in context is re-read on each of them. It starts from plan.md and the task files; the critic's case is in plan-review.md, and the approval is in the state record. The SessionStart summary names the command once the tree is on the issue's branch, and pdkit next <issue> does anywhere.