Entry point for new work. Determines the best action path or work decomposition (update existing spec, create new spec, mixed decomposition, or no spec needed) and refines ideas through structured dia
The skill file stays in the publisher's repository.
Paste the copied command in a terminal. It installs this SKILL.md into that agent.
npx skills add gotalab/cc-sdd --skill kiro-discovery -a cursor -y
Entry point for new work. Determines the best action path or work decomposition (update existing spec, create new spec, mixed decomposition, or no spec needed) and refines ideas through structured dialogue.
Entry point for new work. Determines the best action path or work decomposition (update existing spec, create new spec, mixed decomposition, or no spec needed) and refines ideas through structured dialogue.
<background_information>
Gather only metadata to determine the action path. Do NOT read full file contents yet.
{{KIRO_DIR}}/specs/*/spec.json for name, phase fields and approvals status. Note feature names and their current status.{{KIRO_DIR}}/steering/ (product.md, tech.md, structure.md, roadmap.md). Do NOT read their contents yet.{{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.This step should consume minimal context. If specs/ is empty and no steering exists, note "greenfield project" and move to Step 2.
Based on the user's request and the metadata from Step 1, determine which path applies:
Path A: Existing spec covers this
Path B: No spec needed
Path C: New single-scope feature
Path D: Multi-scope decomposition needed
Path E: Mixed decomposition
For Path C/D/E, present the determined path (or mixed decomposition) to the user and confirm before proceeding. For Path A/B, recommend the next action and stop.
Only for Path C, D, and E. Now load the context needed for discovery.
In main context (essential for dialogue with user):
Delegate to sub-agent (keeps exploration out of main context):
Context budget: Keep total content loaded into main context under ~500 lines. The sub-agent handles the heavy exploration.
Ask clarifying questions sequentially (not all at once), prioritizing boundary discovery over feature detail:
Ask only questions whose answers you cannot infer from the context already loaded. Skip questions that steering documents already answer. If the user already provided a clear description, skip to Step 5. The goal is NOT to assign final owners yet. The goal is to discover the cleanest responsibility boundaries that can later become specs, tasks, and review scopes.
Propose 2-3 concrete approaches with trade-offs:
For each approach:
If technical research is needed (unfamiliar framework, library evaluation), spawn a sub-agent to research and return a concise summary. Ask it to compare options, check latest versions, and note known issues. Raw search results never enter the main context.
Recommend one approach and explain why.
After the user selects an approach, spawn a sub-agent to verify viability before proceeding to Step 6. Ask it to check: (1) Are these technologies still actively maintained? (2) Any license incompatibilities (e.g., GPL contamination)? (3) Do the components actually work together for the use case? (4) Any known showstoppers (critical bugs, security vulnerabilities, platform limitations)? Return only issues found, or "No issues found" if everything checks out.
If the viability check reveals issues, present them to the user and revisit the approach selection. If no issues, proceed to Step 6.
CRITICAL: You MUST write these files to disk BEFORE suggesting any next command. Conversation text does not survive session boundaries. If you skip this step, all discovery analysis is lost when the session ends.
For Path C (single spec):
Write {{KIRO_DIR}}/specs/<feature-name>/brief.md to disk with this structure:
# Brief: <feature-name>
## Problem
[who has the problem, what pain it causes]
## Current State
[what exists today, what's the gap]
## Desired Outcome
[what should be true when done]
## Approach
[chosen approach and why]
## Scope
- **In**: [what this feature includes]
- **Out**: [what's explicitly excluded]
## Boundary Candidates
- [responsibility seam 1]
- [responsibility seam 2]
## Out of Boundary
- [explicit non-goals this spec does not own]
## Upstream / Downstream
- **Upstream**: [existing systems/specs this depends on]
- **Downstream**: [likely consumers or follow-on specs]
## Existing Spec Touchpoints
- **Extends**: [existing spec(s) this work updates, if any]
- **Adjacent**: [neighbor specs or modules to avoid overlapping]
## Constraints
[technology, compatibility, or other constraints]
For Path D (multi-spec decomposition):
Write these to disk:
{{KIRO_DIR}}/steering/roadmap.md{{KIRO_DIR}}/specs/<feature>/brief.md for every feature listed under ## Specs (dependency order)Use this roadmap structure:
# Roadmap
## Overview
[Project goal and chosen approach -- 1-2 paragraphs]
## Approach Decision
- **Chosen**: [approach name and summary]
- **Why**: [key reasoning]
- **Rejected alternatives**: [what was considered and why it was rejected]
## Scope
- **In**: [what the overall project includes]
- **Out**: [what is explicitly excluded]
## Constraints
[technology, compatibility, timeline, or other project-wide constraints]
## Boundary Strategy
- **Why this split**: [why these spec boundaries improve independence]
- **Shared seams to watch**: [cross-spec boundaries needing careful review]
## Specs (dependency order)
- [ ] feature-a -- [one-line description]. Dependencies: none
- [ ] feature-b -- [one-line description]. Dependencies: feature-a
- [ ] feature-c -- [one-line description]. Dependencies: feature-a, feature-b
Then write {{KIRO_DIR}}/specs/<feature>/brief.md for every feature listed under ## Specs (dependency order) using the Path C brief format. This enables parallel spec creation via /kiro-spec-batch.
For Path E (mixed decomposition):
Use the same roadmap structure as Path D, plus these additional sections:
## Existing Spec Updates
- [ ] existing-feature-a -- [one-line description of the extension]. Dependencies: none
- [ ] existing-feature-b -- [one-line description of the extension]. Dependencies: feature-a
## Direct Implementation Candidates
- [ ] small-item-a -- [why this stays direct implementation]
- [ ] small-item-b -- [why this stays direct implementation]
## Specs (dependency order)
- [ ] new-feature-a -- [one-line description]. Dependencies: none
- [ ] new-feature-b -- [one-line description]. Dependencies: new-feature-a
Path E rules:
## Specs (dependency order) reserved for new specs only so /kiro-spec-batch can still parse it unchanged## Existing Spec Updates## Direct Implementation Candidatesbrief.md only for the new specs listed under ## Specs (dependency order)Re-entry (roadmap.md already exists): Write the next new spec's brief.md to disk. Update roadmap.md if scope/ordering changed, preserving completed items and prior phases.
After writing, verify the files exist by reading them back.
Suggest the next command and stop. Do NOT automatically run downstream spec generation from this skill.
/kiro-spec-requirements {feature} to update the existing spec/kiro-spec-init <feature-name>
/kiro-spec-quick <feature-name> when the user explicitly wants to continue immediately/kiro-spec-batch (creates all specs in parallel based on roadmap.md dependency order)
/kiro-spec-init <first-feature-name> when the user wants to validate the first slice before batching the rest/kiro-spec-init <new-feature-name>/kiro-spec-batch/kiro-spec-requirements <feature>/kiro-spec-init <next-feature-name> or /kiro-spec-batch if multiple specs remainIf the decomposition contains only existing-spec updates plus direct implementation candidates, do NOT use Path E. Prefer Path A when one existing spec is the clear home, or recommend the existing-spec update plus direct implementation work without creating roadmap entries.
Roadmap Already Exists (re-entry):