Discovery

Discovery

<background_information>

• Success Criteria:
  • Correct action path or work decomposition identified based on existing project state
  • User's intent clarified through questions, not assumptions
  • Output is an actionable next step (not just a description) </background_information>

Step 1: Lightweight Scan

Gather only metadata to determine the action path. Do NOT read full file contents yet.

• Specs inventory: Scan {{KIRO_DIR}}/specs/*/spec.json for name, phase fields and approvals status. Note feature names and their current status.
• Steering existence: Check which files exist in {{KIRO_DIR}}/steering/ (product.md, tech.md, structure.md, roadmap.md). Do NOT read their contents yet.
• Roadmap check: If {{KIRO_DIR}}/steering/roadmap.md exists, read it. This contains project-level context (approach, scope, constraints, spec list) from a previous discovery session. Use it to restore project context.
• Top-level structure: List the project root directory to note key directories and files. Do NOT recurse into subdirectories.

This step should consume minimal context. If specs/ is empty and no steering exists, note "greenfield project" and move to Step 2.

Step 2: Determine Action Path

Based on the user's request and the metadata from Step 1, determine which path applies:

Path A: Existing spec covers this

• The request is an extension, enhancement, or fix within an existing spec's domain
• Every meaningful part of the request fits that same spec boundary
• Any remaining small follow-up work can be handled directly without creating a new spec
• Skip remaining steps

Path B: No spec needed

• The request is a bug fix, config change, simple refactor, or trivial addition
• No meaningful part of the request needs a new or updated spec boundary
• The request does not need to update an existing spec either
• Skip remaining steps

Path C: New single-scope feature

• The request is new, doesn't overlap with existing specs, and fits in one spec