execute-plan-tasks

Execute plan tasks

One task per run — implement it, verify it, tick it, stop. The review between tasks is the point; never carry on into the next.

Invocation: /execute-plan-tasks <plan-path> [task-id]

Pick the task

Read the plan whole — summary, conventions and overrides, the steps the task cites, acceptance criteria — then its ## Tasks section, and the decisions log beside it when it exists (<id>-<slug>.DECISIONS.md, <id>-<slug> being the plan filename without .PLAN.md): a logged deviation outranks the plan text it deviates from. Ambiguous or missing plan path → ask. Several task sections → ask which one this run works from. No task section → stop and point at /split-plan-tasks.

task-id given → that task; none → the first unticked one in order. A range or a whole group → run its first task only, saying the rest need their own runs; a task already ticked → say so and ask whether to redo it. Its dependencies — earlier tasks in its group, plus every task in each group its Depends on line names — must be ticked; name any unticked dependency and ask before proceeding.

Done when the chosen task, its steps, its acceptance criteria, its dependency state and any logged deviation that touches it are stated.

Execute

• Scope is the task's steps, nothing else: no work belonging to a later task, no drive-by refactors. Work the plan calls for that no task covers → report it, don't absorb it.
• The plan's conventions and overrides bind every task, this one included.
• Never guess. What the code settles, settle by reading it; what it doesn't goes to the user as one question carrying your recommendation, worded via explain-in-simple-language when available. Append each settled deviation from the plan, and its why, as one line to the decisions log beside the plan (<id>-<slug>.DECISIONS.md), creating it if absent. Only a deviation confined to the task's own steps and result (an equivalent call, a local adjustment, a corrected attempt departing from the plan text) takes this path; a shape-changing one goes to Stop to re-plan. Correcting your own implementation needs no question.
• A copy is not exempt. A file the plan says to copy or mirror was written for its own runtime and tooling: check each setting fits this task's target before copying. A misfit is a deviation — settle and log it as above.
• Fail-first test — a step requiring its test to fail before the fix, however the plan words it: write the test, run it and see it fail on the bug (its assertion, or the error the bug raises; a broken import or fixture is no failure seen), only then write the fix; never skip the run because the fix looks obvious. Rework the test within the step until it fails that way; until it does, no fix is written, and a test that cannot be made to fail that way is blocked outright (below). Once the fix is in, rerun the same test and see it pass.
• Blocked outright — a step the codebase contradicts, an unmet prerequisite — → stop, leave the task unticked, report what blocks it; leave the edits made so far in place and list them with the blocker, never revert on your own.
• Stop to re-plan (section below) at the task's second failed attempt, or before applying a workaround that would change its shape:
  • A failed attempt is the approach the task's steps prescribe, or a corrected version of it, falling short of the step's result, the task's Done when check or the project's validation for a reason rooted in the approach. The first never stops the run: make one corrected attempt. Not counted: a slip fixed in passing (typo, missing import, lint or format nit, wrong path corrected on sight), or a failure Verify reports as predating the task or outside its scope. One count for the whole task, Execute and Verify alike, within this run only — a later run starts from zero.
  • A workaround changes the task's shape when it would deliver other than its steps describe, add files, areas or behaviour they don't name, change an interface or behaviour later tasks or the plan's acceptance criteria rely on, or abandon the approach the plan prescribes for the task. Stop as soon as one proves needed, whatever the count.
  • A step the codebase contradicts or an unmet prerequisite stays blocked outright, even when a shape-changing workaround could get round it.