Phase Orchestrator

Phase Orchestrator

Goal

Run a phase-based plan through a repeatable delegated workflow. The plan is the source of truth, any PRD/spec is supporting context, and each phase should move through orientation, implementation, validation, review, plan updates, and commits by default.

Use this skill only when the user explicitly asks for delegated phase orchestration, invokes this skill, or asks to implement a plan/checklist using subagents.

Companion Skills

This skill is the parent of a five-skill workflow:

• write-phase-plan — authors plans in the format this skill consumes best.
• phase-implementer — the delegated worker contract for implementing exactly

one phase (Phase Loop step 2).

• phase-reviewer — the delegated worker contract for the review-and-fix pass

on a completed phase (Phase Loop step 4).

• phase-final-reviewer — the delegated worker contract for the end-to-end

review of the whole feature after all phases (Final Whole-Feature Pass).

Each worker skill carries that role's standing rules: single-phase or single-pass scope, no-revert discipline, no-commit default, and the required final-response format. The parent's prompt only needs to supply the per-run context from the templates below.

How to dispatch a worker role depends on the host:

1. Named custom agents. If the host supports named custom agents or

subagent types (Cursor custom agents, for example), prefer a dedicated agent per role whose definition is the matching companion skill's body.

1. General subagent + installed skill. Otherwise, launch a general-purpose

subagent and instruct it to load and follow the matching installed companion skill by name.

1. Inline rules. If the subagent cannot load skills, paste the companion

skill's standing rules into the prompt along with the per-run context.

Host Mapping

• Use the host's todo tracker (TodoWrite in Cursor) for the in-chat

orchestration state. Keep exactly one phase or orchestration step in_progress.

• Use the host's subagent or task tool (Subagent in Cursor) for delegated

implementation, broad read-only exploration, review/fix passes, validation, and shell/git work when delegation is useful.

• Use fast read-only subagents (Cursor's explore type, where available) for

broad codebase discovery before implementation.

• Use shell-focused subagents only for command-heavy validation or git

operations.

• Respect the user's or host's model choice for workers. Pass a model

explicitly only when the user requests a specific model for the run or for a specific worker.

• Use background subagents when the host supports them and independent

read-only investigations can run in parallel.

• Do not assume subagents can be "closed"; inspect their final response and

continue from the parent agent.

• Record every spawned subagent's ID in the main thread (alongside its phase

in the todo/phase notes) when the host exposes one. Some hosts can resume a completed subagent by ID with its full context preserved (Cursor's task tool resume parameter). The user may ask for flows that reuse the same agent across the run — the same reviewer re-checking its own earlier findings, or an implementer revisiting its phase after review — and resuming beats a fresh dispatch there because the agent keeps everything it already learned. Keeping the IDs in thread history is what makes that possible later.

• Treat worker responses as structured handoffs. Require the result fields

defined below so the parent can compare and combine results without carrying an unstructured transcript in context.

• Follow the host's normal tool rules: read tool schemas before unfamiliar

calls, avoid destructive git commands, and never revert user-owned work.

Inputs

Accept any of these as the plan source:

• A path to a plan, checklist, task breakdown, issue list, or phase document.
• A pasted plan in the conversation.
• A PRD or spec plus a request to derive implementation phases.

Optional inputs:

• PRD, design doc, ticket, issue, or acceptance criteria.
• Branch, commit style, validation commands, release constraints, or PR target.
• A stopping point such as "phase 2 only", "implementation only", or "no commits".

If the plan does not name phases, derive a conservative dependency-ordered phase list and record that grouping in the plan or in the in-chat todos before starting implementation.

The companion write-phase-plan skill defines the plan format this skill consumes best (phase sections with status, scope, acceptance criteria, validation commands, and an implementation log). A plan in that shape needs no derivation step; prefer it when authoring a plan ahead of an orchestration run.

Orchestrator Duties

Before spawning implementation workers:

1. Read the plan, optional PRD/spec, repo instructions, relevant contributor

docs, and current git status.

1. Identify phases, dependencies, validation requirements, ownership boundaries,

and whether the user opted out of the default commit workflow.

1. Create or update the in-chat todo plan with one active phase or orchestration

step.

1. Note existing dirty worktree changes and treat them as user-owned unless a

subagent clearly made them for this workflow.

During the run:

• Execute phases sequentially unless the plan marks phases as independent and

their write scopes are disjoint.

• Give every subagent enough context to act safely: plan path, PRD/spec path,

phase scope, prior phase results, repo rules, validation commands, ownership scope, dirty-worktree notes, and commit policy.

• Tell coding subagents they are not alone in the worktree, must not revert work

they did not make, and must adapt to existing or concurrent changes.

• If new information invalidates the plan, update the plan and downstream phase

items instead of silently following stale instructions.

• Keep the user updated at phase boundaries, before edits, during long

validation, and whenever a blocker or plan deviation appears.

Phase Topologies

The default topology for a phase is one implementer, then validation, then one reviewer. During orientation, pick a different topology when the phase's shape calls for it:

• Batch migration — one worker discovers the target items, parallel

implementers each own a disjoint batch, then aggregate validation and one reviewer over the combined diff. For mechanical changes across many files.

• Audit / sweep — parallel read-only workers each inspect a slice, a

separate verifier confirms each finding against the code, and the parent deduplicates and ranks before acting. For phases whose output is findings rather than edits.

• Fix-until-green — run the failing check, dispatch a fix worker, re-run,

repeat. Stop when the check passes or two consecutive rounds make no progress; then escalate to the user or update the plan instead of looping.

• Competing drafts — for a high-stakes design decision inside a phase, two

or three workers draft independently; the parent compares and adopts or synthesizes one before implementation proceeds.

Rules for every topology: parallel workers must have disjoint write scopes; every loop needs an explicit stop condition (success, an attempt ceiling, or no-progress detection); and results come back in the Worker Result Contract shape so the parent can combine them without carrying transcripts.

Phase Loop

Run this loop for each phase in dependency order.

1. Orient The Phase

• Re-read the phase section, acceptance criteria, and prior logs.
• Inspect git status and recent relevant commits.
• Choose the phase's topology (see Phase Topologies): the default single

implementer, or a fan-out/loop shape when the phase calls for one.

• Update the todo tracker before spawning workers.

2. Implementation Worker

Spawn a worker under the phase-implementer contract to implement only the active phase. The worker edits files directly. The parent orchestrator owns commits by default unless the user opted out or explicitly delegated commits to a worker.

After the worker returns:

• Note its agent ID in the phase's todo/notes for possible resumption.
• Inspect its summary, changed paths, validation results, blockers, and risks.
• Inspect git status and a focused diff.
• If implementation is incomplete because assumptions changed, send a bounded

follow-up (resume the same worker by ID so it keeps its context) or update the plan before continuing.

3. Validation

Run or delegate affected validation for the phase. Use the repo's documented commands when available, and include tests, lint, typecheck, migrations, or browser checks when relevant.

If validation cannot run, record the exact command, blocker, and risk in the phase notes or plan log.

4. Review And Fix Worker

Spawn a worker under the phase-reviewer contract after implementation and initial validation. Note its agent ID alongside the phase.

Build the review prompt from primary evidence first: the plan and acceptance criteria, the actual diff or commit range, repo rules, and validation results. Do not lead with the implementer's summary. Include implementer notes only as supplemental context for the reviewer to consult after independently inspecting the change. This avoids anchoring the review to what the implementer believed it changed.

The reviewer/fixer should:

• Review the phase against the plan, PRD/spec, repo rules, security, tenancy/data

ownership, migrations, tests, and likely regressions.

• Patch concrete issues directly when bounded and low-risk.
• Leave review fixes uncommitted for the parent orchestrator to commit unless

the user opted out or explicitly delegated commits to the reviewer/fixer.

• Report no-op clearly if no changes are needed.
• Report larger design issues with the exact plan changes needed.

5. Default Commit

Commit each completed phase by default unless the user requested "no commits", "implementation only", or another no-commit constraint. Prefer the parent agent's normal commit workflow unless a dedicated shell subagent is clearly useful.

When committing:

• Follow the host's git safety rules.
• Inspect git status, full staged/unstaged diff, and recent log first.
• Stage only files that belong to the active phase.
• Run repo-required pre-commit validation and affected tests.
• Fix validation failures only when the fix is clearly in phase scope.
• Create a focused commit, or report an explicit no-op if there are no phase

changes.

6. Plan Finalization

Update the plan or phase log for the active phase.

Record:

• Phase status: Done, Partial, or Blocked.
• Implementation summary and changed behavior.
• Validation commands and results.
• Review outcome.
• Commit SHAs, if commits were created.
• Deviations from the original plan.
• Downstream changes, remaining risks, and manual checks not performed.

Commit the plan/log update separately from implementation changes unless the user opted out of commits.

Final Whole-Feature Pass

After all requested phases are finalized:

1. Run aggregate validation appropriate for the whole feature.
2. Spawn a worker under the phase-final-reviewer contract to inspect the

complete feature against the plan and PRD/spec.

1. If the final reviewer changed files, validate those fixes.
2. Commit final fixes or final plan/log updates unless the user opted out of

commits.

1. Give the user a concise final summary with phase status, validation, commit

SHAs if any, remaining manual gaps, and branch/worktree status.

Give the final reviewer the plan, acceptance criteria, complete diff or commit range, and aggregate validation before phase summaries. Phase summaries are supplemental and should be read only after an independent pass over the primary evidence.

Worktrees And Stacked PRs (Option For Complex Plans)

For a plan with sequenced phases plus parallel tracks — especially when the user's checkout is on their own branch, is behind the default branch, or carries dirty user-owned work — run the orchestration in dedicated git worktrees and land each phase as a PR in a stack, instead of committing to the user's checkout.

When to choose this mode:

• The plan names foundations that later phases build on, so phases must land

as separate reviewable PRs in dependency order.

• Two or more tracks touch disjoint areas (for example API vs web) and can run

as concurrent implementation workers without colliding.

• The current checkout is not a safe base: behind origin, on a personal

branch, or dirty with user-owned edits.

Setup:

1. Choose worktree locations and branch names from the target repo's

contributor docs and the user's rules — conventions differ (some require a specific in-repo directory, others forbid one). Only when no rule exists, default to a sibling directory such as ../--work.

1. Fetch and branch from origin/, not the local checkout:

git worktree add origin/ --detach.

1. Make the worktree runnable before spawning workers: copy gitignored env

files from the user's checkout, install dependencies, run the repo's build-before-measure steps (built packages, generated clients). Workers inherit a broken toolchain otherwise.

1. Create one additional worktree per concurrent track

(git worktree add -b ) so parallel workers never share a checkout. Point each worker at its own worktree path in its prompt.

1. Remove temporary worktrees when done (git worktree remove ),

and if the host can point its diff view at a worktree (Cursor's SetActiveBranch), do so, so the IDE diff follows the work.

Branching and stacking:

• One branch per phase, cut from the previous phase's branch when the phase

depends on it: foundations first, then tracks stacked on the last foundation they need. Parallel tracks branch from the same base, not from each other.

• Commit each phase on its branch (orchestrator owns commits), push with

git push -u origin , then open the PR with the gh CLI, setting --base to the parent branch for stacked phases and to the default branch for the stack root: gh pr create --title "type(scope): subject" --body "$(cat .

• Record the PR number in the phase's todo item so the final summary can map

phases to PRs.

• A schema/migration phase ships as its own PR based on the default branch;

code that depends on it stacks on the migration branch (many repos require this — check the repo's contributor docs).

Keeping the stack healthy during the run:

• Check CI on every open PR after pushes (gh pr checks ); investigate

failures with gh api .../actions/jobs//logs before assuming a worker's change caused them — a failure may predate the stack's base.

• If the default branch gains a fix the stack needs, merge it forward through

the stack in order (base branch first, then each child), using a temporary worktree if the branches are checked out elsewhere. Never rebase or force-push pushed branches.

• When an inner PR merges early, GitHub retargets its children automatically;

verify with gh pr view --json baseRefName.

• Follow the repo's stack-collapse rules before final review if it has them

(prove containment with git merge-base --is-ancestor before closing inner PRs; the survivor merges, never closes).

The final summary must report the stack shape: which PRs are open, their base branches, merge order, CI state, and which worktrees were created or removed.

Prompt Templates

Adapt these to the repo and phase. These templates are the per-invocation context to hand each worker — the standing role rules (scope discipline, no-commit default, response format) live in the companion skills, so the prompt's job is the run-specific facts. If the worker runs as a named custom agent built from the companion skill, the template alone is enough; if it runs as a general subagent, prepend an instruction to load and follow the matching companion skill,

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: hraness
• Source: hraness/slopcamera
• License: MIT
• Homepage: https://slopcamera.com/

Install and usage instructions live in the source repository linked above.