explore

/explore — map the terrain before designing

Designing without exploring produces options grounded in general priors rather than the actual terrain — they look reasonable in the abstract but don't fit how this codebase / client / domain actually works.

This skill enforces a discipline: before any design step, systematically map what's already there. Existing patterns, hard constraints, hooks, things that would surprise you if you weren't looking.

Tooling

Match the tool to the operation, not the domain:

• Autonomous breadth-y exploration — spawn the Explore subagent: one when scope is known, several in parallel when scope is uncertain or spans subsystems. Each agent gets a distinct search focus — fan out as wide as the terrain warrants, just never duplicate a focus.
• Targeted lookups — use Grep/Read directly when you need raw content in your own context.
• Non-codebase sources — file reads against notes/docs, web search, MCP queries.

The four phases

The phases apply across domains. Adapt depth and tooling — the questions generalize even when the artifacts don't.

1. Locate — find what's relevant

What artifacts, sources, prior work, or context are in play? Don't accept the user's framing as the boundary — adjacent material often turns out to be load-bearing.

2. Trace — follow how things connect

Where does data/argument flow? What depends on what? Which derivations are load-bearing?

3. Pattern — identify conventions

What recurring shapes and established ways of doing things exist? Fighting them creates friction; fitting them creates leverage.

4. Constrain — name the hard limits

What would create problems if violated? Knowing these upfront prevents proposing options that get killed in review.

What to surface

Most findings stay in your context. Surface only surprises, hard constraints, gotchas, and genuine ambiguities that need user input before design can proceed. If exploration was uneventful, say that plainly. The detailed terrain map stays in your context for the next phase.

After exploration

Findings are grounding for the next step — typically design. If you're proceeding in a way that ignores something from exploration, surface it: "I'm doing X despite Y — the reason is..."

Common pitfalls

• Performative exploration. Reading material to look thorough, without tying findings to design implications.
• Dumping the reading list. "I read these 12 files" — they want surprises and constraints, not the catalog.
• Confusing locate with trace. Listing artifacts isn't tracing how things connect. The phases build on each other.
• Skipping because the terrain feels familiar. Map it anyway when the work is non-trivial — the finding you'd skip past is often the one that reshapes the design.
• Treating exploration as a deliverable. It's grounding, not a research project. Time-box it.
• Fanning out the same prompt to multiple Explore agents. Each agent should have a distinct search focus, otherwise you're paying 3× for the same answer.