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

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.