Strategies
How phases fan out into agent steps at run time.
A schema's phases declare what a step does; a strategy decides how the phase is rendered into one or more agent invocations at run time. A phase picks a strategy by name (strategy: task-group-implement), and the runner consults the matching strategy template to render the agent's system prompt and, where relevant, expand the phase into multiple sub-steps.
contractor ships five named strategies. They live in packages/cli/src/lib/slash-commands/strategies.ts and consume templates from packages/cli/schemas/commands/strategies/.
artifact-loop
Walks every artifact in the schema's artifacts: list and renders each one's instruction as a subsection. The agent's system prompt lists the artifact ids and the schema flag (--schema <name>), then walks the agent through producing each artifact in dependency order.
Used by: the propose phase in both contractor-base and contractor-lite. This is what /contractor:propose invokes.
task-group-implement
Reads tasks.md (or whatever file the phase's tracks: field names) and expands the phase into one agent sub-step per incomplete task-group. Each sub-step gets its own runs row, its own log, and a system prompt scoped to that single group's unchecked checkboxes. The pipeline enforces commit-per-group: a sub-step that exits without a new commit is treated as failure.
The strategy template inlines the testing partial into a verify-block region of the prompt. When contractor/partials/testing.md is empty or missing, the block is stripped and the agent receives the stack-agnostic prose instead.
Used by: the implement phase in both contractor-base and contractor-lite.
parallel-agents
Renders the phase's agents: list as N agent sections, one per declared sub-agent. The runner spawns each sub-agent in parallel against the same diff and aggregates their findings into a single consolidated report.
Used by: the review phase in contractor-base. The four sub-agents are reuse, quality, efficiency, and blueprint-compliance.
agent
The pass-through strategy: it emits the phase's instruction: field verbatim as the system prompt, with no template wrapping. Use this for phases that do not need fan-out, sub-agents, or partial inlining — typically a single-agent prompt with a fixed playbook.
Used by: the close phase in both schemas, and the review phase in contractor-lite (single-agent review by design).
rebase-review
Renders a rebase-aware system prompt that primes the agent for post-rebase artifact reconciliation: comparing the blueprint's delta specs against the global requirements that landed during the rebase, and updating proposal/requirements/design/tasks where the rebase invalidated their premises.
Used by: the rebase phase in contractor-base. Today the rebase phase is not in the default pipeline — invoke it via a custom pipeline or directly via contractor blueprint phase <name> rebase.
Phase-to-strategy mapping today
| Schema | propose | implement | review | rebase | close |
|---|---|---|---|---|---|
contractor-base | artifact-loop | task-group-implement | parallel-agents | rebase-review | agent |
contractor-lite | artifact-loop | task-group-implement | agent | — | agent |
Strategies are a closed set — adding a new one is a CLI code change, not a YAML edit. Forking a schema lets you re-mix existing strategies (for example, swapping task-group-implement for agent to disable per-group fan-out), but it does not let you author new strategy templates from a schema YAML alone.