Research codebase questions using parallel agents - documents what exists, not what should change. Use when the user asks how the codebase works, where something lives, or invokes the prp-codebase-question skill.
72
88%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
View guide
High
Do not use without reviewing
Kild lane: you are running inside a kild room, in a workspace (worktree + branch) the kild engine assigned. The driver owns isolation and publishing — SKIP any step below that creates or switches branches or worktrees, pulls or rebases the base branch, pushes, opens PRs, or moves/archives plan artifacts, and never run
gh pr checkout. Your job ends at implement → validate → commit in the current workspace, reporting evidence. Where a step spawns subagents, do that analysis inline — or ask the room's orchestrator to invite a helper agent.
Arguments:
$ARGUMENTS(and$1,$2, ...) refer to the arguments given when this skill was invoked. Take them from the user's request; if absent, infer them from the conversation.
Input: $ARGUMENTS
Answer codebase questions thoroughly by spawning parallel specialized agents, synthesizing their findings, and producing a research document.
Core Philosophy: Document what IS, not what SHOULD BE. You are a technical cartographer.
Golden Rule: Every claim must have a file:line reference. No speculation, no suggestions, no critique.
If the user mentions specific files, read them FULLY first (no limit/offset) before any decomposition.
| Type | Indicators | Agent Focus |
|---|---|---|
| Where | "where is", "find", "locate" | codebase-explorer primary |
| How | "how does", "trace", "flow" | codebase-analyst primary |
| What | "what is", "explain", "describe" | Both agents in parallel |
| Pattern | "how do we", "convention", "examples" | codebase-explorer primary |
| External | "docs", "best practice", "API" | Add web-researcher |
--web flag for external research--follow-up flag for appending to existing researchPHASE_1_CHECKPOINT:
Break the query into 2-5 composable research areas:
RESEARCH QUESTION: {user's question}
AREAS:
1. {Area} → Agent: {which agent}
2. {Area} → Agent: {which agent}
3. {Area} → Agent: {which agent}| Agent | Use When |
|---|---|
codebase-explorer | Finding WHERE code lives, locating files, extracting patterns, discovering conventions |
codebase-analyst | Understanding HOW code works, tracing data flow, mapping integration points |
web-researcher | Only when --web flag is set or user explicitly asks for external docs |
Strategy:
codebase-explorer to find what existscodebase-analyst on the most relevant findings to trace how they workPHASE_2_CHECKPOINT:
Launch agents in parallel by working through them inline, one after another.
For each research area, use the appropriate agent:
codebase-explorer:
Find all code relevant to: {research area}
LOCATE:
1. {Specific files/components to find}
2. {Patterns or conventions to extract}
3. {Related test files and configuration}
Categorize findings by purpose. Return ACTUAL code snippets with file:line references.
Remember: Document what exists, no suggestions or improvements.codebase-analyst:
Analyze the implementation of: {research area}
TRACE:
1. {Data flow to trace}
2. {Integration points to document}
3. {Contracts between components}
Document what exists with precise file:line references. No suggestions.web-researcher:
Research external documentation for: {topic}
FIND:
1. {Specific documentation needed}
2. {API references or patterns}
Return findings with direct links and citations.IMPORTANT: Wait for ALL agents to complete before proceeding.
PHASE_3_CHECKPOINT:
file:line references throughoutMap findings back to the user's original question:
| Question Aspect | Finding | Evidence |
|---|---|---|
| {aspect 1} | {what was found} | file.ts:123 |
| {aspect 2} | {what was found} | file.ts:456 |
Note any areas that couldn't be fully documented:
PHASE_4_CHECKPOINT:
date -u +"%Y-%m-%dT%H:%M:%SZ"
git rev-parse --short HEAD
git branch --show-current
basename $(git rev-parse --show-toplevel)# --- PRP store resolver (canonical; keep byte-identical across skills) ---
_gd="$(git rev-parse --path-format=absolute --git-common-dir 2>/dev/null)"
case "$_gd" in */.git) _root="${_gd%/.git}" ;; "") _root="$PWD" ;; *) _root="$_gd" ;; esac
_root="$(cd "$_root" && pwd -P)"
_name="$(basename "$_root" | tr '[:upper:]' '[:lower:]' | tr -cs 'a-z0-9' '-' | sed 's/^-*//;s/-*$//')"
PRP_DIR="${PRP_HOME:-$HOME/.prp}/${_name:-project}-$(printf %s "$_root" | git hash-object --stdin | cut -c1-8)"
mkdir -p "$PRP_DIR"; [ -f "$PRP_DIR/project.json" ] || printf '{"path": "%s", "name": "%s"}\n' "$_root" "${_name:-project}" > "$PRP_DIR/project.json"
mkdir -p "$PRP_DIR/research"If --follow-up: Append to existing research file instead of creating new one.
If new research:
Path: $PRP_DIR/research/{YYYY-MM-DD}-{kebab-case-topic}.md
Examples:
2025-01-08-authentication-flow.md2025-01-15-database-migration-patterns.md---
date: {ISO timestamp with timezone}
git_commit: {short hash}
branch: {branch name}
repository: {repo name}
topic: "{User's Question/Topic}"
tags: [research, codebase, {relevant-component-names}]
status: complete
last_updated: {YYYY-MM-DD}
---
# Research: {User's Question/Topic}
**Date**: {ISO timestamp}
**Git Commit**: {short hash}
**Branch**: {branch name}
**Repository**: {repo name}
## Research Question
{Original user query}
## Summary
{High-level documentation of what was found, answering the question by describing what exists}
## Detailed Findings
### {Component/Area 1}
- Description of what exists (`file.ts:123`)
- How it connects to other components
- Current implementation details
### {Component/Area 2}
...
## Code References
| File | Lines | Description |
|------|-------|-------------|
| `path/to/file.ts` | 123-145 | {What's there} |
| `another/file.ts` | 45-67 | {What's there} |
## Architecture Documentation
{Current patterns, conventions, and design implementations found}
## Open Questions
- {Areas that need further investigation}# Check if on main or pushed
git branch --show-current
gh repo view --json owner,name -q '"\(.owner.login)/\(.name)"'If on main/pushed, replace local file references with:
https://github.com/{owner}/{repo}/blob/{commit}/{file}#L{line}
If --follow-up flag and existing research file:
last_updated and add last_updated_note## Follow-up Research {timestamp}PHASE_5_CHECKPOINT:
## Research Complete
**Question**: {original question}
**Document**: `{expanded absolute path to $PRP_DIR/research/{filename}.md}`
### Summary
{2-3 sentence answer to the question}
### Key Findings
- **{Finding 1}**: {brief} (`file.ts:123`)
- **{Finding 2}**: {brief} (`file.ts:456`)
- **{Finding 3}**: {brief} (`file.ts:789`)
### Architecture
{1-2 sentence description of relevant architecture}
### Open Questions
- {Any unanswered aspects}
### Follow-up
To dig deeper: `the prp-codebase-question skill --follow-up {topic}`
To include external docs: `the prp-codebase-question skill --web {topic}`# Basic codebase question
the prp-codebase-question skill how does authentication work
# Include external documentation
the prp-codebase-question skill --web how does the PRP runner execute commands
# Follow up on previous research
the prp-codebase-question skill --follow-up what error handling patterns exist in the runner
# Locate and document a specific area
the prp-codebase-question skill where are all the command templates and how are they structuredDocument, don't evaluate. Describe what IS, never what SHOULD BE.
Evidence required. Every claim needs a file:line reference.
Agents are parallel. Launch multiple agents simultaneously when researching different areas.
Wait for completion. Never synthesize until ALL agents have returned.
Read first. If the user mentions files, read them fully before spawning agents.
No placeholders. Every field in the research document must have real values.
Codebase is truth. Live code always overrides documentation or assumptions.
file:line references{expanded absolute path to $PRP_DIR/research/}1142738
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.