Agent skill
maestro:parallel-exploration
Use when you need parallel, read-only exploration with task() (Scout fan-out)
Install this agent skill to your Project
npx add-skill https://github.com/ReinaMacCredy/maestro/tree/main/skills/built-in/maestro:parallel-exploration
SKILL.md
Parallel Exploration (Scout Fan-Out)
Overview
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, spawn one scout per sub-question, collect results, synthesize into a coherent picture.
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, use maestro skill maestro:dispatching with maestro task-next -> maestro task-claim.
When to Use
Use when:
- Investigation spans 2+ domains (code + tests, code + docs, code + config)
- Questions are independent (answer to A doesn't affect B)
- No edits needed (read-only exploration)
- The exploration likely spans multiple files or packages
Skip when:
- It's a single focused question answerable with one grep + one file read
- Questions are dependent (answer A materially changes what to ask for B)
- Work involves file edits (use Hive tasks instead)
Thinking "this is simple, I'll just do it myself"? If the investigation touches 3+ domains, fan out. Sequential exploration in a parallel-capable system is waste.
The Pattern
1. Decompose Into Independent Questions
Split your investigation into 2-4 independent sub-questions.
| Domain | Question shape |
|---|---|
| Codebase | "Where is X implemented? What files define it?" |
| Tests | "How is X tested? What patterns exist?" |
| Docs/OSS | "How do other projects implement X?" |
| Config | "How is X configured? What env vars affect it?" |
See reference/scout-patterns.md for concrete fan-out strategies: codebase survey, dependency analysis, pattern search, API surface mapping.
2. Write Scout Prompts
Each scout prompt must be specific, bounded, and evidence-oriented.
Return as a table. Do not read files outside src/.
Specific function. Defined output format. Bounded scope. Evidence-oriented.
</Good>
<Bad>
How does the skill system work? Look at everything related to skills and give me a summary.
Unbounded scope. No output format. Will return a vague narrative instead of evidence.
</Bad>
<Good>
Find all error handling patterns in src/commands/. For each try/catch block, return:
- File:line
- What error types are caught
- What action is taken (rethrow, log, swallow, wrap) Return as a table.
Specific artifact (try/catch). Defined output columns. Bounded directory.
</Good>
<Bad>
Look at error handling in the codebase.
No artifact specified. No output format. No scope boundary.
</Bad>
**Scout prompt checklist:**
- [ ] Specific target (function, pattern, file type -- not "everything about X")
- [ ] Bounded scope (directory, file glob, or explicit exclusions)
- [ ] Defined output format (table, list with file:line, or explicit columns)
- [ ] Evidence-oriented ("return file paths with line numbers", not "summarize")
### 3. Decide How Many Scouts
| Situation | Scouts | Rationale |
|-----------|--------|-----------|
| Focused question, 2 clear domains | 2 | Minimum useful parallelism |
| Typical investigation | 3 | Sweet spot: structure + behavior + tests/config |
| Complex unfamiliar subsystem | 4 | Maximum before synthesis overhead dominates |
| 5+ scouts | **Stop. Reframe.** | Decompose into 2 sequential rounds of 2-3 each |
**The overlap test:** Write out each scout's expected output before launching. If two scouts would return the same files, merge them or redefine boundaries.
### 4. Fan Out (Spawn All Before Waiting)
Launch all scouts in the same assistant message. Do not wait for results between launches.
```typescript
// GOOD: All scouts launched in one message
task({
subagent_type: 'scout-researcher',
description: 'Map skill registry structure',
prompt: `Map the file structure of src/skills/.
For each file: purpose, exports, and which modules import it.
Return as a table with columns: file, purpose, exports, importers.`,
});
task({
subagent_type: 'scout-researcher',
description: 'Trace skill loading data flow',
prompt: `Trace data flow for skill loading: from CLI invocation
through registry lookup to file read. List each function in the
chain with file:line. Return as an ordered list.`,
});
task({
subagent_type: 'scout-researcher',
description: 'Audit skill configuration points',
prompt: `Find all configuration that affects skill loading: env vars,
config file keys, CLI flags, defaults. Return as a table with
columns: source, key, default_value, effect.`,
});
// BAD: Sequential -- defeats the purpose
const result1 = await task({ ... }); // Waits here
const result2 = await task({ ... }); // Then waits here
5. Continue Working (Optional)
While scouts run, you can:
- Prepare synthesis structure
- Draft based on what you already know
- Work on unrelated aspects
You'll receive a <system-reminder> notification when each scout completes.
6. Synthesize Findings
This is the hardest step. Raw scout results are not the answer.
Synthesis process:
- Deduplicate -- List every file mentioned. Files cited by 2+ scouts are integration points.
- Resolve contradictions -- Scouts disagree? One is wrong. Re-read the code yourself. Never average.
- Identify gaps -- What wasn't found? Missing answers matter as much as found ones.
- Build narrative -- Write an integrated story with evidence, not a paste of each scout's output.
Integration point: registry.ts -- both CLI and loader depend on it. Gap: No tests found for the fallback path.
Cross-referenced. Integration points identified. Gaps noted.
</Good>
<Bad>
Scout 1 found: registry.ts, loader.ts, types.ts Scout 2 found: cli.ts calls loadSkill(), loadSkill() calls parseFile() Scout 3 found: SKILL_PATH env var, default is ./skills/
Dumped raw results. No integration. No gaps identified.
</Bad>
See `reference/synthesis-guide.md` for detailed patterns: resolving contradictions, prioritizing discoveries, gap analysis.
### 7. Verify Completeness
After synthesis, check:
- [ ] All scouts spawned before collecting any results (true fan-out)
- [ ] Scout prompts were specific and bounded (not "tell me about X")
- [ ] Contradictions resolved (not glossed over)
- [ ] Gaps identified and either investigated or noted
- [ ] Synthesis is a narrative with evidence, not a scout dump
## Diminishing Returns -- When to Stop Exploring
Exploration is seductive. You can always learn more. The goal is not complete knowledge -- it's sufficient knowledge to make design decisions.
### Stop signals
| Signal | What it means | Action |
|--------|--------------|--------|
| Scouts return the same files you already know about | You've mapped the domain | Stop. Start designing. |
| Follow-up scouts find edge cases, not new subsystems | Core structure is understood | Note edge cases. Start designing. |
| You're on round 3+ of scouts | Diminishing returns | Stop. What you don't know, you'll learn during implementation. |
| You can explain the subsystem to someone else | Sufficient understanding | Stop. Write the context doc. |
| You're exploring "just in case" | Curiosity, not necessity | Stop. Explore when blocked, not preemptively. |
### The 2-round rule
- **Round 1:** Broad survey (2-4 scouts). Map structure, data flow, config.
- **Round 2:** Targeted follow-ups (1-2 scouts). Fill specific gaps identified in synthesis.
- **Round 3:** Almost never needed. If two rounds didn't answer your question, either reframe the question or read the code yourself.
### Exploration vs. design time
| Codebase familiarity | Exploration budget | Then |
|---------------------|-------------------|------|
| Greenfield / never seen | 1 broad round + 1 targeted round | Start designing |
| Familiar codebase, new subsystem | 1 targeted round | Start designing |
| Familiar codebase, known subsystem | Skip scouts. Read 1-2 files yourself. | Start designing |
**The test:** Can you write the `## Discovery` section of the plan? If yes, you have explored enough. If no, identify the specific gap and send one more targeted scout.
## Common Mistakes
| Mistake | Problem | Fix |
|---------|---------|-----|
| Sequential spawning | `await task()` blocks; no parallelism | Launch all scouts in the same message |
| Vague prompts | "Tell me about X" returns vague summaries | Use the scout prompt checklist above |
| Too many scouts (5+) | Synthesis overhead exceeds parallelism benefit | Max 4 per round; reframe if you need more |
| Overlapping scopes | Two scouts search the same files | Use the overlap test before launching |
| Dependent questions | Scout B needs Scout A's answer | Run sequentially or make independent |
| Scout dump synthesis | Paste each scout's output without integration | Write a narrative; see synthesis guide |
| Exploring forever | "Just one more scout" delays design | Apply the 2-round rule |
| Using scouts for edits | Scouts are read-only | Use `maestro:dispatching` for implementation |
## Prompt Templates
### Codebase Structure
Map the file structure of [DIRECTORY]. For each file, return:
- File path
- Purpose (1 sentence)
- Exports (function/class/type names)
- Which other modules import from it
Return as a table. Do not read files outside [DIRECTORY].
### Data Flow Trace
Trace the data flow for [OPERATION]:
- Where does the data enter? (entry point, function signature)
- What transforms are applied? (each step with file:line)
- Where does the data exit? (return value, side effect, output)
Return as an ordered list with file:line for each step.
### Test Coverage Audit
Find all tests related to [FEATURE] in [TEST_DIRECTORY]:
- What test files exist?
- What behaviors are tested? (list each test name)
- What edge cases are covered?
- What's obviously missing?
Return as a table with columns: file, test_name, behavior_tested.
### Dependency Impact
Find all files that depend on [MODULE/FUNCTION]:
- Direct imports (files that import from [MODULE])
- Call sites (files that call [FUNCTION] with file:line)
- Type references (files that use [TYPE] in signatures)
Return as a table with columns: file, relationship_type, specific_usage.
### Configuration Audit
Find all configuration points for [SUBSYSTEM]:
- Environment variables
- Config file keys
- CLI flags
- Hardcoded defaults
For each, return: source, key, default_value, effect. Return as a table.
## Reference Documents
- `reference/scout-patterns.md` -- Concrete fan-out strategies for common investigation types
- `reference/synthesis-guide.md` -- Patterns for merging findings, resolving contradictions, gap analysis
Recommended Agent Skills
Expand your agent's capabilities with these related and highly-rated skills.
maestro-skill-author
Create, update, or debug maestro built-in skills. Covers SKILL.md frontmatter, reference directory structure, step-file architecture, build-time embedding, naming conventions, alias management, and registry validation. Use when creating a new maestro built-in skill, modifying an existing SKILL.md, adding reference files, debugging skill loading failures, updating the skills registry, or working on the skills full port. Also use when frontmatter validation fails, skills don't appear in skill-list, or reference files fail to load.
maestro:brainstorming
Use before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
mcp-builder
Guide for creating high-quality MCP (Model Context Protocol) servers that enable LLMs to interact with external services through well-designed tools. Use when building MCP servers to integrate external APIs or services, whether in Python (FastMCP) or Node/TypeScript (MCP SDK).
maestro:plan-review-loop
Deep-review any plan (maestro, Codex, Claude Code plan mode, or plain markdown) using iterative subagent review loops with BMAD-inspired adversarial edge-case discovery. Spawns reviewer subagents that find issues using pre-mortem, inversion, and red-team techniques, auto-fixes them with structured fix strategies, and re-reviews until the plan passes with zero actionable issues. Use when the user says 'review the plan', 'deep review', 'check the plan thoroughly', 'review loop', 'validate before approving', or wants rigorous plan validation before execution. Also use proactively before plan-approve when the plan is complex or high-risk.
maestro:research
Structured research workflow for maestro features. Guides tool selection across three tiers (codebase exploration, Context7 for library docs, NotebookLM for deep analysis), defines research patterns, finding organization via memory_write, and completion criteria. Use during the research pipeline stage after feature_create and before plan_write. Also use when investigating a problem space, comparing technical approaches, gathering context on unfamiliar code, or needing to understand external library APIs before making architectural decisions.
cli-for-agents
Designs or reviews CLIs so coding agents can run them reliably: non-interactive flags, layered --help with examples, stdin/pipelines, fast actionable errors, idempotency, dry-run, and predictable structure. Use when building a CLI, adding commands, writing --help, or when the user mentions agents, terminals, or automation-friendly CLIs.
Didn't find tool you were looking for?