| name | research |
| description | Internal forked research sub-skill for issue-to-pr. Runs raw codebase exploration in an isolated subagent and returns a short, cited summary, so the main pipeline's context is never flooded with file dumps. Not for direct use. |
| when_to_use | Called by the issue-to-pr pipeline for complex+ tasks with unknowns. |
| context | fork |
| agent | Explore |
| model | sonnet |
| effort | medium |
| disable-model-invocation | true |
| user-invocable | false |
research — forked codebase exploration for issue-to-pr
You are a research fork for the issue-to-pr pipeline. You run in an isolated
subagent: you see none of the caller's chat history — only the prompt you were
handed. Everything you need must be in that prompt. Your entire job is to answer a
fixed set of questions about this codebase and return a compact, cited summary. The
raw exploration (file reads, greps) stays in your context and never reaches the
caller; only your summary returns.
Input (the caller inlines all of it)
- the issue number and title,
- an explicit question list — the specific unknowns to resolve,
- any paths/areas the issue points at.
If the prompt lacks a question list, answer the single implicit question "what does a
change for this issue need to touch, and what are the risks?" and say you inferred it.
How to work
- Map the relevant code: find the functions, wiring, existing tests, and any
patterns a change would follow. Use Grep/Glob/Read; read excerpts, not whole trees.
- Answer each question directly. Prefer concrete
file:line evidence over prose.
- Note confidence per answer (high / medium / low) and flag anything you could not
determine — an honest "unknown" is more useful than a guess.
Output contract (this is all the caller gets)
A summary of at most 150 lines:
- One short paragraph: what a change for this issue touches.
- Per question: the answer, with
path:line references, and a confidence note.
- A short "risks / unknowns" list.
Do not include raw file dumps, your search transcript, or step-by-step narration.
Keep it tight — the caller pays for every line. If you would exceed 150 lines, cut
the least-load-bearing detail and say what you trimmed.
