| name | sdd-explore |
| description | Use when the user wants to think through ideas, investigate problems, or clarify requirements before or during any SDD path. Triggers: "explore", "think through", "help me figure out", "what should I build", "I'm not sure where to start", "let's brainstorm", "investigate this", "I want to explore". |
SDD Explore
Thinking partner for spec-driven development.
No fixed steps, no mandatory output.
Available before or during any SDD path.
SPECS_ROOT is resolved by the sdd router before this skill runs.
Replace .specs/ with your project's actual specs root in all paths below.
Invocation Notice
- Inform the user when this skill is being invoked by name:
sdd-explore.
When to Use
- Before starting any SDD workflow — explore before speccing
- When requirements are unclear and writing a spec would be premature
- During change work when a decision blocks progress
- When you want to investigate the codebase before deciding what to spec
When Not to Use
- You already know what to build — jump to
sdd-propose or sdd-derive
- You have existing specs to convert — use
sdd-translate
Hard Rule: No Code
Never write or implement code in this skill.
Reading files and searching the codebase is fine — that's investigation.
Writing SDD artifacts (proposals, designs, specs) is fine — that's capturing thinking.
Writing implementation code is not allowed.
Approach
Start with the user's question
Ask: what are you trying to figure out?
Common entry points:
- "I want to understand how X works before speccing it"
- "I'm not sure if this should be one change or two"
- "I need to figure out the right capability breakdown"
Read existing context
Before forming opinions:
- Check
SPECS_ROOT/specs/ for existing baseline specs
- Check
SPECS_ROOT/changes/ for active changes
- Read relevant code files if the user wants codebase investigation
One-time suggestion (codebase investigation only): If the user wants to investigate the codebase, check SPECS_ROOT/.sdd/suggested-tools.
- If
code-review-graph is not listed: present the suggestion below, then append code-review-graph to that file (create the file and directory if needed).
Do this once and only once.
- If already listed: skip the suggestion.
Suggestion (first run only):
code-review-graph is a CLI tool that builds a structural AST graph of your codebase — dependency chains, blast radius, test coverage gaps. Useful for surfacing non-obvious architecture before speccing. Install: uv tool install code-review-graph. Say "skip" to dismiss. This won't appear again.
Thinking tools
Use freely:
- ASCII diagrams for architecture and flows
- Decision tables for tradeoffs
- Lists of forces for or against an approach
- Stakeholder maps, actor lists
- Numbered alternatives with tradeoffs
- Graph-aided investigation (if
code-review-graph is installed) — blast-radius queries, dependency chains, test coverage gaps.
Run code-review-graph build then query by capability entry point.
Crystallization
When thinking becomes clear enough to act:
- Offer to create an artifact: "Want me to capture this as a proposal?"
or "Should I sketch a design?"
- Route to the right skill:
sdd-propose, sdd-derive, sdd-translate
- Don't force it — the user decides when thinking is done
Output
No required output.
May produce:
- Notes, summaries, or decision records (in the conversation)
- SDD artifacts if the user decides to capture decisions (proposal.md, design.md)
- A recommendation for which SDD skill to run next
What You Don't Have To Do
- Follow a script
- Ask the same questions every time
- Produce a specific artifact
- Reach a conclusion
- Stay on topic if a tangent is valuable
- Be brief — this is thinking time
Common Mistakes
- Writing implementation code (forbidden)
- Treating explore as a required step — it's optional, not a gate
- Forcing an artifact when the user just wants to think
- Not reading existing specs before forming opinions about the domain
