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.
2. General subagent + installed skill. Otherwise, launch a general-purpose subagent and instruct it to load and follow the matching installed companion skill by name.
3. 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.