/research-codebase
Document codebase as-is with research directory for historical context.
$ npx -y skills add flora131/atomic --skill research-codebase --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/research-codebase
Context preview
The summary Claude sees to decide when to auto-load this skill.
Document codebase as-is with research directory for historical context.
SKILL.md
research-codebase.SKILL.mdname: research-codebase
description: Document codebase as-is with research directory for historical context.
Research Codebase
You are tasked with conducting comprehensive research across the codebase to answer user questions by spawning parallel sub-agents and synthesizing their findings.
The user's research question/request is: **$ARGUMENTS**
Steps to follow after receiving the research query:
<EXTREMELY_IMPORTANT>
- OPTIMIZE the research question using your prompt-engineer skill to refine phrasing and structure for maximum clarity and precision.
- After research is complete and the research artifact(s) are generated, provide an executive summary of the research and path to the research document(s) to the user, and ask if they have any follow-up questions or need clarification.
</EXTREMELY_IMPORTANT>
1. **Read any directly mentioned files first:**
- If the user mentions specific files (tickets, docs, or other notes), read them FULLY first
- **IMPORTANT**: Use the `readFile` tool WITHOUT limit/offset parameters to read entire files
- **CRITICAL**: Read these files yourself in the main context before spawning any sub-tasks
- This ensures you have full context before decomposing the research
2. **Determine the compatibility posture:**
- Before decomposing the research request, identify whether this project must preserve backward compatibility for real downstream users.
- If the user explicitly allows breaking changes, public API changes, cleanup, or says there are no real users/downstream dependencies, set `breaking_changes_allowed: true`.
- If the user mentions production users, published APIs, downstream consumers, migration safety, or compatibility requirements, set `breaking_changes_allowed: false`.
- If the posture is not inferable from the request, ask the user once before continuing, using the available structured question tool when possible.
- Carry this posture into the research plan, every sub-agent prompt, the final research document frontmatter, and the `## Compatibility Context` section.
- When `breaking_changes_allowed: true`, document existing legacy behavior, compatibility shims, optional flags, and public APIs as current state, not as constraints future specs must preserve unless the user explicitly asks for preservation.
- When `breaking_changes_allowed: false`, document public APIs, compatibility-sensitive surfaces, downstream callers, migration constraints, and behavior that future work must preserve.
3. **Analyze and decompose the research question:**
- Break the research question down into composable research areas
- Take time to ultrathink about the underlying patterns, connections, and architectural implications the user might be seeking
- Identify specific components, patterns, or concepts to investigate
- Create a research plan using TodoWrite to track all subtasks
- Include the compatibility posture in the plan so later synthesis and spec creation inherit the same constraint.
- Consider which directories, files, or architectural patterns are relevant
4. **Spawn parallel sub-agent tasks:**
- Create multiple Task agents to research different aspects concurrently
- We now have specialized agents that know how to do specific research tasks:
**For codebase research:**
- Use the **codebase-locator** agent to find WHERE files and components live
- Use the **codebase-analyzer** agent to understand HOW specific code works (without critiquing it)
- Use the **codebase-pattern-finder** agent to find examples of existing patterns (without evaluating them)
- Output directory: `research/docs/` relative to the current working directory
- Examples:
- The database logic is found and can be documented in `research/docs/2024-01-10-database-implementation.md`
- The authentication flow is found and can be documented in `research/docs/2024-01-11-authentication-flow.md`
**IMPORTANT**: All agents are documentarians, not critics. They will describe what exists without suggesting improvements or identifying issues.
**For research directory:**
- Use the **codebase-research-locator** agent to discover what documents exist about the topic
- Use the **codebase-research-analyzer** agent to extract key insights from specific documents (only the most relevant ones)
**For online search:**
- VERY IMPORTANT: In case you discover external libraries as dependencies, use the **codebase-online-researcher** agent for external documentation and resources
- The agent fetches live web content using the **playwright-cli** skill's `playwright-cli` command (or `npx playwright-cli` / `curl`). Instruct it to apply the token-efficient fetch order: (1) try `curl https://<site>/llms.txt` for an AI-friendly index (see [llmstxt.org](https://llmstxt.org/llms.txt)), (2) try `curl <url> -H "Accept: text/markdown"` to get pre-converted Markdown (supported on Cloudflare-hosted docs via [Markdown for Agents](https://developers.cloudflare.com/fundamentals/reference/markdown-for-agents/)), (3) fall back to HTML parsing via `playwright-cli`
- Instruct the agent to return LINKS with their findings and INCLUDE those links in the research document
- The agent should persist reusable source documents under `research/web/<YYYY-MM-DD>-<kebab-case-topic>.md` (with frontmatter noting `source_url`, `fetched_at`, and `fetch_method`) so future research can reuse them without re-fetching
- Output directory for the synthesized web research artifacts: `research/web/`:
When you fetch a document that is worth keeping for future sessions (reference docs, API schemas, SDK guides, release notes, troubleshooting writeups, architecture articles), `write` it to `research/web/<YYYY-MM-DD>-<kebab-case-topic>.md` with frontmatter capturing:
---
source_url: <original URL>
fetched_aRead more
name: research-codebase description: Document codebase as-is with research directory for historical context.
Research Codebase
You are tasked with conducting comprehensive research across the codebase to answer user questions by spawning parallel sub-agents and synthesizing their findings.
The user's research question/request is: **$ARGUMENTS**
Steps to follow after receiving the research query:
<EXTREMELY_IMPORTANT>
- OPTIMIZE the research question using your prompt-engineer skill to refine phrasing and structure for maximum clarity and precision.
- After research is complete and the research artifact(s) are generated, provide an executive summary of the research and path to the research document(s) to the user, and ask if they have any follow-up questions or need clarification.
</EXTREMELY_IMPORTANT>
1. **Read any directly mentioned files first:**
- If the user mentions specific files (tickets, docs, or other notes), read them FULLY first
- **IMPORTANT**: Use the `readFile` tool WITHOUT limit/offset parameters to read entire files
- **CRITICAL**: Read these files yourself in the main context before spawning any sub-tasks
- This ensures you have full context before decomposing the research
2. **Determine the compatibility posture:**
- Before decomposing the research request, identify whether this project must preserve backward compatibility for real downstream users.
- If the user explicitly allows breaking changes, public API changes, cleanup, or says there are no real users/downstream dependencies, set `breaking_changes_allowed: true`.
- If the user mentions production users, published APIs, downstream consumers, migration safety, or compatibility requirements, set `breaking_changes_allowed: false`.
- If the posture is not inferable from the request, ask the user once before continuing, using the available structured question tool when possible.
- Carry this posture into the research plan, every sub-agent prompt, the final research document frontmatter, and the `## Compatibility Context` section.
- When `breaking_changes_allowed: true`, document existing legacy behavior, compatibility shims, optional flags, and public APIs as current state, not as constraints future specs must preserve unless the user explicitly asks for preservation.
- When `breaking_changes_allowed: false`, document public APIs, compatibility-sensitive surfaces, downstream callers, migration constraints, and behavior that future work must preserve.
3. **Analyze and decompose the research question:**
- Break the research question down into composable research areas
- Take time to ultrathink about the underlying patterns, connections, and architectural implications the user might be seeking
- Identify specific components, patterns, or concepts to investigate
- Create a research plan using TodoWrite to track all subtasks
- Include the compatibility posture in the plan so later synthesis and spec creation inherit the same constraint.
- Consider which directories, files, or architectural patterns are relevant
4. **Spawn parallel sub-agent tasks:**
- Create multiple Task agents to research different aspects concurrently
- We now have specialized agents that know how to do specific research tasks:
**For codebase research:**
- Use the **codebase-locator** agent to find WHERE files and components live
- Use the **codebase-analyzer** agent to understand HOW specific code works (without critiquing it)
- Use the **codebase-pattern-finder** agent to find examples of existing patterns (without evaluating them)
- Output directory: `research/docs/` relative to the current working directory
- Examples:
- The database logic is found and can be documented in `research/docs/2024-01-10-database-implementation.md`
- The authentication flow is found and can be documented in `research/docs/2024-01-11-authentication-flow.md`
**IMPORTANT**: All agents are documentarians, not critics. They will describe what exists without suggesting improvements or identifying issues.
**For research directory:**
- Use the **codebase-research-locator** agent to discover what documents exist about the topic
- Use the **codebase-research-analyzer** agent to extract key insights from specific documents (only the most relevant ones)
**For online search:**
- VERY IMPORTANT: In case you discover external libraries as dependencies, use the **codebase-online-researcher** agent for external documentation and resources
- The agent fetches live web content using the **playwright-cli** skill's `playwright-cli` command (or `npx playwright-cli` / `curl`). Instruct it to apply the token-efficient fetch order: (1) try `curl https://<site>/llms.txt` for an AI-friendly index (see [llmstxt.org](https://llmstxt.org/llms.txt)), (2) try `curl <url> -H "Accept: text/markdown"` to get pre-converted Markdown (supported on Cloudflare-hosted docs via [Markdown for Agents](https://developers.cloudflare.com/fundamentals/reference/markdown-for-agents/)), (3) fall back to HTML parsing via `playwright-cli`
- Instruct the agent to return LINKS with their findings and INCLUDE those links in the research document
- The agent should persist reusable source documents under `research/web/<YYYY-MM-DD>-<kebab-case-topic>.md` (with frontmatter noting `source_url`, `fetched_at`, and `fetch_method`) so future research can reuse them without re-fetching
- Output directory for the synthesized web research artifacts: `research/web/`:
When you fetch a document that is worth keeping for future sessions (reference docs, API schemas, SDK guides, release notes, troubleshooting writeups, architecture articles), `write` it to `research/web/<YYYY-MM-DD>-<kebab-case-topic>.md` with frontmatter capturing:
---
source_url: <original URL>
fetched_aThe verifiable coding agent runtime. Define your coding agent's process in natural language with stages, checks, and approval gates instead of hoping it follows your instructions.
Repo: flora131/atomic
Other skills on atomic.
- /intercom
Streamline session-to-session coordination with the intercom extension. Send messages, delegate tasks, and coordinate work across multiple atomic sessions on the same machine. Use for planner-worker workflows, cross-session context sharing, and real-time collaboration between
Open skill - /liteparse
Use this skill whenever a task involves a document file (PDF, DOCX, PPTX, XLSX, or image) and you need to read it or pull text, tables, or specific values out of it — to answer a question about its contents, look up a figure, or extract data. Provides fast, local, model-free
Open skill - /playwright-cli
Automate browser interactions, test web pages and work with Playwright tests.
Open skill - /subagent
Delegate work to builtin or custom subagents with single-agent, parallel, selective async, forked-context, and intercom-coordinated runs. Use for bounded specialist delegation where a single parent agent stays in control while subagents contribute locate, analyze, pattern-find,
Open skill - /tdd
Test-driven development with red-green-refactor loop. Use when user wants to build features or fix bugs using TDD, mentions "red-green-refactor", wants integration tests, or asks for test-first development.
Open skill - /tmux
Control tmux-compatible sessions/windows/panes for interactive CLIs: list, capture output, send keys, paste text, monitor prompts.
Open skill

