Agent skill

parallel-research

Research scope too big? This skill decomposes large questions into independent parts, spawns parallel researchers, and synthesizes findings. Essential when comprehensive research would overflow a single context window.

Stars 18
Forks 0

Install this agent skill to your Project

npx add-skill https://github.com/malhashemi/dotfiles/tree/main/dot_config/opencode/skill/parallel-research

SKILL.md

Parallel Research

Overview

When research scope is large, decompose into independent questions and spawn parallel researchers. This skill turns a single researcher into a research coordinator.

When to Use

  • When research question spans multiple distinct domains
  • When research would exceed context window if done sequentially
  • When independent aspects can be researched concurrently
  • When RPIV or Planner requests broad research coverage

Decomposition Criteria

A research question should be decomposed when:

Criterion Threshold Example
Topic breadth 3+ distinct areas "Research auth, caching, AND API patterns"
Estimated context >50% for single researcher Large codebase analysis
Independence Aspects don't depend on each other Security review vs performance review

A research question should NOT be decomposed when:

  • Topics are deeply interrelated
  • Sequential discovery is required (A informs B)
  • Total scope fits in single context window

Decomposition Process

Step 1: Analyze Research Scope

Parse the research request to identify:

  • Core questions that must be answered
  • Independent aspects that can be parallelized
  • Dependencies between aspects (if any)

Step 2: Design Research Questions

For each independent aspect, create a focused research question:

markdown
## Research Question: [Aspect Name]

**Focus**: [Specific scope - what to research]
**Boundaries**: [What NOT to research - stay focused]
**Output**: [Expected deliverable format]
**Context needed**: [What context to provide]

Step 3: Spawn Parallel Researchers

Use the Task tool to spawn researchers:

task({
  subagent_type: "researcher",
  description: "Research [aspect name]",
  prompt: "Research Question: [question]
           Focus: [scope]
           Boundaries: [limits]
           Output format: [expected format]
           
           Return findings as structured Markdown with file:line references."
})

Spawn all independent researchers simultaneously by issuing multiple Task calls in parallel.

Step 4: Collect Results

As each researcher returns:

  1. Validate the response addresses the question
  2. Extract key findings
  3. Note any cross-references or dependencies discovered

Step 5: Synthesize Findings

Combine all research into a unified output:

markdown
# Research Synthesis: [Original Topic]

## Executive Summary
[High-level findings across all research tracks]

## Detailed Findings

### [Aspect 1 Name]
[Synthesized findings from Researcher 1]
- Key discovery 1 (file:line)
- Key discovery 2 (file:line)

### [Aspect 2 Name]
[Synthesized findings from Researcher 2]
- Key discovery 1 (file:line)
- Key discovery 2 (file:line)

## Cross-Cutting Themes
[Patterns or connections discovered across research tracks]

## Recommendations
[Actionable next steps based on findings]

## References
[All file:line references from all researchers]

Output to Parent

When research is complete, return to orchestrator (RPIV or Planner):

RESEARCH_COMPLETE
Topics researched: N
Key findings:
  - [Finding 1]
  - [Finding 2]
Full synthesis: [path to research doc]

Error Handling

  • Researcher fails: Continue with other researchers, note gap in synthesis
  • Context overflow in child: Accept partial findings, note limitation
  • Conflicting findings: Document both perspectives, flag for human review

Expand your agent's capabilities with these related and highly-rated skills.

malhashemi/dotfiles

phase-execution

Your bulletproof guide to executing implementation phases! Handles commits, detects when phases are too big, and knows when to bail cleanly. Load this whenever you're implementing a phase - it provides clean commit protocol and signals the orchestrator when things go sideways.

18 0
Explore
malhashemi/dotfiles

plan-review

Catch oversized phases BEFORE implementation begins! This skill reviews plans for sizing, dependencies, and completeness - flagging phases that need decomposition before a single line of code is written. Load this when validating plans pre-implementation.

18 0
Explore
malhashemi/dotfiles

brand-palette

Brand color discovery and palette generation skill. This skill should be used when helping users create brand color palettes, design systems, or Tailwind color configs. It guides through hue selection (RYB color wheel), chroma/tone decisions, and generates Obsidian-compatible palette reports with APCA accessibility validation. Supports starting from hex color or OKLCH values for refinement workflows. Triggers: "brand colors", "palette", "color scheme", "design system colors", "Tailwind colors", "generate palette from hex", "generate palette from OKLCH", or when users describe brand values that imply color decisions.

18 0
Explore
malhashemi/dotfiles

pr-review-orchestration

Automated PR review cycle for RPIV orchestration. Waits for Gemini reviews, assesses feedback, implements fixes, and manages the review loop. Used by Planner agent after RPIV opens PRs. This skill is triggered automatically by RPIV when entering the PR Review phase.

18 0
Explore
malhashemi/dotfiles

pr-review

This skill provides a complete workflow for handling GitHub Pull Request reviews, specifically optimized for @gemini-code-assist automated reviews. This skill should be used when addressing PR review comments, responding to reviewers, resolving threads, requesting re-reviews, or merging PRs after feedback is addressed. Triggers include: /pr-review command, "address PR feedback", "handle review comments", "respond to gemini", or any PR review lifecycle management request.

18 0
Explore
malhashemi/dotfiles

plan-validation

Validates implementation plan execution by verifying success criteria and identifying deviations. This skill should be used after a phase or plan has been implemented and committed. It runs automated checks (tests, types, lint), compares actual changes against the plan's specifications, and generates a validation report documenting what was completed, what deviated, and what needs manual testing.

18 0
Explore

Didn't find tool you were looking for?

Be as detailed as possible for better results