Run a phase-based plan through a repeatable delegated workflow. The plan is\nthe source of truth, any PRD/spec is supporting context, and each phase should\nmove through orientation, implementation, validation, review, plan updates, and\ncommits by default.
\nUse this skill only when the user explicitly asks for delegated phase\norchestration, invokes this skill, or asks to implement a plan/checklist using\nsubagents.
\nThis skill is the parent of a five-skill workflow:
\nwrite-phase-plan — authors plans in the format this skill consumes best.phase-implementer — the delegated worker contract for implementing exactly\none phase (Phase Loop step 2).phase-reviewer — the delegated worker contract for the review-and-fix pass\non a completed phase (Phase Loop step 4).phase-final-reviewer — the delegated worker contract for the end-to-end\nreview of the whole feature after all phases (Final Whole-Feature Pass).Each worker skill carries that role's standing rules: single-phase or\nsingle-pass scope, no-revert discipline, no-commit default, and the required\nfinal-response format. The parent's prompt only needs to supply the per-run\ncontext from the templates below.
\nHow to dispatch a worker role depends on the host:
\nTodoWrite in Cursor) for the in-chat\norchestration state. Keep exactly one phase or orchestration step\nin_progress.Subagent in Cursor) for delegated\nimplementation, broad read-only exploration, review/fix passes, validation,\nand shell/git work when delegation is useful.explore type, where available) for\nbroad codebase discovery before implementation.resume parameter). The user may ask for flows that reuse the same\nagent across the run — the same reviewer re-checking its own earlier\nfindings, or an implementer revisiting its phase after review — and\nresuming beats a fresh dispatch there because the agent keeps everything it\nalready learned. Keeping the IDs in thread history is what makes that\npossible later.Accept any of these as the plan source:
\nOptional inputs:
\nIf the plan does not name phases, derive a conservative dependency-ordered phase\nlist and record that grouping in the plan or in the in-chat todos before\nstarting implementation.
\nThe companion write-phase-plan skill defines the plan format this skill\nconsumes best (phase sections with status, scope, acceptance criteria,\nvalidation commands, and an implementation log). A plan in that shape needs no\nderivation step; prefer it when authoring a plan ahead of an orchestration run.
Before spawning implementation workers:
\nDuring the run:
\nThe default topology for a phase is one implementer, then validation, then one\nreviewer. During orientation, pick a different topology when the phase's shape\ncalls for it:
\nRules for every topology: parallel workers must have disjoint write scopes;\nevery loop needs an explicit stop condition (success, an attempt ceiling, or\nno-progress detection); and results come back in the Worker Result Contract\nshape so the parent can combine them without carrying transcripts.
\nRun this loop for each phase in dependency order.
\nSpawn a worker under the phase-implementer contract to implement only the\nactive phase. The worker edits files directly. The parent orchestrator owns\ncommits by default unless the user opted out or explicitly delegated commits\nto a worker.
After the worker returns:
\nRun or delegate affected validation for the phase. Use the repo's documented\ncommands when available, and include tests, lint, typecheck, migrations, or\nbrowser checks when relevant.
\nIf validation cannot run, record the exact command, blocker, and risk in the\nphase notes or plan log.
\nSpawn a worker under the phase-reviewer contract after implementation and\ninitial validation. Note its agent ID alongside the phase.
Build the review prompt from primary evidence first: the plan and acceptance\ncriteria, the actual diff or commit range, repo rules, and validation results.\nDo not lead with the implementer's summary. Include implementer notes only as\nsupplemental context for the reviewer to consult after independently inspecting\nthe change. This avoids anchoring the review to what the implementer believed it\nchanged.
\nThe reviewer/fixer should:
\nCommit each completed phase by default unless the user requested \"no commits\",\n\"implementation only\", or another no-commit constraint. Prefer the parent\nagent's normal commit workflow unless a dedicated shell subagent is clearly\nuseful.
\nWhen committing:
\nUpdate the plan or phase log for the active phase.
\nRecord:
\nCommit the plan/log update separately from implementation changes unless the\nuser opted out of commits.
\nAfter all requested phases are finalized:
\nphase-final-reviewer contract to inspect the\ncomplete feature against the plan and PRD/spec.Give the final reviewer the plan, acceptance criteria, complete diff or commit\nrange, and aggregate validation before phase summaries. Phase summaries are\nsupplemental and should be read only after an independent pass over the primary\nevidence.
\nFor a plan with sequenced phases plus parallel tracks — especially when the\nuser's checkout is on their own branch, is behind the default branch, or\ncarries dirty user-owned work — run the orchestration in dedicated git\nworktrees and land each phase as a PR in a stack, instead of committing to the\nuser's checkout.
\nWhen to choose this mode:
\nSetup:
\n../<repo>-<feature>-work.origin/<default-branch>, not the local checkout:\ngit worktree add <worktree-path> origin/<default-branch> --detach.git worktree add <track-worktree-path> <base-branch> -b <track-branch>)\nso parallel workers never share a checkout. Point each worker at its own\nworktree path in its prompt.git worktree remove <worktree-path>),\nand if the host can point its diff view at a worktree (Cursor's\nSetActiveBranch), do so, so the IDE diff follows the work.Branching and stacking:
\ngit push -u origin <branch>, then open the PR with the gh CLI, setting\n--base to the parent branch for stacked phases and to the default branch\nfor the stack root:\ngh pr create --title \"type(scope): subject\" --body \"$(cat <<'EOF' ... EOF)\" --base <parent-branch>.Keeping the stack healthy during the run:
\ngh pr checks <n>); investigate\nfailures with gh api .../actions/jobs/<id>/logs before assuming a worker's\nchange caused them — a failure may predate the stack's base.gh pr view <n> --json baseRefName.git merge-base --is-ancestor before closing inner\nPRs; the survivor merges, never closes).The final summary must report the stack shape: which PRs are open, their base\nbranches, merge order, CI state, and which worktrees were created or removed.
\nAdapt these to the repo and phase. These templates are the per-invocation\ncontext to hand each worker — the standing role rules (scope discipline,\nno-commit default, response format) live in the companion skills, so the\nprompt's job is the run-specific facts. If the worker runs as a named custom\nagent built from the companion skill, the template alone is enough; if it runs\nas a general subagent, prepend an instruction to load and follow the matching\ncompanion skill, or paste that skill's standing rules above the template.\nWhen resuming a prior worker by ID instead of dispatching fresh, send only\nwhat changed since its last response; it retains the rest.
\nEvery worker response must use these headings in this order:
\nOutcome — concise result or explicit no-op.Changed files — files the worker changed, not every file it inspected.Behavior or findings — implemented behavior or review findings and fixes.Validation — exact commands or checks and their results.Downstream impact — plan changes, follow-up work, or None.Blockers and risks — unresolved issues, skipped checks, manual checks, or\nNone.Keep Changed files proportional. List paths individually when the list is\nshort. When it would become a long, low-signal inventory, group paths by\nmodule/directory, give counts, and name only high-signal or exceptional files.\nLabel a grouped list as a summary rather than exhaustive; the parent inspects\ngit status and the diff for the authoritative file list.
phase-implementer)You are implementing phase {phase_name} of this plan.\n\nContext:\n- Plan: {plan_path_or_summary}\n- PRD/spec: {prd_path_or_summary_or_none}\n- Prior phase commits and notes: {prior_phase_summary}\n- Repo instructions and validation requirements: {repo_rules_summary}\n- Current dirty-worktree notes: {dirty_worktree_summary}\n\nOwnership:\n- You own {owned_files_or_modules}.\n- Other agents or the user may have changes in the worktree. Do not revert work\n you did not make. Adapt to existing changes.\n\nTask:\n- Implement only phase {phase_name}.\n- It is acceptable to deviate from the plan when the codebase shows a better\n path, but document the reason and downstream impact.\n- Commit policy: {commit_policy}. The parent orchestrator commits by default;\n do not commit from this worker unless this explicitly delegates commit\n authority to you.\n\nValidation:\n- Run {affected_tests_or_checks} where practical.\n- If a required check is not practical, explain why.\n\nFinal response:\n- Use the Worker Result Contract headings in order.\n- In `Behavior or findings`, describe the behavior implemented.\nphase-reviewer)Review and fix phase {phase_name}.\n\nContext:\n- Plan: {plan_path_or_summary}\n- PRD/spec: {prd_path_or_summary_or_none}\n- Change under review: {commit_range_or_diff_scope}\n- Validation evidence: {phase_validation_results}\n- Repo rules: {repo_rules_summary}\n- Commit policy: {commit_policy}\n- Supplemental implementer notes: {phase_result}\n\nTask:\n- First inspect the plan, acceptance criteria, and actual change. Form an\n independent assessment before reading the supplemental implementer notes.\n- Review the phase against acceptance criteria, repo conventions, security,\n tenancy/data ownership, migrations, and test coverage.\n- Patch concrete issues directly when bounded and low-risk.\n- Do not commit from this worker unless the commit policy explicitly delegates\n commit authority to you.\n- If no changes are needed, say so clearly.\n- If the plan should change, describe the exact plan and downstream updates.\n\nFinal response:\n- Use the Worker Result Contract headings in order.\n- In `Behavior or findings`, report findings fixed, the no-op result, and any\n findings not fixed.\nphase-final-reviewer)Review the entire feature after all requested phases.\n\nContext:\n- Plan: {plan_path}\n- PRD/spec: {prd_path_or_none}\n- Complete change: {commit_range_or_diff_scope}\n- Final validation results so far: {validation_summary}\n- Supplemental phase results: {all_phase_results}\n\nTask:\n- First inspect the plan, acceptance criteria, and complete change. Form an\n independent assessment before reading the supplemental phase results.\n- Review end-to-end behavior against the plan and PRD/spec.\n- Look for integration bugs, missing acceptance criteria, stale plan state,\n validation gaps, unsafe data ownership, and regressions across phase\n boundaries.\n- Patch only concrete issues that are safe to fix now.\n- Do not commit from this worker unless the commit policy explicitly delegates\n commit authority to you.\n\nFinal response:\n- Use the Worker Result Contract headings in order.\n- In `Behavior or findings`, report findings fixed, the no-op result, and any\n findings not fixed.\nPrefer a stable plan structure:
\nDo not let the plan become ceremonial. If implementation or review shows that a\ntask is obsolete, split, merged, or better solved differently, update the plan\nand explain why.
\n