researching-codebase
Skill19 starsChanged 8 months agoMITView on GitHub
Thorough codebase exploration that builds understanding through collaborative dialogue. Investigates architecture, patterns, and implementation details before planning or making changes.
2 other projects use a version of this.
Adopted by
Most recently taken up by
- mykaarma/kaarma-skillstheir own version, first seen Apr 28, 2026
- chrispangg/super-rpitheir own version, first seen Mar 10, 2026
Other versions2 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 2
- chrispangg/super-rpi★ 5same name
- mykaarma/kaarma-skills★ 4same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository16 other files it gives its agents.
- AGENTS.mdAGENTS.md
- brainstormingSkill
- documenting-decisionsSkill
- finishing-workSkill
- git-worktreesSkill
- implementing-plansSkill
- parallel-agentsSkill
- receiving-code-reviewSkill
- research-plan-implementSkill
- reviewing-codeSkill
- security-reviewSkill
- synthesizing-researchSkill
- systematic-debuggingSkill
- test-driven-developmentSkill
- verification-before-completionSkill
- writing-plansSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
24 rules. About 0 are common, 23 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈23
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 15
Start by understanding what the user needs to learn, then ask questions one at a time to refine the scope.
- Distinctive: line 23
Do not touch the codebase until the problem is understood.
- Distinctive: line 34
Use Glob or Grep
- Distinctive: line 40
Prefer multiple choice questions when possible, but open-ended is fine too
- Distinctive: line 41
Only one question per message
- Distinctive: line 42
If a topic needs more exploration, break it into multiple questions
- Distinctive: line 55
If anything needs clarification, ask follow-up questions.
- Distinctive: line 63
Use the file-finder agent to locate files relevant to the research objective:
- Distinctive: line 80
Use TaskCreate to track exploration based on the file-finder report.
- Distinctive: line 85
Read files in the suggested order
- Distinctive: line 91
Follow data through the identified files
- Distinctive: line 93
Document state changes and side effects
- Distinctive: line 99
Document conventions for testing and error handling
- Distinctive: line 109
After identifying relevant files, use the LSP tool for deeper structural understanding:
- Distinctive: line 124
If codebase exploration reveals external factors that need broader investigation, use the web-researcher agent:
- Distinctive: line 131
Use web research for:
- Distinctive: line 143
Ask if findings align with expectations or if you should look elsewhere
- Very specific: line 148
Create research document at: docs/plans/YYYY-MM-DD-<topic>-research.md
- Distinctive: line 198
Ask what the user wants to do next:
- Distinctive: line 200
Create an implementation plan
- Distinctive: line 206
Funnel questions: - Start broad, narrow based on answers:
- Distinctive: line 217
Trade-off questions: - When multiple approaches exist:
- Distinctive: line 222
Clarification through examples: - When requirements are vague:
- Distinctive: line 238
One question at a time: - Don't overwhelm with multiple questions
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Research Methodology
Research topic: $ARGUMENTS
Overview
Help turn research requests into thorough codebase understanding through natural collaborative dialogue.
Start by understanding what the user needs to learn, then ask questions one at a time to refine the scope. Once you understand what you're researching, explore the codebase systematically, presenting findings in digestible sections and validating as you go.
The Iron Law
Ask questions BEFORE exploring code.
Do not touch the codebase until the problem is understood. Resist the urge to immediately search for files or read code.
Phase 1: Understanding the Request
Your first action must be asking a clarifying question.
Do NOT:
- Read any files
- Search the codebase
- Use Glob or Grep
- Explore anything
- Make assumptions about what the user wants
Ask questions one at a time using AskUserQuestion:
- Prefer multiple choice questions when possible, but open-ended is fine too
- Only one question per message
- If a topic needs more exploration, break it into multiple questions
Focus on understanding:
- Purpose: What are they trying to accomplish? (build, change, fix, learn)
- Specifics: What exactly should happen or change?
- Scope: How big is this? (one file, multiple files, architectural)
- Constraints: Any requirements around performance, compatibility, security?
- Context: Have they already looked at anything or have hunches?
When you believe you understand, confirm:
Summarize your understanding and ask if it's accurate before proceeding. If anything needs clarification, ask follow-up questions.
Phase 2: Exploration
Only proceed after confirming understanding with the user.
Locate Relevant Files
Use the file-finder agent to locate files relevant to the research objective:
Task tool with subagent_type: "file-finder"
Prompt: "Find files related to [topic from interrogation]. Goal: [user's stated purpose]"The file-finder will return a structured report with:
- Core files to examine first
- Supporting files and utilities
- Test files
- Configuration files
- Suggested reading order
Explore the Discovered Files
Use TaskCreate to track exploration based on the file-finder report. Create one task per file category (core, supporting, test, config) and update via TaskUpdate as you examine each.
Examine core files first:
- Read files in the suggested order
- Understand the main flow and architecture
- Note patterns and conventions
Trace relevant data flow:
- Follow data through the identified files
- Identify inputs, transformations, outputs
- Document state changes and side effects
Review supporting files:
- Examine utilities and helpers
- Note reusable patterns
- Document conventions for testing and error handling
Identify technical constraints:
- External dependencies
- Performance considerations
- Security implications
Deepen Understanding with LSP
After identifying relevant files, use the LSP tool for deeper structural understanding:
goToDefinition— trace how functions and types connect across filesfindReferences— understand where symbols are used throughout the codebasedocumentSymbol— get a structured overview of a file's exports and structureincomingCalls/outgoingCalls— map call hierarchies to understand data flow
If LSP is unavailable (no configured language server), skip this step and rely on Grep-based content search.
Research External Context (When Needed)
For single-page lookups (e.g., checking a library's API docs or a specific GitHub issue), use WebFetch directly instead of spawning a web-researcher agent. Reserve the web-researcher for multi-source research requiring synthesis.
If codebase exploration reveals external factors that need broader investigation, use the web-researcher agent:
Task tool with subagent_type: "web-researcher"
Prompt: "[specific research question about external topic]"Use web research for:
- Understanding external libraries or APIs the code depends on
- Comparing implementation approaches or best practices
- Investigating third-party service documentation
- Researching security implications or known issues
The web-researcher returns findings with source citations and confidence assessments.
Present findings incrementally:
- Share what you find in digestible sections
- Ask if findings align with expectations or if you should look elsewhere
- Be ready to redirect based on feedback
Phase 3: Document Findings
Create research document at: docs/plans/YYYY-MM-DD-<topic>-research.md
(Use today's date in YYYY-MM-DD format)
# Research: <Topic> (YYYY-MM-DD)
## Problem Statement
[What the user wants to accomplish]
## Requirements
[Key requirements gathered during interrogation]
## Findings
### Relevant Files
| File | Purpose | Key Lines |
| --------------- | ----------- | --------- |
| path/to/file.ts | Description | 42-87 |
### Existing Patterns
[Patterns discovered that inform implementation]
### Dependencies
[External and internal dependencies]
### External Research
[Findings from web research, if conducted - include sources]
### Technical Constraints
[Limitations discovered during exploration]
## Open Questions
[Questions that remain unanswered]
## Recommendations
[Initial thoughts on approach]Phase 4: Transition
Ask what the user wants to do next:
- Create an implementation plan
- Continue researching
- End for now
Questioning Techniques
Funnel questions - Start broad, narrow based on answers:
- "What are you trying to accomplish?" (broad)
- "Which part is most important?" (narrowing)
- "What would success look like?" (specific)
Assumption surfacing - Make assumptions explicit:
I'm assuming this needs to work with the existing auth system. Is that correct?
Trade-off questions - When multiple approaches exist:
There's a trade-off: Option A is faster to build but less flexible. Option B is more flexible but more complex. Which matters more here?
Clarification through examples - When requirements are vague:
Can you give me an example of what you'd expect to happen?
Anti-Patterns
| Wrong | Right |
| Reading files immediately | Ask questions first |
| Multiple questions in one message | One question, wait, then next |
| "I understand, let me look" | "Let me confirm: [summary]. Accurate?" |
| "How should we handle this?" | "Should we A) do X, B) do Y, or C) something else?" |
| "I'll add a new AuthService" | "The codebase uses repository pattern. Auth is here." |
Key Principles
- One question at a time - Don't overwhelm with multiple questions
- Multiple choice preferred - Easier to answer than open-ended
- Confirm before exploring - Validate understanding first
- Incremental findings - Present discoveries in sections, validate each
- Be flexible - Go back and clarify when something doesn't fit
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

