executing-plans

name	executing-plans
description	Use when an approved implementation plan will be executed inline in a separate session with batch checkpoints

Executing Plans

Execute an approved Full plan on the main thread, serially, in the single task worktree. Tasks run in depends_on topological order. task.json is the progress source, superharness:test-driven-development supplies the implementation discipline, and all review waits for the shared final check. Lite remains its separate serial route in superharness:go.

Announce at start: "I'm using the executing-plans skill to implement this plan."

Load and Resume

1. Read task.json, prd.md, contract.md, and plan.md.
2. Review the plan for blocking gaps before editing.
3. Confirm the worktree and branch are isolated and inspect current git status/diff/log.
4. Resume at the first task whose status is not "completed". Do not rerun completed tasks' focused verifications — the finishing gate covers the whole set once at the end.
5. If a task is already in_progress and the checkout is dirty, inspect its diff and focused verification, preserve the edits, and continue as a recovery agent. Never reset or stash recovery work.

Execute Each Task

For each task in dependency order:

1. Confirm its Outcome, Files/Modules, Public Seams, Behavior Slices, Dependencies, Focused Verification, and Commit Intent.
2. Run superharness task item {task-id} {task-number} start.
3. Invoke superharness:test-driven-development. For each tested behavior slice, expose one seam through one failing behavior test, run RED, add the minimum implementation, then run GREEN. Confirm each verified slice through its declared gate instead of a dedicated test.
4. Run the task's focused verification, commit only that task's scope with an exact pathspec (git commit --only -- <files>), resolve the full SHA, and record superharness task item {task-id} {task-number} complete --commit {full-sha}.

There is no per-task reviewer and no per-task E2E checkpoint. Stop for missing context, unexplained failures, or unclear edit ownership; record the corresponding task item status before returning control.

Batch Checkpoint

After three to five completed tasks, report:

• completed task ids and commits;
• focused commands with observed results;
• the next pending task;
• unresolved concerns.

The batch checkpoint is a user visibility boundary. It does not transition the workflow to check and does not create a review artifact.

Shared Final Check

When every task item is completed:

1. Run superharness task transition {task-id} check once.
2. Follow superharness:subagent-driven-development's Final Check exactly: shell preflight, then dispatch the Spec axis and the Standards axis check agents in parallel and present both reports separately.
3. Invoke superharness:finishing-a-development-branch for the single fresh final verification, the review discipline recorded in verification.md, and the completion flow.

Red Flags

• Editing a task before the current tested slice's RED demonstrates the missing behavior
• Writing a dedicated test for a verified slice, or silently skipping a tested one
• Updating task item state by hand instead of superharness task item
• Dispatching a reviewer between tasks
• Resetting or stashing recovery work
• Entering final check with pending, blocked, or context-needing task items