The composer pipeline

Composer drives a task end to end. It picks the next ready task off the critical path, dispatches four subagents in sequence, propagates the result through the graph, and loops until the queue is empty or you stop it.

The orchestrator is glue. It picks tasks, hands off, and propagates. The heavy lifting lives in the four phase agents, each dispatched in a fresh context with a focused tool set.

Commands

• /piyaz:composer runs backlog mode: the orchestrator picks the highest-value ready task each iteration and keeps going.
• /piyaz:composer <taskRef> runs single-task mode, for example /piyaz:composer ZIN-42. Same pipeline, one task, then exit.

The four phases

research → plan → implement → review

Research

The researcher reads the target task, maps it to the codebase (files to touch, patterns to reuse, tests that cover them), checks current library docs against the project's pinned versions, audits the project's conventions (commit format, test/lint/typecheck commands, PR template), and reasons about security, performance, reliability, and observability.

It writes refinements directly back to the task: a sharper description, binary acceptance criteria, missing tags, an accurate estimate. It returns a research brief but never writes status, implementationPlan, executionRecord, or files. Substantive scope rewrites are proposed, not applied; the orchestrator gates those with you before the planner runs.

Plan

The planner reads the refined task and the brief, then writes the unabridged implementationPlan: goal, files to modify, build sequence, edge cases, verification commands, acceptance-criteria mapping. It is the only phase that writes the draft → planned transition, and it writes it in the same call as the plan. It edits no code.

Implement

The implementer reads the plan from piyaz_context depth='agent', claims the task (planned → in_progress), implements on a feature branch, runs the project's tests, typecheck, and lint until green, and opens a PR using the project's template with the [<taskRef>] bracket form. It then marks the task in_review with the full Completion Protocol payload (executionRecord, decisions, files, evaluated acceptance criteria). It does not merge, and it does not write done.

Review

The reviewer reads piyaz_context depth='review', which renders the plan alongside the execution record, surfaces the PR link, and computes plan-vs-files drift. It returns a structured verdict (approve, request-changes, or block) with file-cited reasoning across five lenses: security, performance, reliability, observability, and codebase standards. Review is read-only over Piyaz; the verdict travels in the return message, not in any task field. See Human in the loop.

Why a fresh context per phase

Each phase is a separate dispatched agent, not one long-running agent wearing four hats. It applies the same context discipline the task graph uses at the project level to a single task:

• Each agent gets a clean context window and only the tools its phase needs. The researcher cannot edit code; the reviewer cannot write to Piyaz.
• Dispatch payloads stay small because the task row is the source of truth. The researcher's refinements and the planner's plan land on the task, and the implementer reads both from it. Nothing is re-passed between phases.

Where the human gate sits

Composer never flips a task to done. The implementer's terminal write is in_review. After the PR is approved, the human operator moves the task in_review → done. The reviewer's verdict is advisory: the orchestrator surfaces it verbatim and does not treat request-changes or block as a retry signal. The operator owns the next move.