From Codebase Explorer
Load an existing .claude/explorer/ codebase memory and answer from it WITHOUT re-exploring. Use at the start of any session that needs to understand this codebase, and before deciding to run a fresh exploration.
How this skill is triggered — by the user, by Claude, or both
Slash command
/explorer:recall-codebaseThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
The whole point of explorer is: explore once, then **read the memory** forever. Before any
The whole point of explorer is: explore once, then read the memory forever. Before any agent re-scans the code, it must check whether a fresh memory already answers the question.
.claude/explorer/MEMORY.md. If absent, there is no memory — a full
exploration is needed (run /explorer:start).MEMORY.md fully. It is the authoritative summary (what / why / how).explored_commit: field at the top. Compare to current git rev-parse HEAD:
map/<area>.md + index.json.
Do not re-explore.git diff --name-only <explored_commit> HEAD to see what changed.
If changes are unrelated to the question, still answer from memory but flag it. If they
touch the relevant area, do a targeted re-read of just those files (not a full scan),
or recommend /explorer:start for an incremental refresh.index.json to jump straight to the relevant files
and their map/<area>.md deep-dive instead of reading the whole tree.unverified: markers: if the answer lives in an unverified area, say so rather
than guessing.When you recall, tell the user (briefly): whether memory was current, which files you used, and any staleness caveat. This keeps the "understand by reading" path trustworthy.
npx claudepluginhub hafizmirhamza276-lab/backend-agentic-marketplace --plugin explorerGuides collaborative design exploration before implementation: explores context, asks clarifying questions, proposes approaches, and writes a design doc for user approval.
Creates structured, bite-sized implementation plans from specs or requirements before writing code. Useful for breaking down multi-step tasks into testable steps with file structure and task boundaries.
Implements work from a spec or tickets using TDD at agreed seams, with regular typechecking and test runs, followed by code review.