From hive
Decomposes multi-domain investigations into independent sub-questions and runs parallel scout agents for read-only exploration across code, tests, docs.
npx claudepluginhub tctinh/agent-hive --plugin hiveThis skill uses the workspace's default tool permissions.
When you need to answer "where/how does X work?" across multiple domains (codebase, tests, docs, OSS), investigating sequentially wastes time. Each investigation is independent and can happen in parallel.
Orchestrates multi-wave parallel agent exploration for large-scale codebase research (>25 files) and complex cross-domain systems, outputting unified reports with completeness scores.
Orchestrates parallel agents to find all query-relevant files in codebase with orthogonal exploration. Delivers topic overview + file lists with line ranges. Scales thoroughness from quick single-agent to multi-wave thorough searches.
Share bugs, ideas, or general feedback.
When you need to answer "where/how does X work?" across multiple domains (codebase, tests, docs, OSS), investigating sequentially wastes time. Each investigation is independent and can happen in parallel.
Core principle: Decompose into independent sub-questions, invoke one scout agent per sub-question, and synthesize the results together.
Safe in Planning mode: This is read-only exploration. It is OK to use during exploratory research even when there is no feature, no plan, and no approved tasks.
This skill is for read-only research. For parallel implementation work, refer to the skill at ../dispatching-parallel-agents/SKILL.md and invoke @forager directly for each runnable task.
Default to this skill when: Use when:
Only skip this skill when:
Important: Do not treat "this is exploratory" as a reason to avoid delegation. This skill is specifically for exploratory research when fan-out makes it faster and cleaner.
Load this skill before any multi-domain, read-only investigation that benefits from Scout fan-out.
browser as one of the read-only slices.web or io.github.upstash/context7/* for the docs/OSS slice.todo only when you need to track multiple questions and evidence coverage during synthesis.vscode/memory only for findings the parent agent or a later turn will need after synthesis.Split your investigation into 2-4 independent sub-questions. Good decomposition:
| Domain | Question Example |
|---|---|
| Codebase | "Where is X implemented? What files define it?" |
| Tests | "How is X tested? What test patterns exist?" |
| Docs/OSS | "How do other projects implement X? What's the recommended pattern?" |
| Config | "How is X configured? What environment variables affect it?" |
Bad decomposition (dependent questions):
Start all independent scout requests before waiting on any result.
Invoke the @scout agent via the agent tool for question 1.
Invoke the @scout agent via the agent tool for question 2.
Invoke the @scout agent via the agent tool for question 3.
Key points:
While tasks run, you can:
Each scout result returns to the parent chat when it completes.
When each task completes, its result is returned directly. Collect the outputs from each task and proceed to synthesis.
Combine results from all tasks:
No manual cancellation is required for these agent invocations.
Investigate [TOPIC] in the codebase:
- Where is [X] defined/implemented?
- What files contain [X]?
- How does [X] interact with [Y]?
Return:
- File paths with line numbers
- Brief code snippets as evidence
- Key patterns observed
Investigate how [TOPIC] is tested:
- What test files cover [X]?
- What testing patterns are used?
- What edge cases are tested?
Return:
- Test file paths
- Example test patterns
- Coverage gaps if obvious
Research [TOPIC] in external sources:
- How do other projects implement [X]?
- What does the official documentation say?
- What are common patterns/anti-patterns?
Return:
- Links to relevant docs/repos
- Key recommendations
- Patterns that apply to our codebase
Investigation: "How does the API routing system work?"
Decomposition:
Fan-out:
Invoke the @scout agent via the agent tool to find API route implementation.
Invoke the @scout agent via the agent tool to analyze concurrency.
Invoke the @scout agent via the agent tool to find the notification mechanism.
Results:
background-tools.ts (tool definition), index.ts (registration)manager.ts with concurrency=3 default, queue-based schedulingsession.prompt() call in manager for parent notificationSynthesis: Complete picture of background task lifecycle in ~1/3 the time of sequential investigation.
Spawning sequentially (defeats the purpose):
Bad: invoke one scout agent, wait, then decide whether to invoke the next.
Good: issue all independent scout invocations in the same response.
Too many tasks (diminishing returns):
Dependent questions:
Using for edits:
After using this pattern, verify: