Executing Plans

Execute the plan yourself, task by task, in this session: no per-task implementer or reviewer subagent, one routed final review per missing artifact class at the end. The brief is the spec, the ledger is your memory, TDD is the per-task gate, the final reviewer is the second pair of eyes.

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

Strategy before execution

Before every automated review or test/check pass, resolve a snapshot-bound REUSE, WAIT, RUN_MINIMAL, REVIEW_REQUIRED or STOP decision at its supported execution/dispatch boundary. Reuse valid coverage or join its active producer. Missing/stale decisions refuse; unknown coverage stays conservative. No model calls or recursive checks inside strategy. Status/HEAD changes, clean reviews and score targets alone never justify another expensive pass.

Execution control

An independent execution controller owns phase acceptance and may STOP scope expansion. This role is separate from implementation and code review; use a fresh agent for a drift exception or disputed acceptance, not every action. Routine decisions use the deterministic tools/execution-admission.py gate.

Before a managed edit, check or review, register the active phase, its open acceptance criterion, exact patch paths or check argv/selector, and proof inputs in the private execution-control registry. Invoke admission with the actual request before execution. Missing ownership, stale prerequisite fingerprints, unrelated selectors and successor work before predecessor acceptance STOP. Close criteria only against their required evidence. Reuse unchanged proof. The ledger records costs and exceptions; it cannot substitute for admission. Unsupported host boundaries remain UNENFORCED in the support matrix.

When to Use

• A written plan exists (writing-plans), the user reviewed that saved plan and authorized execution, and chose native execution — or no subagent tool exists (never fabricate a dispatch). Approval of an unseen scope is not approval of an unseen plan.
• Prefer subagent-driven-development when the user wants a review gate per task, or the plan is long enough that late tasks would run on a compacted context. Native runs well on a mid-tier session model; tell the user so.

Operating Rules

• Continuous within admitted scope: do not pause to check in between tasks. Narrate at most one short line between tool calls; bookkeeping rides in the same call as work.
• Rulings, not stalls: decide conflicts, ambiguities, and plan defects. The spec is the binding authority, the plan its argument. Ledger each as Task <N>: Ruling: <what you decided> — <why> — <cost if wrong>. A deviation without a ledgered ruling is a decision made in secret.
• Only four things stop you: an irreversible or destructive operation; a security-sensitive action; a side effect outside this worktree that norms say to ask about (merge, push to a shared branch, publish); a plan so broken every path is a guess.
• Context hygiene: redirect long output to a workspace file and read its tail; read a task's brief, not the whole plan.
• Before any git commit: run unified-commit-gate (all applicable gates), even mid-plan.

Setup

Run every command from the target repo's root. Script paths below (scripts/…, ../subagent-driven-development/…) are relative to this skill's installed directory — ~/.claude/skills/executing-plans or ~/.codex/skills/executing-plans — so prefix them with it.

1. Isolated workspace via using-git-worktrees; never implement on main/master without explicit consent.
2. Workspace and ledger are shared with subagent-driven-development so executors can swap mid-plan: run bash ../subagent-driven-development/scripts/sdd-workspace PLAN_FILE (prints <repo>/.superpowers/sdd/<plan-basename>/). Another plan's directory is never yours.
3. Ledger <workspace>/progress.md, first line # SDD ledger — plan: <plan file path>. If it names your plan, every Task <N>: complete line is DONE — resume at the first task without one; after compaction trust the ledger and git log over recollection. A ledger naming another plan: leave it, start your own. git clean -fdx destroys it; recover from git log.
4. Read the plan once (Global Constraints) and its Spec if named; no reachable spec → ledger note, rulings provisional. One todo per task.
5. Load test-driven-development now; it governs every step.
6. Pre-flight scan: for each task consuming what an earlier task produces (Interfaces blocks), one ledger row: both tasks, produced vs consumed, finding, ruling. Nothing shared → Pre-flight: no shared interfaces.

The Task Loop

1. Take: bash scripts/task-start PLAN_FILE N prints the brief path and BASE. Read the brief every time — memory is a summary, the brief has the exact values. Mark the todo in_progress.
2. Admit, then work the steps in their RED-GREEN order. Watching the test fail is a step; a test that passes before the implementation exists is a finding about the test. Compare every Expected: line to real output: matches → next; code wrong → systematic-debugging, never patch the symptom; plan wrong → smallest spec-satisfying change, ledgered ruling. Commit as the plan says; BASE, never HEAD~1, cuts the review range.
3. Completion contract (verification-before-completion governs the claim), with evidence from this session: every named test exists and ran; the final run passed; every Expected: was compared; every deviation has a Ruling: line. Anything missing → the task is not complete.
4. Complete: bash scripts/task-done PLAN_FILE N BASE -- <test command> must use the authoritative runner, reusing its valid task coverage before it appends Task <N>: complete (commits <base>..<head>, tests: <cmd> → <result>). A failing run records nothing. Mark the todo complete; next task.

Final Review

1. bash ../subagent-driven-development/scripts/review-package PLAN_FILE MERGE_BASE HEAD (MERGE_BASE = git merge-base <base-branch> HEAD).
2. Resolve the native review preflight and actual artifact routes. Obey REUSE, WAIT or STOP; dispatch only a required class with REVIEW_REQUIRED. With a subagent tool: send the routed class's reviewer the package, plan/spec, Review Focus and ledger rulings, with SPP_REVIEW_CLASS=<required-class> SPP_REVIEW_SNAPSHOT=<strategy.snapshot>. Use one combined reviewer per missing class, on the most capable available model. Never replace independent review with your own read of the diff. Without one: ledger Final review: self-review (no subagent tool); the user decides whether that suffices before merge.
3. Re-grade by effect (what a reasonable user gets if it ships), not by whether the spec named the input. Each "Declined to judge" item becomes a ledgered Final: Ruling:.
4. Critical/Important → ONE fix pass, each fix: reproducing test RED → GREEN, then resolve missing/invalidated project coverage; ledger Final: fixed <finding> — <test> RED→GREEN, suite <N>/<N>. No re-review dispatch without a new actionable basis. Not fixing is a Final: Ruling:. Minor → Final: minor (deferred): <one-liner>, never fixed, never a ruling.

Finish

Final message lists every Ruling: line under "Rulings I made" (in order, with cost if wrong) and every deferred minor under "Deferred minors" — exhaustive; it is the only place those decisions reach the user. When the review is clean and fixes are committed, delete this plan's workspace directory (siblings belong to other plans). Before pushing, run unified-commit-gate (/sp-push), reusing valid content/context coverage. Confirm the required native clearances with read-only readiness for the pushed ref. Then follow finishing-a-development-branch.

Common Rationalizations