| name | explore-plan |
| description | Drives the Explore -> Plan -> Review -> Verify discipline for non-trivial, multi-file work before any code is written. Activate when the user asks to "plan this", "scope this out", "figure out how to do X", "explore the codebase first", or is starting a change that touches several files or an unfamiliar area. Enforces a written plan and real verification instead of trusting a success claim.
|
Explore / Plan Skill
For non-trivial work, exact context beats approximation and a written plan beats diving in. This
skill codifies the four-phase loop. Skip it for trivial edits (typos, single-line tweaks)—say so.
1. Explore (read-only)
Understand before changing. Use plan mode for read-only tracing of the relevant files and data
models. Prefer references over descriptions: cite path/to/file.py:42 and read the real code
rather than guessing. Pipe real errors in (cat error.log | claude) instead of paraphrasing them.
Launch parallel Explore agents when scope is uncertain or spans multiple areas.
2. Plan (written, explicit)
Before multi-file changes, write an explicit plan: the problem, the approach, the specific files to
touch, and the existing helpers/patterns to reuse (search for them—do not invent new code when a
utility already exists). A written plan is reviewable and catches wrong premises before they cost edits.
3. Review (fresh, unbiased)
Have the plan—and later the diff—reviewed with no implementation bias. Use the peer-review
skill, which drives the read-only code-reviewer subagent. A reviewer that did not write the plan
catches assumptions the author cannot see.
4. Verify (never trust a success claim)
Never accept “it works” without evidence. Before declaring done, produce real output: run the
tests, run the app and observe behavior, capture a screenshot for UI changes, or paste the real
command output. Type-checks and a green suite prove code correctness, not feature correctness—if
you cannot exercise the feature, say so explicitly rather than claiming success.
Examples
Example 1: Multi-file feature
User says: “Plan how we’d add rate limiting to the API.”
- Launches
Explore agents to map the request middleware and existing config patterns; reads the
real middleware files and cites them.
- Writes a plan: which middleware to add, where config lives, which existing
RedisClient helper to
reuse, which tests to add.
- Runs
peer-review on the plan—reviewer notes the plan misses the health-check path; fixes it.
- After implementing, verifies by hitting the endpoint until throttled and pasting the 429 response.
Example 2: Unfamiliar bug
User says: “Figure out why login intermittently 500s, then fix it.”
- Explores: greps the auth path, reads the session store code, pipes in the real stack trace.
- Writes a short plan pinpointing the suspected race in token refresh.
- Implements the fix, then verifies by reproducing the original failure and showing it now passes —
not by asserting the change “should” fix it.
