Run Discovery Pipeline

For each step:

1. Read .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.
2. Mark the step as "in_progress" in .discovery/pipeline.lock.json.
3. Run the corresponding skill listed in the table.
4. On success:
   • Mark the step as "completed" in .discovery/pipeline.lock.json with completed_at set to the current UTC timestamp.
   • Update .project/state/workflow.json → step to the next step name (not prd yet).
   • Print " ✔ {display label}".
   • Continue immediately to the next step — do NOT call bootstrap-next or wait for user input.
5. On failure:
   • Mark the step as "failed" in .discovery/pipeline.lock.json with an error field describing what went wrong.
   • Print " ✗ {display label} — {error summary}".
   • STOP. Do not continue to the next step.
   • Tell the user what failed and how to fix it, then re-run this skill to resume.

Updating the Lock File

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}" }

Interactive Fallback

If any step reveals ambiguous information that requires user clarification:

• Ask the question directly in the chat
• Wait for the user's response
• Incorporate the answer and continue with the pipeline
• Do NOT abandon the pipeline on interactive prompts

Examples of when to ask:

• A capability candidate spans two domains and the boundary is unclear
• Architecture pattern is ambiguous and affects capability grouping

After All Steps Complete

1. Update .project/state/workflow.json:

   { "step": "prd", "status": "in_progress" }
   

2. Update project.json → step to "prd".
3. Print the completion summary:

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.

4. Tell the user: "Run /generate to produce the project specification documents."

Rules

• Read pipeline.lock.json before starting to resume from the first non-completed step
• Never re-run a step that is "completed" or "skipped"
• Stop immediately on failure — log the error, update the lock, do not continue
• Update pipeline.lock.json after every state change (in_progress → completed or failed)
• Do not modify the target codebase — this pipeline is read-only on the analyzed code
• Do not call bootstrap-next between steps — this skill manages workflow state directly