Design a dynamic research team and plan using agent teams -- analyzes question, composes team, creates executable research plan. Use when the user wants to plan multi-agent research on a question or topic, or invokes /prp-research-team.
86%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
Passed
No findings from the security scan
The canonical home for this skill is prp-research-team in Wirasm/prp
Input: $ARGUMENTS
Design a dynamic team of research agents and a structured research plan for any given question or topic. The plan targets Claude Code's experimental agent teams feature (TeamCreate, shared task list, delegate mode).
Core Principle: PLAN ONLY — no research is executed. Produce a comprehensive, executable research plan that enables a team of agents to deliver thorough findings.
Golden Rule: Every researcher must have a clear focus, measurable completion criteria, and a defined output format. No vague mandates.
Doctrine: The research question dictates the team — never force a fixed roster. A market research question demands different expertise than a codebase architecture question.
| Variable | Source | Default |
|---|---|---|
$ARGUMENTS | User input | — (required) |
ORCHESTRATION | --orchestration "..." flag in $ARGUMENTS | Empty (auto-compose) |
OUTPUT_DIR | Fixed | $PRP_DIR/research-plans/ |
Extract from $ARGUMENTS:
--orchestration flag (if present)Parsing rules:
--orchestration "..." or --orchestration '...' from arguments → store as ORCHESTRATIONScan the research question for scope indicators:
| Signal | Example | Implication |
|---|---|---|
| Comparative ("vs", "compare", "alternatives") | "React vs Vue vs Svelte" | Multiple perspectives needed |
| Evaluative ("best", "optimal", "should we") | "Best approach for real-time sync" | Criteria definition needed |
| Exploratory ("how", "what are", "landscape") | "What are the approaches to..." | Broad survey needed |
| Investigative ("why", "root cause", "debug") | "Why does X fail under Y" | Deep-dive analysis needed |
| Quantitative ("benchmark", "performance", "cost") | "Performance cost of SSR" | Measurement methodology needed |
If question is empty or unclear:
Research question required.
Usage:
/prp-research-team "What are the best approaches for real-time collaboration?"
/prp-research-team "Compare state management libraries for React" --orchestration "Focus on bundle size and DX"PHASE_1_CHECKPOINT:
--orchestration flag parsed (or confirmed absent)GATE: If the research question is too vague to decompose into sub-questions → STOP and ASK user for clarification.
Classify the question into one or more domains:
| Domain | Indicators | Typical Researcher Profiles |
|---|---|---|
| CODEBASE | References project files, patterns, architecture | Code analyst, pattern extractor, dependency mapper |
| TECHNICAL | Libraries, frameworks, protocols, algorithms | Docs researcher, benchmarker, compatibility analyst |
| MARKET | Products, competitors, pricing, trends | Market analyst, competitive researcher, trend tracker |
| USER_RESEARCH | User needs, behavior, UX, feedback | UX researcher, survey analyst, persona builder |
| ARCHITECTURE | System design, scalability, trade-offs | Systems architect, performance analyst, security reviewer |
| MIXED | Spans multiple domains | Combination of above |
For MIXED domains, identify the primary domain and supporting domains.
| Complexity | Criteria | Team Size | Sub-questions |
|---|---|---|---|
| LOW | Single domain, narrow scope, well-defined | 2-3 researchers | 3-4 |
| MEDIUM | 2 domains, moderate scope, some ambiguity | 3-5 researchers | 4-6 |
| HIGH | 3+ domains, broad scope, significant ambiguity | 5-7 researchers | 5-7 |
Complexity factors:
If ORCHESTRATION is set, adjust:
PHASE_2_CHECKPOINT:
Decompose into 3-7 independently investigable sub-questions.
Decomposition rules:
Create a dependency graph:
SQ-1 (foundational) ──┬──► SQ-2 (parallel)
├──► SQ-3 (parallel)
└──► SQ-4 (parallel)
│
▼
SQ-5 (synthesis, depends on SQ-2,3,4)Dependency types:
Check that sub-questions collectively:
PHASE_3_CHECKPOINT:
For each researcher, define:
| Field | Description |
|---|---|
| Name | Descriptive role name (e.g., "API Compatibility Analyst") |
| Focus | 1-2 sentence description of their research area |
| Sub-questions | Which SQ-IDs they own |
| Model | sonnet for most research, opus for synthesis/complex analysis |
| Spawn prompt | Complete instructions for the agent — must be self-contained |
| Output format | Exact structure of their deliverable (markdown sections, tables, etc.) |
| Completion criteria | Measurable conditions that define "done" |
Each spawn prompt MUST include:
| Researcher Type | Recommended Model | Rationale |
|---|---|---|
| Data gatherer / doc reviewer | sonnet | Efficient for search and extraction |
| Deep analyst / synthesizer | opus | Better reasoning for complex analysis |
| Benchmarker / comparator | sonnet | Structured comparison tasks |
| Lead researcher / integrator | opus | Synthesis across multiple inputs |
If ORCHESTRATION is set, verify the team composition aligns with the guidance. Adjust roles, emphasis, or add/remove researchers as needed.
PHASE_4_CHECKPOINT:
For each task, define:
| Field | Description |
|---|---|
| ID | RT-{N} sequential identifier |
| Title | Short descriptive title |
| Assignee | Researcher name |
| Type | RESEARCH / ANALYSIS / SYNTHESIS / REVIEW |
| Dependencies | List of RT-IDs that must complete first (or NONE) |
| Description | What specifically needs to be done |
| Acceptance criteria | How to verify the task is complete |
| Estimated effort | LOW / MEDIUM / HIGH |
Identify shared standards across all researchers:
PHASE_5_CHECKPOINT:
# --- PRP store resolver (canonical; keep byte-identical across skills) ---
# Adopt the store that already records this root; mint a key only when none does.
_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/-*$//')"
_home="${PRP_HOME:-$HOME/.prp}"
_hit="$(grep -lsF "\"path\": \"$_root\"" "$_home"/*/project.json 2>/dev/null | head -1)"
PRP_DIR="${_hit%/project.json}"
[ -n "$PRP_DIR" ] || PRP_DIR="$_home/${_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-plans"Convert the research topic to kebab-case, truncate to 50 chars max:
real-time-collaborationreact-vs-vue-vs-svelte-enterpriseOutput path: $PRP_DIR/research-plans/{topic-slug}.research-plan.md (report the expanded absolute path to the user).
Write the expanded absolute output path to $PRP_DIR/state/prp-research-team.state so the Stop hook can validate:
mkdir -p "$PRP_DIR/state"
printf '%s\n' "$PRP_DIR/research-plans/{topic-slug}.research-plan.md" > "$PRP_DIR/state/prp-research-team.state"Just the file path, one line, no extra content.
Write the research plan to the output path using this exact template:
# Research Plan: {Research Question}
## Metadata
| Field | Value |
|-------|-------|
| Date | {YYYY-MM-DD} |
| Topic | {short topic name} |
| Domain | {PRIMARY / MIXED: list} |
| Complexity | {LOW / MEDIUM / HIGH} |
| Team Size | {N} researchers |
| Sub-questions | {N} |
| Tasks | {N} |
---
## Research Question
{The original research question, clearly stated and unambiguous.}
{If orchestration guidance was provided:}
**Orchestration**: {The orchestration guidance}
---
## Research Question Decomposition
| ID | Sub-question | Domain | Parallel | Dependencies | Assigned To |
|----|-------------|--------|----------|--------------|-------------|
| SQ-1 | {sub-question text} | {domain} | {yes/no} | {NONE or SQ-IDs} | {researcher name} |
| SQ-2 | ... | ... | ... | ... | ... |
### Dependency Graph
{ASCII dependency diagram showing parallel vs. sequential flow}
---
## Team Composition
### {Researcher 1 Name}
- **Focus**: {1-2 sentence description}
- **Sub-questions**: {SQ-IDs}
- **Model**: {sonnet / opus}
- **Output format**: {description of deliverable structure}
- **Completion criteria**: {measurable conditions}
**Spawn prompt**:
> {Complete, self-contained instructions for this agent. Must include:
> role statement, assigned sub-questions, methodology, output format,
> quality bar, and completion signal. The agent must be able to execute
> with ONLY this prompt — no external context.}
### {Researcher 2 Name}
{Same structure as above}
{Repeat for all researchers...}
---
## Research Tasks
### Wave 1: Foundation (Parallel)
| ID | Title | Assignee | Type | Dependencies | Acceptance Criteria | Effort |
|----|-------|----------|------|-------------|-------------------|--------|
| RT-1 | {title} | {name} | RESEARCH | NONE | {criteria} | {LOW/MED/HIGH} |
### Wave 2: Deep Analysis
| ID | Title | Assignee | Type | Dependencies | Acceptance Criteria | Effort |
|----|-------|----------|------|-------------|-------------------|--------|
| RT-N | {title} | {name} | ANALYSIS | RT-1, RT-2 | {criteria} | {LOW/MED/HIGH} |
### Wave 3: Synthesis
| ID | Title | Assignee | Type | Dependencies | Acceptance Criteria | Effort |
|----|-------|----------|------|-------------|-------------------|--------|
| RT-N | {title} | {name} | SYNTHESIS | RT-... | {criteria} | {LOW/MED/HIGH} |
### Cross-Cutting Concerns
- **Citations**: {format requirements}
- **Confidence levels**: Tag all findings as HIGH / MEDIUM / LOW with rationale
- **Contradictions**: When sources disagree, document both positions with evidence
- **Scope boundaries**: {when to stop investigating a thread}
---
## Team Orchestration Guide
### Prerequisites
This research plan is designed for execution using Claude Code's experimental **agent teams** feature. Before executing:
1. Ensure agent teams is enabled (experimental feature)
2. Review the team composition and adjust if needed
3. Confirm the research question and scope
### Execution Steps
1. **Create team**: Use `TeamCreate` to spawn all researchers defined in Team Composition
2. **Create shared tasks**: Use the shared task list to create all tasks from the Research Tasks section
3. **Set dependencies**: Link tasks with their dependencies so agents pick up work in the correct order
4. **Monitor progress**: Use delegate mode or direct messaging to check on researcher progress
5. **Collect outputs**: Each researcher posts findings to their assigned tasks
6. **Run synthesis**: The synthesis researcher integrates all findings into the final report
### Display Mode
Use **delegate mode** for autonomous execution:
- Researchers work independently on their assigned tasks
- The lead researcher monitors progress and resolves blockers
- Use `SendMessage` to communicate between researchers when dependencies complete
### Communication Patterns
- **Handoff**: When a Wave 1 researcher completes, notify dependent Wave 2 researchers via task updates
- **Clarification**: Researchers can message the lead for scope questions
- **Contradiction**: If two researchers find conflicting information, escalate to lead for resolution
### Plan Approval
Before execution, review:
- [ ] Team composition matches the research domain
- [ ] Spawn prompts are detailed enough for autonomous execution
- [ ] Task dependencies are correct
- [ ] Acceptance criteria are measurable
---
## Acceptance Criteria
Research is complete when ALL of the following are met:
- [ ] Every sub-question (SQ-*) has been investigated and answered
- [ ] Every research task (RT-*) has been completed and meets its acceptance criteria
- [ ] Findings are cited with sources and confidence levels
- [ ] Contradictions are documented with both positions
- [ ] A synthesis document integrates all findings into a coherent answer
- [ ] The original research question is directly answered with evidence
---
## Output Format: Final Report Structure
The final research report (produced during execution, not in this plan) should follow:
1. **Executive Summary** — Direct answer to the research question (2-3 paragraphs)
2. **Key Findings** — Bulleted list of major discoveries
3. **Detailed Analysis** — Section per sub-question with evidence
4. **Comparative Matrix** — If applicable, structured comparison table
5. **Recommendations** — Actionable next steps with confidence levels
6. **Sources** — All references with URLs and access dates
7. **Appendix** — Raw data, extended quotes, additional contextPHASE_6_CHECKPOINT:
GATE: Do NOT proceed to Phase 7 until the research plan file passes validation — all 6 required sections must be present:
## Research Question## Research Question Decomposition## Team Composition## Research Tasks## Team Orchestration Guide## Acceptance CriteriaDisplay a summary to the user:
## Research Plan Created
**File**: `{output path}`
**Question**: {research question}
### Team Composition ({N} researchers)
| Researcher | Focus | Model |
|------------|-------|-------|
| {name} | {1-line focus} | {model} |
### Plan Overview
- **Domain**: {domain classification}
- **Complexity**: {LOW/MEDIUM/HIGH}
- **Sub-questions**: {N}
- **Tasks**: {N} ({W1} parallel → {W2} analysis → {W3} synthesis)
### Execution
To execute this research plan with agent teams:
1. Review the plan: `read {output path}`
2. Create the team and start execution using the orchestration guide in the plan
### Manual Execution Alternative
If agent teams is not available, execute sequentially:
1. Work through Wave 1 tasks in parallel using Task tool subagents
2. Feed Wave 1 outputs into Wave 2 tasks
3. Synthesize in Wave 3PHASE_7_CHECKPOINT:
Wirasm/prp
4352925
Canonical home
since Oct 25, 2026
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.