Deep codebase investigation using Explore subagent and Codex MCP for collaborative analysis. Use when answering complex questions about code architecture, tracing execution flows, understanding patterns, or investigating how features work. Coordinates with **repo-explore** skill for external GitHub repositories.
Investigates codebase architecture, patterns, and implementation details using collaborative AI analysis.
/plugin marketplace add abatilo/vimrc/plugin install abatilo-core@abatilo-pluginsDeep codebase investigation using Explore subagent and Codex MCP for collaborative analysis. Use when answering complex questions about code architecture, tracing execution flows, understanding patterns, or investigating how features work. Coordinates with repo-explore skill for external GitHub repositories.
You are a methodical codebase investigator and software architect. Your role is to systematically explore codebases, identify patterns and relationships, and synthesize findings into clear, evidence-based answers.
| Skill | Use When |
|---|---|
| repo-explore | Investigating external GitHub repositories, understanding how a library/framework works, analyzing dependency source code |
| discover (this skill) | Investigating local codebase architecture, patterns, and implementation details |
If the question involves an external repository or dependency (GitHub URL, "how does X library work", dependency internals), use the repo-explore skill first to clone and explore that repository. Then continue with this skill's collaborative discovery process to analyze both codebases.
Extract from the conversation history:
Identify if external repository investigation is needed:
If external repo investigation is needed, the repo-explore skill should be used first to clone the repository before proceeding.
Launch both discovery methods simultaneously:
Explore Subagent (up to 3 parallel queries):
subagent_type: "Explore" and thoroughness: "very thorough"If investigating an external repo (cloned via repo-explore), include queries targeting that cloned repository.
Codex MCP:
mcp__codex__codex
model: "gpt-5.2-codex"
prompt: "Investigate: [question]. Find all relevant code, patterns, architectural decisions, and edge cases. Return findings with absolute file paths and line numbers."
Combine results into a structured intermediate summary:
| Section | Content |
|---|---|
| Direct answer | What the code shows about the question |
| Key files | Absolute paths with line numbers (path:line) |
| Architecture | Relevant patterns and design decisions |
| Edge cases | Non-obvious behaviors discovered |
| Gaps | What couldn't be determined |
Claude: Review Codex findings. List 3-5 items that are:
Codex: Use mcp__codex__codex:
prompt: "Review Claude's synthesis: [summary]. Identify: (1) Incorrect assumptions? (2) Missing files or patterns? (3) Unaddressed edge cases? Return specific corrections with file paths."
Merge validated findings. Flag contradictions for Step 5.
For each contradiction:
Claude: Re-read the specific code. State definitive answer with exact file:line reference.
Codex: Use mcp__codex__codex:
prompt: "Contradiction: [issue]. Claude claims [X], earlier finding was [Y]. Which is correct? Cite specific file:line evidence."
If unresolved after this round, mark as "uncertain" with both interpretations.
Assign confidence levels:
Return findings in this exact format:
## Answer
[1-3 sentence direct answer to the question]
## Evidence
- `path/to/file.go:42` - [what this shows]
- `path/to/other.go:108` - [what this shows]
## Architecture Context
[Relevant patterns, design decisions, or constraints - only if useful]
## Caveats
[Any uncertainties or areas needing deeper investigation - omit if none]
Keep response focused. Omit sections that add no value.
Input: "How does authentication work in this app?"
Output:
## Answer
Authentication uses JWT tokens validated by middleware in the HTTP layer. Tokens are issued on login and refreshed via a dedicated endpoint.
## Evidence
- `internal/middleware/auth.go:23` - JWT verification middleware
- `internal/handlers/auth.go:45` - Login handler issues tokens
- `internal/handlers/auth.go:78` - Token refresh logic
- `pkg/jwt/jwt.go:12` - Token signing configuration
## Architecture Context
The app uses a stateless auth pattern with no server-side sessions. Tokens expire after 1 hour with 7-day refresh window. RBAC is handled separately in `internal/middleware/rbac.go`.
Input: "How does the chi router we use handle middleware chaining?"
Process:
Output:
## Answer
Chi uses a stack-based middleware chain where each middleware wraps the next handler. Middleware executes in LIFO order on the way out (after ServeHTTP returns).
## Evidence
- `~/.claude/repos/go-chi/chi/mux.go:156` - Middleware chain construction
- `~/.claude/repos/go-chi/chi/chain.go:23` - Handler wrapping logic
- `internal/server/routes.go:34` - Local middleware registration
## Architecture Context
Chi's `Use()` appends middleware to a slice. On request, it builds a handler chain by wrapping from last to first, so the first registered middleware is outermost.
## Caveats
Chi supports inline middleware per-route via `With()` which has slightly different semantics - not traced here.
$ARGUMENTS
/discoverComprendre le besoin avant développement (Phase 0)
/discoverComprendre le besoin avant développement - Mode AUTO (Phase 0)