skills/codebase-research/SKILL.md
Orchestrates comprehensive codebase research by decomposing user queries into parallel sub-agent tasks and synthesizing findings. This skill should be used when users ask questions about how code works, where functionality exists, how components interact, or need comprehensive documentation of existing implementations. It focuses exclusively on documenting and explaining the codebase as it exists today.
npx skillsauth add mhylle/claude-skills-collection codebase-researchInstall 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.
This skill enables comprehensive codebase research through parallel sub-agent orchestration. It decomposes research questions into focused sub-tasks, executes them in parallel for efficiency, and synthesizes findings into structured research documents.
THE ONLY JOB IS TO DOCUMENT AND EXPLAIN THE CODEBASE AS IT EXISTS TODAY.
Do NOT:
DO:
When this skill is invoked, respond:
"I'm ready to research the codebase. Please provide your research question or area of interest, and I'll analyze it thoroughly by exploring relevant components and connections."
| Agent | Purpose | When to Use |
|-------|---------|-------------|
| codebase-locator | Finds files by topic/feature | Need to locate all files related to a feature |
| codebase-analyzer | Traces implementation with file:line refs | Need to understand how code works |
| codebase-pattern-finder | Finds code patterns with examples | Need to see how patterns are implemented |
| Agent | Purpose | When to Use |
|-------|---------|-------------|
| docs-locator | Finds docs, ADRs, design documents | Need to find documentation about a topic |
| docs-analyzer | Extracts decisions and specs from docs | Need to understand documented decisions |
| Agent | Purpose | When to Use |
|-------|---------|-------------|
| web-search-researcher | Researches external documentation | Explicitly requested or need external context |
Read any files directly mentioned by the user completely (without limit/offset parameters) before spawning sub-tasks. This establishes baseline context.
Analyze the research question considering:
Create a research plan using TodoWrite with specific investigation areas.
Use the Task tool to spawn parallel sub-agents. Match agents to research needs:
For "Where is X? questions:
Task(subagent_type="codebase-locator", prompt="Find all files related to [topic]...")
For "How does X work?" questions:
Task(subagent_type="codebase-analyzer", prompt="Trace the implementation of [feature]...")
For "How should I implement X?" questions:
Task(subagent_type="codebase-pattern-finder", prompt="Find patterns for [type] including examples...")
For "Why was X done this way?" questions:
Task(subagent_type="docs-locator", prompt="Find design docs and ADRs related to [topic]...")
Task(subagent_type="docs-analyzer", prompt="Extract decisions and rationale for [topic]...")
For external documentation needs (only if explicitly requested):
Task(subagent_type="web-search-researcher", prompt="Research [library/API] documentation for [topic]...")
Spawn multiple agents in parallel (single message with multiple Task tool calls) for efficiency.
Wait for all sub-agents to complete using AgentOutputTool, then compile results with:
Create a structured research document with the following format:
# Research: [Topic]
**Date:** YYYY-MM-DD
**Branch:** [current branch]
**Commit:** [current commit hash]
## Research Question
[The original question being investigated]
## Summary
[2-3 paragraph executive summary of findings]
## Detailed Findings
### [Finding Category 1]
[Detailed explanation with code references]
### [Finding Category 2]
[Detailed explanation with code references]
## Code References
| Component | File | Purpose |
|-----------|------|---------|
| [Name] | `path/to/file.ts:line` | [What it does] |
## Architecture
[How components interact - can include ASCII diagrams]
## Historical Context
[Relevant decisions from documentation, if any]
## Related Files
- `path/to/related1.ts` - [Purpose]
- `path/to/related2.ts` - [Purpose]
## Open Questions
- [Any unresolved questions or areas needing further investigation]
Present the research document to the user. For follow-up questions:
| Question Pattern | Primary Agent | Supporting Agents | |-----------------|---------------|-------------------| | "Where is X implemented?" | codebase-locator | - | | "How does X work?" | codebase-analyzer | codebase-locator | | "How is X typically done here?" | codebase-pattern-finder | codebase-locator | | "Why was X designed this way?" | docs-analyzer | docs-locator, codebase-analyzer | | "What are all the files for X?" | codebase-locator | - | | "Trace the flow of X" | codebase-analyzer | codebase-locator | | "Find examples of X" | codebase-pattern-finder | codebase-locator | | "What's documented about X?" | docs-locator | docs-analyzer |
For complex questions that span multiple concerns, spawn multiple specialized agents:
Example: "How does authentication work and why was JWT chosen?"
Task(subagent_type="codebase-locator", prompt="Find all auth-related files...")
Task(subagent_type="codebase-analyzer", prompt="Trace auth flow implementation...")
Task(subagent_type="docs-locator", prompt="Find auth design docs and ADRs...")
Task(subagent_type="docs-analyzer", prompt="Extract auth decisions and rationale...")
Always spawn multiple sub-agents in parallel when investigating different aspects of the same question. This significantly reduces research time.
Include precise file:line references for all findings:
src/services/auth.service.ts:45 - Goodthe auth service - InsufficientFocus on observable facts:
Avoid speculation or judgment:
For broad questions, structure the research in layers:
For narrow questions, go directly to specifics with supporting context.
When relevant, include findings from documentation:
This skill handles questions like:
tools
--- name: tt-workflow-build description: Tasktracker-native trigger for a PARALLEL build via the Claude Code Workflow tool. Thin by design — it does two things, then drives to done: (1) ensure a tasktracker project exists (use the existing one, or create one), then (2) start a dynamic `Workflow` that builds it, tracking the work in tasktracker and using the build + verify skills. It does NOT analyze parallelism up front, ask the user to choose a mode, hand back, or fall back to a sequential skil
tools
--- name: grumpy-reviewer description: A single grumpy, nitpicky structural code reviewer that runs as an isolated subagent and treats the code as third-party work submitted by a junior programmer for validation. It cares about exactly one thing — maintainability — judged through separation of concerns, service-oriented design, helper-method extraction, small files, and the rule of 7 (as any grouping nears 7 members, it pushes for sub-groupings). It is deliberately kept OUT of the implementation
development
--- name: tt-workflow-run description: Tasktracker-native autonomous build-loop orchestrator. Drives a first-class `workflow_run` end-to-end — create the run (Gate 1 lifecycle completeness + Gate 2 zero-defects-in), then loop while `getNextReadyTask(projectId)` returns a slice — `setActiveTask` → record a pre-slice `scanArchitectureDrift` baseline → delegate the slice to `/tt-implement-phase` (which does the code work, registers the architecture delta in-slice, and auto-logs defects/learnings/fr
tools
Tasktracker-native project-wide parallel audit using the Claude Code Workflow tool (dynamic workflows). Partitions a repo / backlog / architecture and fans out read-only agents (one per partition) that return schema-checked findings, aggregates them into a deduplicated, ranked risk register, and OPTIONALLY writes fixes back as tasks under a Bug Fix phase — with all tasktracker writes done by the PARENT, never the parallel agents (single global active-task pointer). Journaled and resumable, so a rate-limit or crash mid-audit resumes without re-running completed partitions. Use for large, embarrassingly-parallel, read/analyze-heavy jobs where each unit is self-contained and the output aggregates — audit every file/component for risk, find all architecture drift (scanArchitectureDrift) or duplicate tasks (detectDuplicates/auditDuplicates), per-file tech-debt sweep, test-coverage or security-surface scan across a whole project. Triggers on "/tt-workflow-audit", "audit the whole repo", "parallel audit", "scan every file/component", "find all drift/duplicates", "tech-debt sweep (tasktracker)", or any whole-project analyze-at-scale request inside a session with a tasktracker project. Prefer this over /codebase-audit or /code-quality-audit when the project is tracked in tasktracker AND you want the findings written back as tasks; prefer it over team-* modes when the units don't need to negotiate live (they just report).