End-to-end feature pipeline. Orchestrates work across API service repos, frontend, mock server, and infrastructure repos as defined in the workspace config.
-
Read the workspace config first. Resolve the config path:
- If
--workspace=<slug> was passed: use {workspace_root}/{slug}/config.json
- If not passed: resolve
{workspace_root} via node {plugin}/scripts/workspace-root.js --get and scan {workspace_root}/*/config.json. If exactly one exists, use it. If multiple exist, list them and ask the user to pick.
- If none exist, print the detailed "missing config" block below and stop — do NOT proceed to Phase 1.
Parse the JSON. Validate with node {plugin}/scripts/validate-config.js {config-path}. If validation fails, report errors and stop. All repo paths, service mappings, spec file locations, and domain context come from this config — nothing is hardcoded.
Missing-config stop message (print verbatim, adapted to the user's scan results):
✗ No workspace config found.
/deliver requires a workspace configuration file at
{workspace_root}/{slug}/config.json
I scanned {workspace_root}/ and found none. The workspace config is
produced by /discover, which also generates several other artifacts
that /deliver depends on.
Recommended: run /discover first
/discover /path/to/your/repos
/discover takes about 5-15 minutes and produces:
• config.json — this file (hard requirement)
• context/platform.md — architecture context for Phase 2 (hard requirement)
• CLAUDE.md per repo — implementer orientation (soft; skip → 3-5× token cost per dispatch)
• agent-context/ per repo — deep architecture docs (soft; skip → implementer re-reads code each run)
• context/audit-findings.md — real bugs spotted during onboarding (soft; skip → Phase 4.5 has fewer anti-patterns to inject)
• Workspace agents ({slug}-product-owner, assessor, troubleshooter) — tailored to your domain
You can hand-write config.json + context/platform.md and run /deliver
against them directly, but the other artifacts are soft-optional and
each one degrades /deliver quality in a specific way:
- No CLAUDE.md → implementers guess conventions per dispatch; PRs become less consistent
- No agent-context → no "similar feature" catalog; implementers re-derive architecture
- No audit-findings.md → Phase 4.5 `## Known Anti-Patterns` uses plugin stack catalog only, not your workspace's observed bugs
- No workspace agents → falls back to generic agents with a preamble; product-owner loses domain context
If your workspace has zero existing repos (greenfield): run
/discover --greenfield
which brainstorms + scaffolds + discovers in one pass.
-
Config-driven phase auto-detection. After loading the config, derive which phases to run based on what repos exist — NOT based on assumptions about the workspace shape. Flags override auto-detection, not the other way around.
| Phase | Auto-runs if | Override flag |
|---|
| 3a (Contract Edit) | architect's AFFECTED_CONTRACTS is non-empty | --skip-spec-edit skips |
| 3b (Spec Edit) | architect found spec changes AND at least one affected service has spec_policy: api-first | --skip-spec-edit skips |
| 4 (Spec Sync) | user opts in at the Phase 3 approval gate | default OFF — skipped unless the user answers "yes" to the spec-sync follow-up at the Phase 3 gate. Auto-skipped (and the gate question is suppressed) when no repo has spec_copies referencing any affected service — there are no sync targets to ask about. |
| 5a (Backend) | config has repos with role: "api-service" | --frontend-only skips |
| 5b (Frontend) | config has repos with role: "frontend" | --backend-only skips |
| 5c (Mock) | config has repos with role: "mock-server" | --no-mock skips |
| 5d (Infra) | config has repos with role: "infrastructure" AND architect flags it | --with-infra forces |
| 5.5 (Review) | any Phase 5 task ran | --no-review skips |
| 5.75 (Security) | keyword trigger or --force-security-review | --no-security skips |
| 6 (Assess) | 2+ repos modified during Phase 5 AND the architect's cross_repo_integration flag is true (or absent — conservative fallback). Skip if only 1 repo changed (the reviewer covers it) OR if 2+ repos changed but cross_repo_integration=false (standalone scope — nothing cross-repo to assess; e.g. bundled-independent changes or the same maintenance applied to several services). Note the skip reason. See phase-6-assess.md spin-up decision. | — |
| 7 (Report) | always | — |
| 8 (Publish + Wrap-up) | always (Step 8.6 feedback offering); PR publish steps within Phase 8 only if --with-pr AND no Phase 6 blockers | --with-pr enables PR publish; --publish-despite-blockers overrides blocker gate; --no-feedback-prompt skips Step 8.6 |
Store the derived phase plan in the scratchpad's Architecture Flags section. Log: "Auto-detected phases: {list}. Skipped: {list with reasons}."
-
Pre-flight check — verify all repo paths from the config exist on disk. Report missing repos and stop.
3.5. Pull shared memory (only if config.workspace.memory.enabled) — read the team's latest workspace knowledge before planning: node {plugin_dir}/scripts/sync-memory.js pull {workspace_root}/{slug}. Warn-only: a dirty tree or fetch failure skips the pull (the run uses the local copy) and never blocks /deliver. Skip silently when memory is off.
-
Per-run isolation. Each feature run has its own directory under the workspace:
{workspace_root}/{slug}/runs/deliver/
└── {run_id}/ ← THIS run's {run_dir} (run_id = {YYYY-MM-DD-HHMMSS}-{feature-slug})
├── scratchpad.md lean phase index
├── checkpoints.jsonl unified event log (see rules/observability.md)
├── outputs/
├── tasks/
├── review/ per-repo code-review reports
├── security-review.md (optional — --force-security-review)
├── assessment.md Phase 6 output
├── fix-rounds/ (optional — per fix-round artifacts)
└── report.md Phase 7 final report
The timestamp prefix of {run_id} makes sibling dirs chronologically sortable — no separate active/ or completed/ split. In all phase files, {run_dir} resolves to {workspace_root}/{slug}/runs/deliver/{run_id}/. See phases/pre-flight.md for run_id computation + directory creation. Update the scratchpad immediately after every phase completes.
-
User approval gates — pause after Phase 1 (requirements), Phase 2 (architecture), Phase 3 (spec changes), Phase 4.5 (implementation plan), Phase 5b UX consultant (before launching feature-implementer), and Phase 5.5 code review (only for repos with critical issues that need approval — the gate asks whether to dispatch a fix round. Reviewers run as background dispatches and are processed per-repo as each finishes: a repo needing no approval (gates disabled, or --auto-fix-mechanical set AND that repo's criticals all mechanical) dispatches its fix round immediately; a repo needing approval gets its own focused gate the moment its reviewer finishes — one prompt per critical-finding repo as findings arrive, NOT one consolidated prompt after the slowest reviewer. Only one gate is open at a time. See phase-5.5-code-review.md Step 2).
At EVERY gate, surface the wait to the UI: before asking the user, run node {plugin_dir}/scripts/gate.js open --run-dir={run_dir} --phase={N} --gate=approval --question="..." [--context="..."]. After receiving the user's answer, run node {plugin_dir}/scripts/gate.js close --run-dir={run_dir}. This drives the yellow "waiting for input" banner in the pipeline-view UI and the ⏸ prefix in the browser tab title — essential when the user has the UI open in a second monitor and is working elsewhere. Forgetting to close leaves the banner stuck; treat open/close as mandatory bracketing around every gate. Full gate contract + label catalog in {plugin_dir}/docs/site-view.md.
-
Parallel execution — Phases 5a, 5c, 5d run in parallel via background agents. Phase 5b runs sequentially (UX → user gate → implementer) but can run in parallel with 5a/5c/5d.
-
Section extraction — extract architect output sections using <!-- BEGIN X --> / <!-- END X --> delimiters. Product-owner output also uses these delimiters.
-
Clarification questions — product-owner and solution-architect agents will ask questions. Present them to the user and pass answers back.
-
Spec editing — delegated to openapi-spec-editor — Phase 3 dispatches the openapi-spec-editor agent via the Agent tool to apply the approved technical design's API_DESIGN section to each affected spec file in the architect's declared order. The agent reads each spec, applies edits in place on the current branch, verifies YAML well-formedness, and returns a structured diff summary per service. The orchestrator never reads spec files directly — it reads only the agent's diff summary.
Rollback on rejection: if the user rejects at the Phase 3 approval gate, the orchestrator runs git checkout <spec-file> for each modified spec in each affected service repo to revert, then either stops the pipeline or re-dispatches openapi-spec-editor with updated instructions based on the user's feedback. The agent does not handle rollback itself — that's strictly an orchestrator responsibility.
-
In-session Agent tool dispatch — NEVER claude -p. See phases/dispatch-rules.md for the full TYPE_TO_AGENT mapping table, worktree creation steps, and parallel dispatch rules. Load that file before Phase 4.5.
- Worktrees default ON. Phase 3 creates worktrees for spec-owning repos; Phase 5 reuses them and creates more for repos not touched in Phase 3. Agents always work in the worktree path — never the main repo checkout.
--no-worktrees opts out (see flag table).
- Workspace agents: Phase 1 / Phase 6 dispatch by slug-prefixed name (
{slug}-product-owner, {slug}-assessor; {slug}-troubleshooter for /troubleshoot). Onboarding Phase C Step 3 publishes these to ~/.claude/agents/ so they resolve as first-class subagent_types. If not found, phases fall back to general-purpose with a preamble that reads the canonical copy at {workspace_root}/{slug}/agents/{role}.md. Phase 5b UX is the exception — it dispatches the base pipecrew:ux-consultant (not workspace-generated), the same agent that authored the design system at discovery.
-
Context hygiene — after dispatching Phase 5 agents, do NOT re-reference Phase 1/2 outputs from conversation history. Use the scratchpad output files when Phase 6 needs them.
-
Agent naming — name agents by their role, not their phase number. E.g., "Backend implementer — publisher-service" not "Phase 5a: Backend implementation".
-
SendMessage for follow-ups — if an agent returns incomplete output, use SendMessage to continue the existing agent rather than spawning a new one.
-
Execution tracking + task management — see phases/dispatch-rules.md for the full tracking protocol (per-phase, per-dispatch, per-task metrics) and the task file contract (frontmatter schema, CRUD operations, context-lean rules). Load that file before Phase 4.5. Every Agent dispatch — background and inline (product-owner, solution-architect, openapi-spec-editor, ux-consultant included) — emits a paired agent_start (immediately before the call) and agent_end (on return) to checkpoints.jsonl; the leading agent_start is what drives the live "working" state and per-agent token display in the site-view.
-
Transient failures — every Agent dispatch in every phase follows the shared retry rules at {plugin_dir}/rules/transient-failures.md. Retry once on 529/503/network per the table, wait per retry-after on 429, halt on a second 429 or any non-429 4xx. Emit retry + follow-up agent_end events per rules/observability.md. On parallel dispatch, retry only the failed agent — let the rest of the batch finish. Deferred agents block advancing to the next gating phase until the user resumes or approves continuing without them.
-
Emit a one-line phase-done status in chat — immediately after phase_end and scratchpad update, print exactly one line in the format:
[phase {CODE} ✔] {what-was-produced} ({metrics})
Examples:
[phase 1 ✔] requirements document (FR×8 / EC×3, 12k tokens, 2:10)[phase 2 ✔] technical design — 4 services, 7 endpoints (28k tokens, 4:03)[phase 3 ✔] spec edits applied to 3 services (3:12)[phase 5a ✔] publisher-service backend complete — 12 files changed (94k tokens, 8:12)[phase 5.5 ✔] 3 reports — 2 critical, 5 non-critical (24k tokens, 5:20)[phase 6 ✔] assessment PASS (18k tokens, 6:18)
Gives users a greppable progress signal without forcing them to open the scratchpad. One line per phase — no trailing commentary. After the line, proceed to the next phase (or wait for an approval gate if the phase is gated).
Partial failure or user-rejected gate gains a ⚠ suffix and one extra line:
[phase 5a ✔⚠] 2 services complete, 1 deferred (80k tokens, 7:40)
Deferred: backoffice-service (529 after retry) — re-run /deliver --resume
Zero-dep Node — prefer over LLM parsing. Phase files cite the specific script at point of use; this is the discoverability index.
