mcpField
E
execute-plan

execute-plan

github.com/jayden-dangAgent workflows150 installsUpdated 5d ago
Repository

About execute-plan

A skill for completing approved continuous plans by assigning dependency-ordered tasks to fresh subagents, reviewing each change, and reviewing the branch at the end. It is intended for plan execution without pauses between tasks.

Key features

  1. 01Continuous-plan mode gate
  2. 02Dependency-ordered task waves
  3. 03Fresh implementer subagent per task
  4. 04Two-verdict review of task diffs
  5. 05Whole-branch review at completion

Use cases

  1. 01Executing an approved continuous plan
  2. 02Splitting independent tasks across subagents
  3. 03Reviewing task changes before proceeding

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/jayden-dang/skills --skill execute-plan

After installing, type/execute-planin Claude Code to confirm it loaded.

Bundled files

References and scripts installed along with SKILL.md.

implementer-prompt.md
story-unit-mode.md
task-reviewer-prompt.md
TESTS.md

Details

From the project README

Execute Plan

Drive an approved continuous plan to completion: independent tasks run in dependency-ordered waves, one fresh implementer subagent per task, a two-verdict review of each task's diff, a whole-branch review at the end — no human pause between tasks.

Not this skill:

IntentUse instead
Execution-mode: story-unit (human-gated review units)REQUIRED SUB-SKILL: use execute-story
No subagents / controller implements / user chose inlineREQUIRED SUB-SKILL: use execute-inline

Why fresh subagents: each worker receives exactly the context its task needs and nothing else. Subagents never inherit session history — you construct their world. Bulk artifacts travel as file paths under .skills/, never as pasted text.

Narration: at most one short line between tool calls. Ledger + tool results carry the record.

Mode gate

Execution-mode is a required header on tasks.md. This skill runs only when the value is continuous.

HeaderAction
continuousProceed with Setup below
story-unitDo not run this skill's loop. REQUIRED SUB-SKILL: use execute-story
missing / unset / invalidAsk the user; write continuous or story-unit into tasks.md (commit if tracked). If they pick story-unit → execute-story. If continuous → proceed. Never invent continuous silently. No project-level default

Never run unit barriers, unit derivation, or human unit stops in this skill. Those live only in execute-story.

ThoughtReality
"execute-plan used to handle both modes — I'll keep going in story-unit"Story-unit is execute-story. Staying here is the dual-mode failure
"I'll derive units as a size signal then continuous"No unit table in this skill. Waves come from Depends-on only
"Lead wants human stops — stay in continuous and pause anyway"Pause policy is the header. Write story-unit and use execute-story, or keep continuous with no pauses
"PM / standup — default continuous without asking"Empty mode means not ready; ask and write the field

Setup

  1. Mode gate first. Parse Execution-mode: per the table above. Done when: you are on continuous, or you have handed off to execute-story.
  2. Workspace check — ask first. If no isolated workspace exists yet, ask: isolate in a worktree, or implement on the current branch? Do not create a worktree unasked. Isolation → REQUIRED SUB-SKILL: use worktrees. Current branch is main/master → separate explicit consent before implementing; "no worktree" is not consent to touch main/master. Done when: workspace choice is clear.
  3. Ledger check. Make .skills/ local-only: grep -qxF '.skills/' .gitignore 2>/dev/null || { printf '.skills/\n' >> .gitignore && git commit -m 'chore: ignore local skills artifacts' -- .gitignore; } Read .skills/progress.md if it exists. Every task it marks complete IS complete — resume at the first task it does not list. Done when: next task is known.
  4. Read the plan. Read tasks.md in full once. Copy Global Constraints verbatim for every reviewer dispatch. If docs/agents/project.md is missing, say so, suggest setup-repo, take verify commands from Global Constraints. When ## Team has roster/band, load band packaging only — never skip dual-verdict review for Solo. Done when: constraints captured word-for-word.
  5. Todos — GATE. One todo per task via TodoWrite before any dispatch. Done when: the todo list mirrors the plan.
  6. Pre-flight plan review. Scan once for internal defects (contradictions, assertion-free tests, copy-pasted logic the plan mandates). Batch ALL findings into ONE question to the user before dispatch. Clean scan → no comment. Done when: conflicts ruled or none.
  7. Wave planning. Read each task's Depends-on: line. Named tasks must land first; Depends-on: none = no prerequisite; absent line → depends on every earlier task. Topo-sort into waves. No Depends-on edges → one task per wave (strict serial). Done when: every task sits in a wave.

Per-Task Loop

For Task N:

  1. Record the base. BASE=$(git rev-parse HEAD) — before dispatch, always.
  2. Build the brief. Task N block + verbatim Global Constraints → .skills/task-N-brief.md. Include relevant **ARCH-N** when a docs/architecture/ spine exists. Apply Team band packaging to tone — never omit review obligations.
  3. Dispatch a FRESH implementer using implementer-prompt.md (beside this file). Dispatch inventory only: one-line placement; brief path as requirements; interfaces/decisions prior tasks cannot know; ambiguity resolutions; report path .skills/task-N-report.md; explicit model. Never session history. Never the plan file.
  4. Answer questions fully before the implementer proceeds.
  5. Handle the status per the table below. Work committed on DONE.
  6. Package the diff → .skills/review-<base7>..<head7>.diff: git log $BASE..HEAD --oneline, git diff --stat $BASE HEAD, git diff -U10 $BASE HEAD. Never HEAD~1 as base.
  7. Dispatch a task reviewer using task-reviewer-prompt.md with brief, report, diff package, verbatim Global Constraints, explicit model. Spine present → also REQUIRED SUB-SKILL: use check-invariants; violates enters the fix loop.
  8. Fix loop. Critical/Important → fix subagent (re-run covering tests under tdd, append to same report) → re-review. Same finding survives 3 cycles → stop; plan/design/requirements invalidated → REQUIRED SUB-SKILL: use correct-course; else escalate. Never fix in controller context. Minors → ledger for whole-branch triage.
  9. Resolve ⚠️ items the reviewer could not verify from the diff.
  10. Ledger. Task N: complete (commits <base7>..<head7>, review clean). Mark todo done.
  11. Next. Advance by wave order (see Parallel waves), not raw task number. No permission pause between tasks.

Parallel waves

A single-task wave runs the Per-Task Loop on the branch — the common case. A wave with two or more independent tasks runs them concurrently, each in its own worktree, only when git worktree is usable; otherwise serial.

  1. Record the wave base. WBASE=$(git rev-parse HEAD).
  2. Prove surfaces are disjoint. No two briefs Create/Modify the same file. Overlap → demote to serial; never parallel overlapping surfaces.
  3. Fan out — one worktree per task. Stay in the primary worktree at WBASE. For each task: git worktree add .worktrees/<branch>-taskN -b <branch>-taskN WBASE, run Per-Task Loop steps 1–9 inside that worktree; hold ledger/advance for the barrier. Implementers run concurrently.
  4. Barrier, then merge in task order. Only after every wave task passed review, merge each into the feature branch (never main/master) ascending task number (git merge --no-ff <branch>-taskN). Conflict → STOP and escalate; never resolve a wave merge blind.
  5. Ledger once, worktrees down. Task N: complete (merged <branch>-taskN at <merge7>, review clean) per task; mark todos; git worktree remove each.

Implementer Status Handling

StatusYour move
DONEPackage the diff → task review.
DONE_WITH_CONCERNSRead concerns and .skills/implementation-notes.md. Plan-falsifying deviation → REQUIRED SUB-SKILL: use correct-course. Missing notes while claiming deviation → re-dispatch to log first.
NEEDS_CONTEXTSupply what was named; re-dispatch same model.
BLOCKEDContext → supply; ceiling → stronger model; too large → split; plan wrong → REQUIRED SUB-SKILL: use correct-course.

Cap redispatches at 2 per task; still not DONE → escalate to the user. Never force the same model to retry with nothing changed.

Model Tiering

State the model explicitly on every dispatch — omitted model inherits the session's (usually most expensive).

  • Cheap: transcription / single-file mechanical fixes.
  • Mid floor: every reviewer; every implementer working from prose.
  • Top: design judgment, broad codebase understanding, whole-branch review.

Scale reviewer tier to diff size and risk.

Reviewer-Prompt Hygiene

  • Never pre-judge findings ("do not flag X", "Minor at most", "the plan chose this").
  • A plan-mandated defect is still a finding — ask which governs.
  • No open-ended "check everything" without a concrete task-specific reason.
  • Do not re-run tests the implementer already evidenced in the report.

Durable Progress

Conversation memory does not survive compaction. Todos = live session view; ledger = survives compaction. Never let one excuse skipping the other.

  • On start, read .skills/progress.md; resume after the last complete task.
  • After compaction, trust the ledger and git log over memory.
  • Never re-dispatch a task the ledger marks complete.
  • Crash mid-wave → discard unmerged worktrees; re-run the whole wave off WBASE.
  • .skills/ is git-ignored; if wiped, reconstruct from git log.

After the Last Task

  1. Whole-branch review. REQUIRED SUB-SKILL: use code-review with base = git merge-base main HEAD — never a mid-branch sha. Feed ledger Minors. Top model tier.
  2. One fixer for the complete findings list → re-review. Never one fixer per finding.
  3. Polish. REQUIRED SUB-SKILL: use polish on the whole-branch diff (before acceptance).
  4. Acceptance. REQUIRED SUB-SKILL: use acceptance-check. Breaks → debug, then promote to committed ID-tagged tests. Optional: /allocate-attention (not a gate).
  5. Prepare. REQUIRED SUB-SKILL: use prepare-change.
  6. Finish. REQUIRED SUB-SKILL: use finish-branch.

Inline route

Controller-side sequential execution (no implementer subagents) is owned by execute-inline. If the user chose inline, or the environment cannot fan out implementers: REQUIRED SUB-SKILL: use execute-inline. Do not half-run this skill's subagent loop without dispatches.

Red Flags — Never

  • Run this skill's loop when Execution-mode is story-unit (hand off to execute-story)
  • Stay on this skill when the user chose inline / no subagents (hand off to execute-inline)
  • Run unit barriers, unit derivation, or human unit stops under continuous
  • Pause between tasks to ask permission to continue
  • Invent Execution-mode: continuous because the header is missing
  • Run two implementers in the same worktree, or parallel without isolated worktrees and a disjoint-surface check
  • Merge or ledger a parallel wave before every task in it passed review
  • Hand a subagent the whole plan file — the brief is its world
  • Use HEAD~1 as a review base
  • Skip re-review after a fix, or accept a review missing either verdict
  • Move to the next task with open Critical/Important findings
  • Let implementer self-review substitute for task review
  • Tell a reviewer what not to flag, or pre-rate severity in the dispatch
  • Dispatch a reviewer without a diff package
  • Re-dispatch a task the ledger marks complete
  • Dispatch the first task before the todo list exists
  • Fix reviewer findings in the controller context
  • Start implementation on main/master without explicit consent
  • Create a worktree without asking, or treat "current branch" as consent for main/master

Comments

Markdown supported