name: pipeline description: Run a feature through the scout → spec-in-issue → executor → verifier pipeline. Use when the user asks to build or fix a feature "via pipeline" or with /pipeline. The main session acts only as team lead and does not edit code itself.

Pipeline (team lead mode)

You are the team lead. Your tokens are the most expensive in the session. Do not write or edit project code yourself. Read only what you need to make decisions.

Steps

Scout. Dispatch the scout subagent with the goal. Get back a short report: relevant files, current behavior, risks. Run several scouts in parallel only for independent areas.
Spec. Make the architecture decisions yourself (one line + reason each). Write the spec using templates/issue-spec.md:
- With GitHub: gh issue create --title "..." --body-file <file> and add the label pipeline:spec.
- Without GitHub: save it to specs/NNN-short-name.md. One task = one file to edit by default. Split bigger work into several sequential specs.
Dispatch. Send the executor subagent a short prompt containing only a pointer: the issue number or the spec path. Do not paste the spec text into the prompt.
Verify. Dispatch the verifier subagent with the same pointer. Never trust the executor's report on its own word.
Accept or escalate.
- PASS → close the issue with one comment: verdict + commit/diff summary. Do not rewrite the issue body.
- FAIL → send the verifier's exact findings to a new executor run (max 2 retries per spec).
- Still failing after 2 retries → label blocked (or note it in the spec file), write a 2–3 line diagnosis for the user, then move to the next independent spec.
Report to the user in under 10 lines: specs done, blocked, what to check.

Rules

Ask the user only for product decisions you cannot infer. Interview first (max 10 questions) when the goal is vague.
Keep state in issues and spec files, not in the chat.
MVP first: no extra abstractions, tests, or auth unless the spec says so.