Run the full brownfield discovery pipeline (A1–A7) automatically without manual next commands. Executes all 7 steps in sequence, skipping steps whose output already exists. Use this after /scan when approach is brownfield.
Run the full brownfield capability extraction pipeline automatically. Do NOT wait for user confirmation between steps unless a step requires interactive input.
project.json → approach = "brownfield"..discovery/context.json. If missing, tell the user to run /scan first and stop. Use this file as the source of truth for codebase path, language, architecture, and database presence..discovery/pipeline.lock.json already exists.
/discover first to initialize the pipeline, then stop..discovery/pipeline.lock.json to identify which steps are pending.Say: "Running brownfield discovery..."
Execute each step listed in the table below, in order, from top to bottom.
For each step:
.discovery/pipeline.lock.json. If the step status is "completed" or "skipped", print " ✔ {output file} already exists — skipping" and move to the next step immediately."in_progress" in .discovery/pipeline.lock.json."completed" in .discovery/pipeline.lock.json with completed_at set to the current UTC timestamp..project/state/workflow.json → step to the next step name (not prd yet)." ✔ {display label}".bootstrap-next or wait for user input."failed" in .discovery/pipeline.lock.json with an error field describing what went wrong." ✗ {display label} — {error summary}".| Step | Skill | Output | Display Label |
|---|---|---|---|
seed_candidates | discover-candidates | docs/discovery/candidates.md | Capability candidates extracted |
analyze_candidates | analyze-candidates | docs/discovery/analysis.md | Candidates analyzed |
verify_coverage | verify-coverage | docs/discovery/coverage.md | Coverage verified |
lock_l1 | lock-l1 | docs/discovery/l1-capabilities.md | L1 capabilities locked |
define_l2 | define-l2 | docs/discovery/l2-capabilities.md | L2 sub-capabilities defined |
discovery_domain | generate-discovery-domain | docs/discovery/domain-model.md | Domain model built |
blueprint_comparison | compare-blueprint | docs/discovery/blueprint-comparison.md | Blueprint comparison complete |
After each state change, edit .discovery/pipeline.lock.json directly.
Mark in_progress:
{ "status": "in_progress" }
Mark completed:
{ "status": "completed", "output": "docs/discovery/{file}.md", "completed_at": "{ISO timestamp}" }
Mark failed:
{ "status": "failed", "output": "docs/discovery/{file}.md", "error": "{error description}" }
If any step reveals ambiguous information that requires user clarification:
Examples of when to ask:
.project/state/workflow.json:
{ "step": "prd", "status": "in_progress" }
project.json → step to "prd".Discovery pipeline finished.
✔ Capability candidates extracted
✔ Candidates analyzed
✔ Coverage verified
✔ L1 capabilities locked
✔ L2 sub-capabilities defined
✔ Domain model built
✔ Blueprint comparison complete
7 artifacts generated in docs/discovery/. Ready for PRD generation.
/generate to produce the project specification documents.""completed" or "skipped"bootstrap-next between steps — this skill manages workflow state directly