plugins/developer-kit-specs/skills/specs-explore/SKILL.md
Explore codebase before committing to a change. Phase executor skill for specs.explore command.
npx skillsauth add giuseppe-trisciuoglio/developer-kit specs-exploreInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Investigate the codebase, think through problems, compare approaches, and return a structured analysis. Only create exploration.md when --spec is provided.
The orchestrator will give you:
--spec path (optional)--lang framework (optional)Parse what the user wants to explore:
Read relevant code to understand:
INVESTIGATE:
├── Read entry points and key files
├── Search for related functionality (Grep)
├── Check existing tests (Glob)
├── Look for patterns already in use
└── Identify dependencies and coupling
If there are multiple approaches, compare them:
| Approach | Pros | Cons | Complexity | |----------|------|------|------------| | Option A | ... | ... | Low/Med/High | | Option B | ... | ... | Low/Med/High |
--spec is provided)If --spec=docs/specs/001-add-jwt-auth is specified, write to docs/specs/001-add-jwt-auth/exploration.md:
## Exploration: {topic}
### Current State
{How the system works today relevant to this topic}
### Affected Areas
- `path/to/file.ext` — {why it's affected}
- `path/to/other.ext` — {why it's affected}
### Approaches
1. **{Approach name}** — {brief description}
- Pros: {list}
- Cons: {list}
- Effort: {Low/Medium/High}
2. **{Approach name}** — {brief description}
- Pros: {list}
- Cons: {list}
- Effort: {Low/Medium/High}
### Recommendation
{Your recommended approach and why}
### Risks
- {Risk 1}
- {Risk 2}
### Ready for Proposal
{Yes/No — and what the user should know}
Return the same structured analysis (inline), plus:
Status Report:
done | blocked | partial{spec}/exploration.md (if --spec provided) or "none"specs.brainstorm (if spec provided) or none (if standalone)exploration.md inside the spec folder (if --spec provided)development
Executes real end-to-end verification against a running application after specification implementation. Detects the application type, starts the local runtime (Docker, Node, Spring Boot, etc.), runs real tests (curl for REST APIs, Playwright for web SPAs, computer-use for desktop apps), verifies acceptance criteria from the functional specification, generates a markdown report, and tears down the environment. Use when: user asks to verify a completed spec with real tests, run e2e checks after implementation, validate acceptance criteria in a live environment, or test the feature for real after task completion.
development
Initialize Spec-Driven Development context — detects tech stack, conventions, architecture patterns, and bootstraps persistence backends. Triggers on 'sdd-init', 'init sdd', 'setup sdd', 'initialize sdd', 'setup project', 'initialize project context'. Creates/updates docs/specs/architecture.md & ontology.md (Constitution), and populates knowledge-graph.json.
development
Optimizes raw idea descriptions into structured prompts ready for the brainstorming workflow. TRIGGER when: user says "optimize for brainstorm", "prepare idea for brainstorm", "enhance this idea", "make this ready for brainstorming", "imposta per brainstorm", or wants to improve a feature idea before using /specs.brainstorm. DO NOT TRIGGER for code optimization, refactoring, or general prompt engineering tasks.
testing
Posts review findings from a JSON file as inline comments on a GitHub Pull Request, attaching each comment to its file and line. Use when you have a list/JSON of review findings (each with a file path, line number, and a message such as summary/failure_scenario) and want them published on a PR as inline review comments. Triggers include "post these review comments on the PR", "associate comments to files in the PR", "publish review findings to PR