swarm-engine 1.1.0 → 1.3.0

package/commands/discover.md

@@ -0,0 +1,102 @@
+---
+description: "Hypothesis-driven development — form theories, test cheaply, build the winner"
+argument-hint: "<complex problem where the right approach is unclear>"
+---
+
+You are running a discovery cycle: form hypotheses, test them cheaply, then implement the winner.
+
+Follow the `swarm-output-style` skill for ALL output formatting.
+
+## Task
+$ARGUMENTS
+
+## Workflow
+
+### Step 0: Show Pre-flight Plan
+
+Before creating any team or spawning any agent, show the plan:
+
+Show the pre-flight plan (see swarm-output-style skill). Include:
+- All phases (Hypothesize, Experiment, Implement, Review)
+- Agents per phase with model and focus
+- Estimated cost (~$0.12 hypothesize, ~$0.12 experiment at sonnet rates, ~$0.19 implement, ~$0.20 review)
+- Estimated time (~20-40 min total)
+
+Wait for user approval before proceeding.
+
+### Setup: Create Team
+1. Create a team with `TeamCreate` (name: `discover-<timestamp>`)
+2. Create tasks with `TaskCreate` for each work unit
+
+### Phase 1: Hypothesize — parallel
+
+Show the phase banner with running total (see swarm-output-style skill).
+
+Spawn 2-3 researcher teammates (sonnet) simultaneously, each with `team_name`, `name`, and `run_in_background: true`:
+- Each researcher explores a different angle of the problem
+- Each proposes a hypothesis: "I think the best approach is X because Y"
+- Each identifies what evidence would prove or disprove the hypothesis
+
+As each completes: show a one-line completion summary (see swarm-output-style skill), then send `shutdown_request` via `SendMessage`.
+
+Present the hypotheses to the user. Select 2-3 to test.
+
+### Phase 2: Experiment — parallel (cheap, fast)
+
+Show the phase banner with running total (see swarm-output-style skill).
+
+Spawn 2-3 implementer teammates (sonnet, not opus — keep it cheap) simultaneously, each with `team_name`, `name`, and `run_in_background: true`:
+- Each builds a minimal proof-of-concept for one hypothesis
+- NOT a full implementation — just enough to validate or invalidate
+- Time-box: keep experiments under 5 minutes each
+- Each reports: hypothesis confirmed or rejected, with evidence
+
+As each completes: show a one-line completion summary (confirmed/rejected + key evidence) (see swarm-output-style skill), then send `shutdown_request` via `SendMessage`.
+
+Present the experiment results. Identify the winning hypothesis.
+
+### Phase 3: Implement — sequential (depends on Phase 2)
+
+Show the phase banner with running total (see swarm-output-style skill).
+
+Spawn an implementer teammate (opus) with `team_name`, `name`, and `run_in_background: true`:
+- Full implementation of the winning approach
+- Informed by what was learned from ALL experiments (including failed ones)
+- Include tests
+
+As the teammate completes: show a one-line completion summary (see swarm-output-style skill), then send `shutdown_request` via `SendMessage`.
+
+### Phase 4: Review — parallel (depends on Phase 3)
+
+Show the phase banner with running total (see swarm-output-style skill).
+
+Spawn 2 reviewer teammates (opus) simultaneously with `team_name`, `name`, and `run_in_background: true`:
+- **reviewer-correctness**: Logic, edge cases, error handling
+- **reviewer-convention**: Project patterns, code style
+
+As each completes: show a one-line verdict (PASS/FAIL + finding count) (see swarm-output-style skill), then send `shutdown_request` via `SendMessage`.
+
+### Phase 5: Report
+
+Show the full post-completion summary (see swarm-output-style skill). Include:
+- Status (PASS / NEEDS ATTENTION / FAILED)
+- Metrics (phases, agents, duration, tokens, cost)
+- Hypotheses tested (table with confirmed/rejected)
+- Winner and rationale
+- What was learned from rejected hypotheses
+- What changed (files)
+- Review gate result
+- Next steps
+
+### Cleanup
+1. Send `shutdown_request` via `SendMessage` to any remaining active teammates
+2. Call `TeamDelete` to clean up the team
+
+## Rules
+- All agents must be spawned as team members (TeamCreate → TaskCreate → Agent with team_name/name/run_in_background → SendMessage shutdown → TeamDelete)
+- Experiments must be CHEAP — use sonnet, keep scope minimal, time-box to 5 minutes
+- Failed experiments are valuable — include their learnings in the final implementation context
+- The user approves the winning hypothesis before full implementation begins
+- If no hypothesis is clearly better, recommend combining the best elements from multiple experiments
+- Follow the swarm-output-style skill for ALL output formatting
+- Show the plan first, spend tokens second

package/commands/dynamic.md

@@ -0,0 +1,136 @@
+---
+description: "Let the planner decompose your task into a custom agent workflow -- no pattern selection needed"
+argument-hint: "<any task -- the planner figures out the approach>"
+---
+
+You are running a dynamic orchestration: instead of following a predefined pattern, the planner analyzes the task and builds a custom workflow.
+
+Follow the `swarm-output-style` skill for ALL output formatting.
+
+## Task
+$ARGUMENTS
+
+## Workflow
+
+### Step 0: Check Memory
+
+Search for relevant context:
+```bash
+cd ~/dev/swarm-engine && npx tsx src/cli/index.ts memory search "<relevant keywords>"
+```
+
+### Step 1: Analyze and Decompose
+
+You ARE the planner. Analyze the task and decompose it into subtasks. For each subtask, decide:
+
+1. **What agent type** should handle it (researcher, implementer, reviewer, tester, debugger, refactorer, etc.)
+2. **What model** it needs (expensive tasks like security review get claude-opus-4-6, simple tasks like scanning get claude-sonnet-4-6)
+3. **What dependencies** it has (which subtasks must complete before this one can start)
+4. **What files** it will touch (no two agents should modify the same files)
+
+Group subtasks into waves based on dependencies:
+- **Wave 1**: Independent tasks that can run in parallel (typically research)
+- **Wave 2**: Tasks that depend on Wave 1 results (typically implementation)
+- **Wave 3**: Tasks that depend on Wave 2 (typically review, testing)
+- Add more waves as needed
+
+### Step 2: Show Pre-flight Plan
+
+Present the decomposition as a pre-flight plan:
+
+```
+## Dynamic Orchestration Plan
+
+**Task**: [task description]
+**Waves**: [N] | **Agents**: [N] | **Est. cost**: ~$[amount] | **Est. time**: ~[duration]
+
+### Wave 1 -- parallel (~[time], ~$[cost])
+| Agent | Type | Model | Focus | Dependencies |
+|-------|------|-------|-------|-------------|
+| `name` | [type] | [model] | [what it does] | none |
+
+### Wave 2 -- parallel (~[time], ~$[cost])
+| Agent | Type | Model | Focus | Dependencies |
+|-------|------|-------|-------|-------------|
+| `name` | [type] | [model] | [what it does] | Wave 1 |
+
+[repeat for all waves]
+
+**File ownership:**
+| Agent | Files |
+|-------|-------|
+| `name` | [files this agent will touch] |
+
+Proceed?
+```
+
+Wait for user approval before proceeding.
+
+### Step 3: Create Team and Execute
+
+1. `TeamCreate` (name: `dynamic-<timestamp>`)
+2. `TaskCreate` for each wave
+
+Execute each wave in order:
+
+For each wave:
+1. Show the phase banner with running total
+2. Spawn all agents in this wave in parallel, each with `team_name`, `name`, and `run_in_background: true`
+3. Include context from all completed previous waves
+4. As each completes: show a one-line completion summary, then send `shutdown_request`
+5. After all agents in the wave complete: show wave summary
+
+**Between waves**: If any agent failed or returned low confidence, show error recovery options before proceeding to the next wave.
+
+### Step 4: Quality Gate
+
+After the final wave, assess the combined output:
+- Did all agents succeed?
+- Are there file conflicts or inconsistencies between agent outputs?
+- Do the changes compile/pass linting?
+
+If issues found, spawn a fixer agent to resolve them.
+
+### Step 5: Record and Report
+
+Store results in engine memory:
+```bash
+echo "<outcome summary>" | cd ~/dev/swarm-engine && npx tsx src/cli/index.ts memory store outcome "<title>" --repo "<repo>"
+```
+
+Show the full post-completion summary (see swarm-output-style skill). Include:
+- Status
+- Wave breakdown (which agents ran in each wave)
+- Metrics (waves, agents, duration, tokens, cost)
+- What changed (files with git diff --stat)
+- Quality gate result
+- Next steps
+
+### Cleanup
+1. Send `shutdown_request` to any remaining active teammates
+2. Call `TeamDelete` to clean up the team
+
+## Decomposition Guidelines
+
+When deciding how to break down a task:
+
+**Research first**: Always start with at least one researcher to understand the codebase before modifying it.
+
+**Parallelize aggressively**: If two subtasks touch different files and don't depend on each other, run them in parallel.
+
+**Right-size agents**: Use the cheapest model that can handle the task. Research and scanning with sonnet. Implementation and review with opus.
+
+**File ownership**: Each file should be owned by exactly one agent. If two agents need the same file, make one depend on the other.
+
+**Review everything**: The final wave should always include at least one reviewer checking the combined output.
+
+**Keep it simple**: Most tasks need 2-4 waves and 3-8 agents. Don't over-decompose a task that one agent could handle. If the task is simple, use 1 wave with 1-2 agents.
+
+## Rules
+- Show the plan first, spend tokens second
+- All agents must use team protocol (TeamCreate, Agent with team_name/name/run_in_background, SendMessage shutdown, TeamDelete)
+- No two agents modify the same files in the same wave
+- Every agent dispatch includes full context from previous waves
+- Always include a review step in the final wave
+- Follow the swarm-output-style skill for ALL output formatting
+- Maximum 6 waves -- if you need more, the task should be split into separate orchestrations

package/commands/fix-pr.md

@@ -5,6 +5,8 @@ argument-hint: "<PR number or URL>"
 
 You are fixing PR review comments by dispatching parallel implementers grouped by file.
 
+Follow the `swarm-output-style` skill for ALL output formatting.
+
 ## Task
 $ARGUMENTS
 
@@ -25,46 +27,48 @@ For each file group, classify every comment:
 - **Nit/style fix** → assign to implementer (sonnet)
 - **Question/discussion** → skip, include in report
 
-### Step 3: Present Plan
-Show the user the dispatch plan:
+### Step 3: Show Pre-flight Plan
+
+Show the pre-flight plan (see swarm-output-style skill). Use the dispatch plan format:
 
 ```
-## Fix Plan
+## Orchestration Plan
+
+**Task**: Fix [N] review comments across [M] file groups for PR #[number]
+**Pattern**: parallel-fix | **Phases**: 1 | **Agents**: [N] | **Est. cost**: ~$[amount] | **Est. time**: ~[duration]
 
-| File Group | Comments | Agent | Model | Summary |
-|------------|----------|-------|-------|---------|
-| src/foo.py | 3        | implementer | opus   | [what to fix] |
-| src/bar.py | 1        | implementer | sonnet | [style nit] |
-| src/baz.py | 2        | — (skipped) | —      | [questions only] |
+### Phase 1: Fix -- parallel (~[time], ~$[cost])
+| Agent | Model | Focus |
+|-------|-------|-------|
+| `fixer-foo` | opus   | src/foo.py — [what to fix] |
+| `fixer-bar` | sonnet | src/bar.py — [style nit] |
+| `fixer-baz` | —      | src/baz.py — SKIPPED (questions only) |
+
+Proceed?
 ```
 
-Ask the user to approve before proceeding.
+Wait for user approval before proceeding.
 
 ### Step 4: Dispatch Implementers
+
+Show the phase banner with running total (see swarm-output-style skill).
+
 Spawn one implementer teammate per file group, ALL in parallel, each with `team_name`, `name` (e.g., `fixer-foo`, `fixer-bar`), and `run_in_background: true`. Each dispatch includes:
 - The exact comment text for their file(s)
 - The full PR diff for context
 - The original PR description
 - Clear instructions on what to change
 
-As each teammate completes, send it a `shutdown_request` via `SendMessage` to close its split pane.
+As each completes: show a one-line completion summary (see swarm-output-style skill), then send `shutdown_request` via `SendMessage`.
 
 ### Step 5: Report
-Once all implementers complete, produce a summary:
 
-```
-## PR Fix Report
-
-### Comments Addressed
-- [file:line — what was fixed, which comment]
-
-### Comments Skipped
-- [file:line — why (question/discussion)]
-
-### Next Steps
-- Push changes: `git push`
-- Re-request review: `gh pr edit <the PR> --add-reviewer [reviewer]`
-```
+Show the full post-completion summary (see swarm-output-style skill). Include:
+- Status (PASS / NEEDS ATTENTION)
+- Metrics (agents, duration, tokens, cost)
+- Comments addressed (file:line — what was fixed, which comment)
+- Comments skipped (file:line — why)
+- Next steps (git push, re-request review)
 
 ### Cleanup
 1. Send `shutdown_request` via `SendMessage` to any remaining active teammates
@@ -76,3 +80,5 @@ Once all implementers complete, produce a summary:
 - Group by file to avoid merge conflicts between parallel implementers
 - Include the exact comment text in each implementer dispatch
 - Use opus for logic/behavior changes, sonnet for style/nit fixes
+- Follow the swarm-output-style skill for ALL output formatting
+- Show the plan first, spend tokens second

package/commands/postmortem.md

@@ -0,0 +1,106 @@
+---
+description: "Root cause analysis — trace an error or incident back to its origin and produce a fix"
+argument-hint: "<error message, failing test, or incident description>"
+---
+
+You are running a postmortem analysis: systematically trace an error back to its root cause, understand how it happened, fix it, and prevent it from happening again.
+
+Follow the `swarm-output-style` skill for ALL output formatting.
+
+## Task
+$ARGUMENTS
+
+## Workflow
+
+### Step 0: Show Pre-flight Plan
+
+Before creating any team or spawning any agent, show the plan:
+
+Show the pre-flight plan (see swarm-output-style skill). Include:
+- All phases (Reproduce, Diagnose, Fix, Verify)
+- Agents per phase with model and focus
+- Estimated cost (~$0.12 reproduce, ~$0.15 diagnose, ~$0.19 fix, ~$0.23 verify/review)
+- Estimated time (~15-25 min total)
+
+Wait for user approval before proceeding.
+
+### Setup: Create Team
+1. Create a team with `TeamCreate` (name: `postmortem-<timestamp>`)
+2. Create tasks with `TaskCreate` for each work unit
+
+### Phase 1: Reproduce and Gather Evidence — parallel
+
+Show the phase banner with running total (see swarm-output-style skill).
+
+Spawn 3 researcher teammates (sonnet) simultaneously, each with `team_name`, `name`, and `run_in_background: true`:
+
+- **`researcher-reproduce`**: Reproduce the error. Find the exact steps, inputs, or conditions that trigger it. If a test fails, run it and capture the full output. If it's a runtime error, trace the call stack.
+- **`researcher-history`**: Check git history. When was this last working? What changed? Use `git log`, `git blame`, `git bisect` thinking to identify the commit or time window where the breakage was introduced.
+- **`researcher-context`**: Check memory and vault for related past incidents. Search for similar errors, known fragile areas, or prior decisions that constrained the implementation. Run `~/.claude/scripts/swarm-vault.sh search "<error keywords>"`.
+
+As each completes: show a one-line completion summary (see swarm-output-style skill), then send `shutdown_request` via `SendMessage`.
+
+### Phase 2: Diagnose — sequential
+
+Show the phase banner with running total (see swarm-output-style skill).
+
+Spawn a debugger teammate (opus) with `team_name`, `name` (`diagnostician`), and `run_in_background: true`.
+
+Provide ALL evidence from Phase 1. The debugger should:
+1. Identify the root cause (not the symptom)
+2. Explain the chain of events: what triggered what
+3. Identify contributing factors (was there a missing test? a bad assumption? a race condition?)
+4. Classify the failure type: regression, design flaw, edge case, environment issue, dependency change
+5. Propose a fix
+
+As the teammate completes: show a one-line completion summary (see swarm-output-style skill), then send `shutdown_request` via `SendMessage`.
+
+Present the diagnosis to the user. Proceed after approval.
+
+### Phase 3: Fix — sequential
+
+Show the phase banner with running total (see swarm-output-style skill).
+
+Spawn an implementer teammate (opus) with `team_name`, `name` (`fixer`), and `run_in_background: true`:
+
+- Fix the root cause, not just the symptom
+- Add a regression test that would have caught this
+- If the fix touches a fragile area, add defensive checks
+
+As the teammate completes: show a one-line completion summary (see swarm-output-style skill), then send `shutdown_request` via `SendMessage`.
+
+### Phase 4: Verify — parallel
+
+Show the phase banner with running total (see swarm-output-style skill).
+
+Spawn 2 teammates simultaneously with `team_name`, `name`, and `run_in_background: true`:
+
+- **`verifier`** (tester, sonnet): Run the full test suite. Confirm the regression test passes. Confirm no other tests broke.
+- **`reviewer-fix`** (reviewer, opus): Review the fix for correctness. Check that it addresses the root cause, not a surface symptom. Look for similar patterns elsewhere in the codebase that might have the same vulnerability.
+
+As each completes: show a one-line completion summary (see swarm-output-style skill), then send `shutdown_request` via `SendMessage`.
+
+### Phase 5: Report
+
+Show the full post-completion summary (see swarm-output-style skill). Include:
+- Status (PASS / NEEDS ATTENTION / FAILED)
+- Metrics (phases, agents, duration, tokens, cost)
+- Incident timeline (last working state → change introduced → discovered → fixed)
+- Root cause and contributing factors
+- Fix applied (files changed, regression test added)
+- Prevention checklist (actionable, not generic)
+- Verification results (test count, reviewer verdict)
+- Next steps
+
+### Cleanup
+1. Send `shutdown_request` via `SendMessage` to any remaining active teammates
+2. Call `TeamDelete` to clean up the team
+
+## Rules
+- All agents must be spawned as team members (TeamCreate → TaskCreate → Agent with team_name/name/run_in_background → SendMessage shutdown → TeamDelete)
+- Always find the ROOT cause, not the surface symptom. "X was null" is a symptom. "Input validation was missing because the API contract changed in v2 but the handler wasn't updated" is a root cause.
+- The regression test is mandatory. If the fix doesn't include a test that would have caught the original failure, the postmortem is incomplete.
+- Check for similar patterns elsewhere. If a bug exists in one place, the same mistake may exist in similar code.
+- The Prevention section should be actionable, not generic. "Write more tests" is useless. "Add null check tests for all handler parameters in src/api/handlers/" is actionable.
+- Follow the swarm-output-style skill for ALL output formatting
+- Show the plan first, spend tokens second

package/commands/red-team.md

@@ -5,30 +5,53 @@ argument-hint: "<feature or implementation to red-team>"
 
 You are running an adversarial red-team cycle where a builder implements and a breaker tries to destroy.
 
+Follow the `swarm-output-style` skill for ALL output formatting.
+
 ## Task
 $ARGUMENTS
 
 ## Workflow
 
+### Step 0: Show Pre-flight Plan
+
+Before creating any team or spawning any agent, show the plan:
+
+Show the pre-flight plan (see swarm-output-style skill). Include:
+- All phases (Research, Build, Break, Harden)
+- Agents per phase with model and focus
+- Estimated cost (~$0.08 research, ~$0.19 build, ~$0.45 break, ~$0.34 harden/verify)
+- Estimated time (~15-30 min total)
+
+Wait for user approval before proceeding.
+
 ### Setup: Create Team
 1. Create a team with `TeamCreate` (name: `red-team-<timestamp>`)
 2. Create tasks with `TaskCreate` for each work unit
 3. Create a scratchpad at `.claude/scratchpad/<team-name>.md` for cross-agent communication. Pass its path to all agent dispatches.
 
 ### Phase 1: Research (parallel)
+
+Show the phase banner with running total (see swarm-output-style skill).
+
 Spawn 2 researcher teammates (sonnet) with `team_name`, `name`, and `run_in_background: true`:
 - `researcher-code`: Understand the codebase area being worked on
 - `researcher-attack`: Research common vulnerabilities and failure modes for this type of feature
 
-As each completes, send `shutdown_request`.
+As each completes: show a one-line completion summary (see swarm-output-style skill), then send `shutdown_request`.
 
 ### Phase 2: Build (sequential)
+
+Show the phase banner with running total (see swarm-output-style skill).
+
 Spawn an implementer teammate (opus) with `team_name`, `name` (`builder`), and `run_in_background: true`.
 Include research findings as context. Implement the feature.
 
-As the teammate completes, send `shutdown_request`.
+As the teammate completes: show a one-line completion summary (see swarm-output-style skill), then send `shutdown_request`.
 
 ### Phase 3: Break (parallel)
+
+Show the phase banner with running total (see swarm-output-style skill).
+
 Spawn 3 breaker teammates simultaneously with `team_name`, `name`, and `run_in_background: true`:
 
 1. **`breaker-edge-cases`** (devils-advocate, opus) — Probe null inputs, empty collections, boundary conditions, concurrent access, network failures, resource exhaustion
@@ -37,39 +60,29 @@ Spawn 3 breaker teammates simultaneously with `team_name`, `name`, and `run_in_b
 
 Each breaker gets the full implementation from Phase 2.
 
-As each completes, send `shutdown_request`.
+As each completes: show a one-line completion summary (see swarm-output-style skill), then send `shutdown_request`.
 
 ### Phase 4: Harden (sequential)
+
+Show the phase banner with running total (see swarm-output-style skill).
+
 If breakers found vulnerabilities:
 1. Aggregate all findings by severity
 2. Spawn an implementer teammate (opus) with `team_name`, `name` (`hardener`), and `run_in_background: true` to fix Critical and Important findings
-3. As the hardener completes, send it a `shutdown_request`
+3. As the hardener completes: show a one-line completion summary (see swarm-output-style skill), then send it a `shutdown_request`
 4. Spawn a verifier teammate with `team_name`, `name` (e.g., `verifier-security`), and `run_in_background: true` to re-run the specific breaker's tests against the hardened code
-5. As the verifier completes, send it a `shutdown_request`
+5. As the verifier completes: show a one-line completion summary (see swarm-output-style skill), then send it a `shutdown_request`
 
 ### Phase 5: Report
-```markdown
-## Red Team Report
-
-### Built
-[What was implemented]
-
-### Attacked
-- Edge cases probed: [count]
-- Security attacks attempted: [count]
-- Mutations tested: [count]
-
-### Vulnerabilities Found
-| Severity | Finding | Status |
-|----------|---------|--------|
-| Critical | [finding] | Fixed / Open |
-
-### Hardening Applied
-[What was fixed]
 
-### Surviving Weaknesses
-[What couldn't be fixed or needs human decision]
-```
+Show the full post-completion summary (see swarm-output-style skill). Include:
+- Status (PASS / NEEDS ATTENTION / FAILED)
+- Metrics (phases, agents, duration, tokens, cost)
+- What was built and what was attacked
+- Vulnerability table (severity, finding, status)
+- Hardening applied
+- Surviving weaknesses requiring human decision
+- Next steps
 
 ### Cleanup
 1. Send `shutdown_request` to any remaining active teammates
@@ -80,3 +93,5 @@ If breakers found vulnerabilities:
 - Breakers should be genuinely adversarial — their goal is to BREAK the code
 - Only fix Critical and Important findings — Suggestions go in the report
 - If mutation tests reveal untested code paths, note them but don't block
+- Follow the swarm-output-style skill for ALL output formatting
+- Show the plan first, spend tokens second

package/commands/research.md

@@ -5,11 +5,25 @@ argument-hint: "<research question>"
 
 You are conducting parallel research to answer a complex question using multiple researcher agents simultaneously.
 
+Follow the `swarm-output-style` skill for ALL output formatting.
+
 ## Question
 $ARGUMENTS
 
 ## Workflow
 
+### Step 0: Show Pre-flight Plan
+
+Before creating any team or spawning any agent, show the plan:
+
+Show the pre-flight plan (see swarm-output-style skill). Include:
+- The research question decomposed into 2-5 angles
+- One researcher per angle with model and focus (haiku for broad search, sonnet for deep analysis)
+- Estimated cost (~$0.04/researcher for haiku, ~$0.10/researcher for sonnet)
+- Estimated time (~2-3 min per haiku agent, ~3-5 min per sonnet agent)
+
+Wait for user approval before proceeding.
+
 ### Setup: Create Team
 1. Create a team with `TeamCreate` (name: `research-<timestamp>`, e.g., `research-1234`)
 2. Create tasks with `TaskCreate` for each research angle identified in the decomposition
@@ -21,12 +35,15 @@ Break the research question into 2-5 independent angles of investigation. Each a
 - Together provide a complete picture
 
 ### Step 2: Dispatch Researchers
+
+Show the phase banner with running total (see swarm-output-style skill).
+
 Spawn one researcher teammate per angle, ALL in parallel, each with `team_name`, `name` (e.g., `researcher-angle-1`), and `run_in_background: true`. Use:
 - `subagent_type`: Use the "Explore" type for pure search, or spawn a "researcher" agent for deeper analysis
 - `model`: "haiku" for broad searches, "sonnet" for deep analysis
 - Include the specific angle and any known context in each prompt
 
-As each teammate completes, send it a `shutdown_request` via `SendMessage` to close its split pane.
+As each completes: show a one-line completion summary (see swarm-output-style skill), then send `shutdown_request` via `SendMessage`.
 
 ### Step 3: Synthesize
 Once all researchers return:
@@ -48,6 +65,8 @@ Once all researchers return:
 [Suggested next steps based on findings]
 ```
 
+Show the full post-completion summary (see swarm-output-style skill).
+
 ### Cleanup
 1. Send `shutdown_request` via `SendMessage` to any remaining active teammates
 2. Call `TeamDelete` to clean up the team
@@ -57,3 +76,5 @@ Once all researchers return:
 - Include full context in every researcher dispatch — they cannot ask follow-up questions
 - Use haiku for broad file search, sonnet for deep analysis
 - All findings must include file:line references
+- Follow the swarm-output-style skill for ALL output formatting
+- Show the plan first, spend tokens second