demand-pipeline

For requirements too big to hand a coworker as one brief: a fixed sequence of stages, each run by an independent sub-agent that sees only its own stage's input, not the whole conversation history. Context isolation is the point — a stage that inherits every prior decision tends to rubber-stamp them instead of evaluating the requirement fresh.

Arguments: $ARGUMENTS

• Full pipeline: demand-pipeline <requirement description or path to a written requirement>
• Single stage: demand-pipeline breakdown <requirement> | design <breakdown_doc_path> | implement <design_doc_path> | verify <task_or_pr>

Context isolation rule (mandatory, every stage)

Each stage is dispatched as an independent sub-agent (a fresh coworker, or an isolated sub-agent call if your CLI supports one). The dispatch prompt for a stage may contain only:

1. A short role description for that stage (below), or a pointer to a role file.
2. The one input document for that stage — a file path or pasted text.
3. The one output the stage must produce — a file path and its required structure.

Do not fold in the parent session's other conversation, unrelated files, or "context you already have" — a sub-agent that doesn't independently re-derive the plan from the stated input isn't providing isolation, just a second read of the same reasoning.

Stage 1 — Breakdown

Role: turn a raw requirement into a scoped demand doc — what's being asked, who it's for, what's explicitly out of scope, and which project(s) it likely touches (cross-reference docs/portfolio.md via route, but don't delegate execution yet — this stage only scopes).

Input: the raw requirement (file path or pasted text). Output: docs/plans/<demand-id>_demand.md — problem statement, in/out of scope, affected project(s), open questions. Choose <demand-id> from the requirement (short slug); check it doesn't collide with an existing plan file.

Stage 2 — Design

Role: produce the technical/task design — architecture or approach, a task breakdown table (project, task, acceptance criteria), and the risks worth flagging before anyone writes code.

Input: docs/plans/<demand-id>_demand.md only. May consult docs/portfolio.md and each affected project's agents/<project>.md to understand ownership and constraints — nothing else. Output: docs/plans/<demand-id>_design.md with an explicit task-breakdown table.

Stage 3 — Review

Role: an adversarial second opinion — a fresh sub-agent with no stake in the design it's reviewing (the reviewer persona itself isn't a role contract this repo defines; any capable sub-agent call or fresh session works). Checks the design for soundness, missing risks, and whether the task breakdown is actually implementable as written. Concludes approved or needs revision, never a silent pass-through.

Input: docs/plans/<demand-id>_design.md only. Output: docs/plans/<demand-id>_review.md — conclusion +, if needs revision, the specific revision items.

• If needs revision: send the revision items back to stage 2 with both _design.md and _review.md as input; produce an updated _design.md; re-run stage 3. Do not proceed to implementation on an unapproved design.
• If approved: proceed to stage 4.

Stage 4 — Implement (context-isolated per task)

Role: execution. Read the task-breakdown table from the approved _design.md and, for each task, dispatch it via route (or a direct delegation) with only that task's description + acceptance criteria + owning project — not the full demand or design doc. This is what keeps a 5-task design from becoming one coworker's 5-page mega-brief (the exact anti-pattern docs/delegation.md warns against).

Write each task into its owning project's docs/tasks/<project>.md before dispatch, so it's durable even mid-pipeline.

Stage 5 — Verify

Role: confirm each implemented task actually meets its stated acceptance criteria — run it, don't just read the diff (see the verify skill / verify-by-interaction-not-proxy discipline). Roll up per-task verification into one pipeline completion report: which tasks passed, which didn't, and what's still open.

Single-stage invocation

Any stage can run alone (e.g. re-running design after a requirement changes). A single-stage call still goes through the same context-isolation rule — the dispatch prompt contains only that stage's declared input and output, nothing borrowed from a prior full-pipeline run.

Outputs and traceability

All stage docs land in docs/plans/<demand-id>_<stage>.md. Tasks written to a project's board during Stage 4 should carry the demand-id and the design-doc path, so a task on a board can always be traced back to the requirement that generated it.