Sdd Explore
Run read-only codebase and feature investigation before you commit to an implementation plan or spec change.
Overview
sdd-explore is an agent skill most often used in Validate (also Idea and Build) that read-only investigates an idea or codebase area before you commit to changes.
Install
npx skills add https://github.com/fearovex/claude-config --skill sdd-exploreWhat is this skill?
- Read-only investigation: analyzes ideas or codebase areas with no file writes or code changes
- Triggered via /sdd-explore <topic> and natural phrases like explore, investigate codebase, and research feature
- Resolves project-local .claude/skills/sdd-explore/SKILL.md before the global catalog fallback
- Step 0 loads shared SDD project context and spec preload from sdd-phase-common sections F and G
- Best when the request is complex, scope is unclear, or you need impact analysis across multiple approaches
- SKILL.md metadata version 3.0
- Step 0 references sdd-phase-common sections F (Project Context Load) and G (Spec Context Preload)
- Explicit read-only phase: creates no code and modifies nothing
Adoption & trust: 1 installs on skills.sh; 1 GitHub stars; 2/3 security scanners passed (skills.sh audits); trending (+100% hot-view momentum).
What problem does it solve?
You need to change something in the repo but the request is fuzzy, the blast radius is unclear, or several approaches could work and you do not want to code blindly.
Who is it for?
Solo builders running SDD or Claude Code who want a mandatory-style research pass before specs or edits when complexity or uncertainty is high.
Skip if: Skip when the change is already fully specified, trivial, and localized—you do not need a dedicated explore pass if impact and approach are obvious.
When should I use this skill?
/sdd-explore <topic>, explore, investigate codebase, research feature, or analyze before changing when the request is vague, scope is unclear, impact matters, or multiple approaches exist.
What do I get? / Deliverables
You get a structured, read-only picture of the relevant code, constraints, and viable approaches so you can choose scope and hand off to planning or implementation with confidence.
- In-session exploration findings and approach options
- Impact and dependency notes for downstream planning
- No repository file writes from the explore phase itself
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
The skill is the optional SDD exploration gate—scoped analysis before you lock scope and proceed to planning or coding—so validate/scope is the canonical shelf. Subphase scope fits narrowing impact, approaches, and unknowns when a request is vague or multi-path, without writing code yet.
Where it fits
Map how a new integration idea would touch existing modules before you write a one-pager or spec.
Size a vague feature request and list affected files and risks before locking validate scope.
Trace call paths through a service folder before choosing a refactor strategy.
Explore regression-sensitive areas linked to a planned change before opening a large PR.
How it compares
Use instead of opening files ad hoc in chat when you want a repeatable, read-only SDD exploration ritual before any writes.
Common Questions / FAQ
Who is sdd-explore for?
It is for solo and indie developers using agentic SDD workflows in Claude Code who want evidence-backed understanding before they edit code or finalize scope.
When should I use sdd-explore?
Use it in Validate to scope a fuzzy feature, in Idea when researching how an idea maps to the repo, and in Build when you must investigate a subsystem before a refactor—especially via /sdd-explore <topic> or phrases like investigate codebase and analyze before changing.
Is sdd-explore safe to install?
The skill is designed for read-only analysis, but you should still review the Security Audits panel on this Prism page and inspect SKILL.md in your project before granting broader agent permissions.
SKILL.md
READMESKILL.md - Sdd Explore
# sdd-explore > Investigates and analyzes an idea or area of the codebase before committing to changes. **Triggers**: `/sdd-explore <topic>`, explore, investigate codebase, analyze before changing, research feature --- ## Purpose The exploration phase is **optional but valuable**. Its goal is to understand the terrain before proposing changes. It creates no code and modifies nothing. It only reads and analyzes. Use it when: - The request is vague or complex - You are unsure of the scope of the change - You want to understand the impact before committing - There are multiple possible approaches --- ## Process ### Skill Resolution When the orchestrator launches this sub-agent, it resolves the skill path using: ``` 1. .claude/skills/sdd-explore/SKILL.md (project-local — highest priority) 2. ~/.claude/skills/sdd-explore/SKILL.md (global catalog — fallback) ``` Project-local skills override the global catalog. See `docs/SKILL-RESOLUTION.md` for the full algorithm. --- ### Step 0 — Load project context + Spec context preload Follow `skills/_shared/sdd-phase-common.md` **Section F** (Project Context Load) and **Section G** (Spec Context Preload). Both are non-blocking. ### Step 0 sub-step — Handoff context preload This sub-step is **non-blocking**: any failure (missing file, unreadable file, no slug) MUST produce at most an INFO-level note. This sub-step MUST NOT produce `status: blocked` or `status: failed`. 1. Resolve the change slug from the invocation context. 2. Check whether a proposal already exists in engram: `mem_search(query: "sdd/<slug>/proposal")`. 3. If absent: skip silently — log `INFO: no pre-seeded proposal found — proceeding without handoff context.` 4. If present: retrieve via `mem_get_observation(id)`. Treat its content as **supplemental intent enrichment**: - It informs what the explore should prioritize, not what the codebase shows. - It MUST NOT override live codebase findings. - Log: `Handoff context loaded from engram: sdd/<slug>/proposal` 5. When loaded, include a `## Handoff Context` section in the exploration output (placed before `## Current State`) summarizing: - Decision that triggered the change - Goal and success criteria from the seeded proposal - Explore targets listed in the proposal - Constraints ("do not do" items) --- ### Step 1 — Understand the request I classify what type of exploration is needed: - **New feature**: What already exists? Where would it fit? - **Bug**: Where is the problem? What is the root cause? - **Refactor**: What code is affected? What are the risks? - **Integration**: What exists to connect? What is missing? ### Step 2 — Branch Diff scan This step is **non-blocking**: any failure (git unavailable, no working tree, empty diff) MUST produce at most an INFO-level note. This step MUST NOT produce `status: blocked` or `status: failed`. 1. Run `git status --short` to identify modified, staged, and untracked files in the current working tree. 2. Filter results to files relevant to the domain being explored (match by path prefix, filename, or keyword overlap with the change name). 3. Classify each file as: `modified`, `staged`, `deleted`, or `untracked`. 4. Write output to the `## Branch Diff` section. **If git is unavailable or diff is empty**: log `INFO: branch diff unavailable or empty — skipping Branch Diff section` and include an empty `## Branch Diff` section with that note. **Output format:** ``` ## Branch Diff Files modified in current branch relevant to this change: - path/to/file.ts (modified) - path/to/other.ts (staged, pending deletion) - path/to/new-file.ts (untracked) ``` ### Step 3 — Prior Attemp