swarm-engine 1.1.0 → 1.3.0

package/commands/review-cycle.md

@@ -5,33 +5,55 @@ argument-hint: "<implementation task>"
 
 You are running an implement-then-review cycle with parallel reviewers for quality assurance.
 
+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, Implement, Devil's Advocate, Review-Fix Loop)
+- Agents per phase with model and focus
+- Estimated cost (~$0.12 research, ~$0.19 implement, ~$0.10 devil's advocate, ~$0.29/review iteration)
+- Estimated time (~15-30 min depending on review iterations)
+
+Wait for user approval before proceeding.
+
 ### Setup: Create Team
 1. Create a team with `TeamCreate` (name: `review-cycle-<timestamp>`, e.g., `review-cycle-1234`)
 2. Create tasks with `TaskCreate` for each work unit identified in the plan
 
 ### Phase 1: Research (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` (e.g., `researcher-arch`, `researcher-tests`, `researcher-deps`), and `run_in_background: true`:
 - One for architecture and patterns
 - One for related tests and test patterns
 - One for dependencies and integration points
 
-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`.
 
 Present the research findings and implementation plan to the user. Proceed after approval.
 
 ### Phase 2: Implement (sequential)
+
+Show the phase banner with running total (see swarm-output-style skill).
+
 Based on research findings, spawn an implementer teammate (opus) with `team_name`, `name` (e.g., `implementer`), and `run_in_background: true`.
 Include all research findings as context.
 
-As the teammate completes, send it a `shutdown_request` via `SendMessage` to close its split pane.
+As the teammate completes: show a one-line completion summary (see swarm-output-style skill), then send `shutdown_request` via `SendMessage`.
 
 ### Phase 2b: Devil's Advocate (sequential)
 
+Show the phase banner with running total (see swarm-output-style skill).
+
 After implementation, spawn a devils-advocate teammate (opus) with `team_name`, `name` (e.g., `devils-advocate`), and `run_in_background: true`.
 
 Provide it with:
@@ -39,7 +61,7 @@ Provide it with:
 - The original task description
 - Research findings from Phase 1
 
-As the teammate completes, send it a `shutdown_request` via `SendMessage` to close its split pane.
+As the teammate completes: show a one-line completion summary (see swarm-output-style skill), then send `shutdown_request` via `SendMessage`.
 
 If the devil's advocate found **Critical** challenges:
 1. Spawn a new implementer teammate (opus, name: `implementer-hardened`) with `team_name` and `run_in_background: true`
@@ -54,12 +76,15 @@ If only Important challenges or Questions were raised, include them as context f
 For each iteration (1 to 3):
 
 #### Review (parallel)
+
+Show the phase banner with running total (see swarm-output-style skill).
+
 Spawn 3 reviewer teammates simultaneously, each with `team_name`, `name` (e.g., `reviewer-correctness`, `reviewer-security`, `reviewer-convention`), and `run_in_background: true`, each with a different focus:
 1. **Correctness reviewer** (opus) — Logic errors, edge cases, error handling, race conditions
 2. **Security reviewer** (opus) — Injection, auth bypass, data exposure, OWASP top 10
 3. **Convention reviewer** (sonnet) — Project patterns, naming, structure, CLAUDE.md compliance
 
-As each reviewer teammate completes, send it a `shutdown_request` via `SendMessage` to close its split pane.
+As each completes: show a one-line verdict (PASS/FAIL + finding count) (see swarm-output-style skill), then send `shutdown_request` via `SendMessage`.
 
 #### Gate Check
 Parse review results:
@@ -93,23 +118,14 @@ This block must be constructed from the actual reviewer findings and included ve
 As the fixer teammate completes, send it a `shutdown_request` via `SendMessage` to close its split pane.
 
 ### Phase 5: Report
-```markdown
-## Implementation Summary
-[What was built/changed]
-
-## Quality Gate: [PASS after N iterations | FAIL after 3 iterations]
-
-### Per-Iteration Results
-- **Iteration 1**: N critical, M important → [fixed / passed]
-- **Iteration 2**: N critical, M important → [fixed / passed]
-- **Iteration 3**: N critical, M important → [fixed / passed]
-
-## Remaining Concerns
-[Any Important/Suggestion findings from final iteration]
 
-## Suggestions (non-blocking)
-[Reviewer suggestions that did not trigger fixes]
-```
+Show the full post-completion summary (see swarm-output-style skill). Include:
+- Status (PASS / NEEDS ATTENTION / FAILED)
+- Metrics (phases, agents, duration, tokens, cost)
+- What changed (files with git diff --stat if available)
+- Review gate result with per-reviewer table and per-iteration breakdown
+- Non-blocking suggestions
+- Next steps
 
 ### Cleanup
 1. Send `shutdown_request` via `SendMessage` to any remaining active teammates
@@ -121,3 +137,5 @@ As the fixer teammate completes, send it a `shutdown_request` via `SendMessage`
 - Maximum 3 review-fix iterations before escalating to user
 - Present findings to user before each fix phase
 - Each fix phase must only address findings from the current iteration's review
+- Follow the swarm-output-style skill for ALL output formatting
+- Show the plan first, spend tokens second

package/commands/spike.md

@@ -0,0 +1,108 @@
+---
+description: "Two independent approaches to the same problem, evaluated side-by-side"
+argument-hint: "<problem to solve with competing approaches>"
+---
+
+You are running a competitive spike: two independent approaches to the same problem, evaluated side-by-side.
+
+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, Implement x2 in parallel worktrees, Evaluate x2, Select)
+- Agents per phase with model and focus
+- Estimated cost (~$0.08 research, ~$0.38 implement, ~$0.20 evaluate)
+- Estimated time (~20-35 min total)
+
+Wait for user approval before proceeding.
+
+### Setup: Create Team
+1. Create a team with `TeamCreate` (name: `spike-<timestamp>`, e.g., `spike-1234`)
+2. Create tasks with `TaskCreate` for each work unit (research, implementation, review)
+
+### Phase 1: Research — parallel
+
+Show the phase banner with running total (see swarm-output-style skill).
+
+Spawn 2 researcher teammates (sonnet) simultaneously, each with `team_name`, `name` (e.g., `researcher-a`, `researcher-b`), and `run_in_background: true` to explore the problem space. Each should:
+- Understand the constraints and requirements
+- Identify a viable approach
+- Describe the approach with tradeoffs
+
+As each completes: show a one-line completion summary (see swarm-output-style skill), then send `shutdown_request` via `SendMessage`.
+
+Present the two approaches to the user before proceeding.
+
+### Phase 2: Implement — parallel (worktree isolation, depends on Phase 1)
+
+Show the phase banner with running total (see swarm-output-style skill).
+
+Spawn 2 implementer teammates (opus) simultaneously, each in an **isolated worktree**, with `team_name`, `name` (e.g., `implementer-a`, `implementer-b`), and `run_in_background: true`:
+- **Implementer A**: Approach 1 — full implementation in isolated worktree
+- **Implementer B**: Approach 2 — full implementation in isolated worktree
+
+Both receive the same spec and requirements but different suggested approaches.
+
+As each completes: show a one-line completion summary (see swarm-output-style skill), then send `shutdown_request` via `SendMessage`.
+
+### Phase 3: Evaluate — parallel (depends on Phase 2)
+
+Show the phase banner with running total (see swarm-output-style skill).
+
+Spawn 2 reviewer teammates (opus) simultaneously, each with `team_name`, `name` (e.g., `reviewer-a`, `reviewer-b`), and `run_in_background: true`:
+- **Reviewer A**: Reviews Approach 1 — correctness, complexity, maintainability, testability
+- **Reviewer B**: Reviews Approach 2 — correctness, complexity, maintainability, testability
+
+As each completes: show a one-line verdict per approach (see swarm-output-style skill), then send `shutdown_request` via `SendMessage`.
+
+### Phase 4: Select — sequential (depends on Phase 3)
+Present a comparison table to the user:
+
+```
+## Spike Comparison
+
+| Criteria        | Approach 1           | Approach 2           |
+|-----------------|----------------------|----------------------|
+| Summary         | [brief description]  | [brief description]  |
+| Correctness     | [assessment]         | [assessment]         |
+| Complexity      | [lines/abstractions] | [lines/abstractions] |
+| Maintainability | [assessment]         | [assessment]         |
+| Performance     | [assessment]         | [assessment]         |
+| Testability     | [assessment]         | [assessment]         |
+| Reviewer Verdict| [recommendation]     | [recommendation]     |
+
+### Recommendation
+[Which approach and why]
+```
+
+The user picks the winner. Apply the winning approach: merge the winning worktree branch with `git merge <branch> --no-ff`, or if significantly diverged, cherry-pick the relevant commits.
+
+Show the full post-completion summary (see swarm-output-style skill). Include:
+- Status (PASS / NEEDS ATTENTION)
+- Metrics (phases, agents, duration, tokens, cost)
+- Spike comparison table summary
+- Which approach was selected and why
+- What was applied (merge/cherry-pick)
+- 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)
+- Both approaches must solve the FULL problem — no partial implementations
+- Use worktree isolation so approaches don't interfere with each other
+- Include clear tradeoff analysis in the comparison
+- The user always makes the final decision — never auto-select
+- If both approaches are flawed, recommend a third path informed by what was learned
+- Follow the swarm-output-style skill for ALL output formatting
+- Show the plan first, spend tokens second

package/commands/swarm.md

@@ -1,83 +1,104 @@
 ---
-description: "Swarm Engine — orchestrate multi-agent development with composable patterns"
+description: "Swarm Engine -- orchestrate multi-agent development with composable patterns"
 argument-hint: "<task description> | setup | status | backends"
 ---
 
-You are the Swarm Engine — a multi-agent orchestration system.
+You are the Swarm Engine -- a multi-agent orchestration system.
 
 If the user says "setup", run: `swarm setup` in the terminal to launch the interactive configuration wizard.
 If the user says "status", run: `swarm status` to show registered agents and backends.
 If the user says "backends", run: `swarm backends` to show available execution backends.
 
-Otherwise, orchestrate the task using formal patterns.
+Otherwise, orchestrate the task using formal patterns. Follow the `swarm-output-style` skill for ALL output formatting.
 
 ## Task
 $ARGUMENTS
 
 ## Workflow
 
-### Setup: Analyze and Select Pattern
+### Step 0: Check Memory
 
-1. **Check memory** for relevant context:
-   ```bash
-   cd ~/dev/swarm-engine && npx tsx src/cli/index.ts memory search "<relevant keywords>"
-   ```
+Search for relevant context before doing anything:
+```bash
+cd ~/dev/swarm-engine && npx tsx src/cli/index.ts memory search "<relevant keywords>"
+```
+
+### Step 1: Select Pattern and Show Pre-flight Plan
+
+Assess the task and select the best pattern:
 
-2. **Assess the task** and select the best pattern:
+| Task Type | Pattern | Command |
+|-----------|---------|---------|
+| General feature | `hybrid` | Continue below |
+| Understanding code | `research` | Delegate to `/research` |
+| Quality-critical code | `review-cycle` | Delegate to `/review-cycle` |
+| New feature with tests | `tdd` | Delegate to `/tdd` |
+| Uncertain approach | `spike` | Delegate to `/spike` |
+| Security-sensitive code | `red-team` | Delegate to `/red-team` |
+| Complex/novel problem | `discover` | Delegate to `/discover` |
+| Error/incident | `postmortem` | Delegate to `/postmortem` |
 
-   | Task Type | Pattern | Why |
-   |-----------|---------|-----|
-   | General feature | `hybrid` | Research → Implement → Review (default) |
-   | Understanding code | `research` | Fan-out parallel exploration |
-   | Quality-critical code | `review-cycle` | Iterative review-fix loop |
-   | New feature with tests | `tdd` | Test-first guarantees coverage |
-   | Uncertain approach | `spike` | Two approaches compete, reviewer picks |
-   | Security-sensitive code | `red-team` | Build → Break → Harden |
-   | Complex/novel problem | `discover` | Hypothesize → Test → Implement winner |
+If a dedicated command exists, **delegate to it**. Only continue here for `hybrid`.
 
-   If a dedicated command exists for the chosen pattern (e.g., `/review-cycle`, `/tdd`, `/spike`, `/red-team`, `/discover`, `/research`), **delegate to that command instead** of continuing here. Only continue with this command for `hybrid` or custom multi-phase orchestrations.
+**Show the pre-flight plan BEFORE creating any team or spawning any agent.** Include estimated cost, time, and an agent table for each phase (see swarm-output-style skill). Wait for user approval.
 
-3. **Create team**: `TeamCreate` (name: `orchestrate-<timestamp>`)
-4. **Create tasks**: `TaskCreate` for each planned phase
+### Step 2: Create Team
+
+After the user approves the plan:
+1. `TeamCreate` (name: `orchestrate-<timestamp>`)
+2. `TaskCreate` for each planned phase
 
 ### Phase 1: Research (parallel)
 
+Show the phase banner with running total.
+
 Spawn 2-3 researcher teammates (sonnet) simultaneously, each with `team_name`, `name`, and `run_in_background: true`:
-- **researcher-code** — Explore the relevant codebase: architecture, entry points, existing patterns
-- **researcher-context** — Check memory and vault for past decisions, conventions, gotchas:
+- **researcher-code** -- Explore the relevant codebase: architecture, entry points, existing patterns
+- **researcher-context** -- Check memory and vault for past decisions, conventions, gotchas:
   ```bash
   ~/.claude/scripts/swarm-vault.sh repo "<repo-name>" conventions
   ~/.claude/scripts/swarm-vault.sh repo "<repo-name>" gotchas
   ```
-- **researcher-deps** (optional) — Map dependencies, integration points, downstream consumers
+- **researcher-deps** (optional) -- Map dependencies, integration points, downstream consumers
 
-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, then send `shutdown_request`.
 
-Present the research findings and proposed implementation plan to the user. Proceed after approval.
+After all researchers complete: show phase summary with key findings.
+
+**Approval gate**: Present findings and proposed implementation plan. Proceed after user approval. (This is where cost jumps to expensive-tier agents.)
 
 ### Phase 2: Implement (parallel if independent, sequential if dependent)
 
-Based on research findings, spawn implementer teammates (opus) with `team_name`, `name`, and `run_in_background: true`.
+Show the phase banner with running total.
+
+Spawn implementer teammates (opus) with `team_name`, `name`, and `run_in_background: true`.
 
 For each implementer, include:
 - All relevant research findings as context
 - Specific file assignments (no two implementers touch the same files)
 - Reference patterns from the codebase
 
-As each teammate completes, send it a `shutdown_request` via `SendMessage` to close its split pane.
+As each completes: show one-line summary of files changed, then send `shutdown_request`.
 
 ### Phase 3: Review (parallel)
 
+Show the phase banner with running total.
+
 Spawn 2-3 reviewer teammates simultaneously, each with `team_name`, `name`, and `run_in_background: true`:
-1. **reviewer-correctness** (opus) — Logic errors, edge cases, error handling, race conditions
-2. **reviewer-security** (opus) — Injection, auth bypass, data exposure, OWASP top 10
-3. **reviewer-convention** (sonnet) — Project patterns, naming, structure compliance
+1. **reviewer-correctness** (opus) -- Logic errors, edge cases, error handling, race conditions
+2. **reviewer-security** (opus) -- Injection, auth bypass, data exposure, OWASP top 10
+3. **reviewer-convention** (sonnet) -- Project patterns, naming, structure compliance
 
-As each reviewer completes, send it a `shutdown_request` via `SendMessage` to close its split pane.
+As each completes: show one-line verdict (PASS/FAIL + finding count), then send `shutdown_request`.
 
 #### Gate Check
-- **0 Critical AND 0 Important findings** → proceed to report
-- **Any Critical or Important finding** → spawn a fixer implementer (opus) to address them, then re-review (max 2 fix iterations)
+- **0 Critical AND 0 Important findings** -- proceed to report
+- **Any Critical or Important finding** -- show error recovery options:
+  1. Spawn a fixer implementer (opus) to address them, then re-review
+  2. Accept and note as risks
+  3. Abort
+
+Maximum 2 fix iterations before escalating remaining issues to the user.
 
 ### Phase 4: Record Outcomes
 
@@ -88,39 +109,26 @@ echo "<outcome summary>" | cd ~/dev/swarm-engine && npx tsx src/cli/index.ts mem
 
 ### Phase 5: Report
 
-```markdown
-## Orchestration Summary
-- **Pattern**: [hybrid / custom]
-- **Phases completed**: N of N
-
-## Changes Made
-[List of files changed with brief descriptions]
-
-## Research Findings
-[Key insights that informed the implementation]
-
-## Review Results
-- **Gate**: PASS / FAIL after N iterations
-- **Critical findings**: N (all resolved)
-- **Important findings**: N (resolved / remaining)
-
-## Suggestions (non-blocking)
-[Reviewer suggestions not addressed]
-
-## Knowledge Stored
-[What was saved to memory/vault for future use]
-```
+Show the full post-completion summary (see swarm-output-style skill). Include:
+- Status (PASS / NEEDS ATTENTION / FAILED)
+- Metrics (phases, agents, duration, tokens, cost)
+- What changed (files with git diff --stat if available)
+- Review gate result with per-reviewer table
+- Non-blocking suggestions
+- Knowledge stored
+- Next steps (git diff, tests, /verify)
 
 ### Cleanup
-1. Send `shutdown_request` via `SendMessage` to any remaining active teammates
+1. Send `shutdown_request` 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)
-- Present the plan before executing — wait for user approval
-- If a dedicated command exists for the pattern, delegate to it
+- **Show the plan first, spend tokens second** -- never spawn agents before user approval
+- All agents must use team protocol (TeamCreate, Agent with team_name/name/run_in_background, SendMessage shutdown, TeamDelete)
+- Delegate to dedicated commands when a pattern match exists
 - Include full context in every agent dispatch (agents don't share memory within a session)
 - Use the cheapest model that can handle each task (sonnet for research, opus for implementation/review)
 - Check engine memory before starting for relevant context
 - Record outcomes to engine memory after completion
+- Follow the swarm-output-style skill for ALL output formatting
 - Maximum 2 fix iterations before escalating remaining issues to the user

package/commands/tdd.md

@@ -5,23 +5,43 @@ argument-hint: "<feature description>"
 
 You are running a strict TDD cycle: Red → Green → Review.
 
+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, Write Failing Test, Implement, Verify, Review)
+- Agents per phase with model and focus
+- Estimated cost (~$0.08 research, ~$0.13 test, ~$0.19 implement, ~$0.13 verify, ~$0.29 review)
+- Estimated time (~10-20 min total)
+
+Wait for user approval before proceeding.
+
 ### Setup: Create Team
 1. Create a team with `TeamCreate` (name: `tdd-<timestamp>`, e.g., `tdd-1234`)
 2. Create tasks with `TaskCreate` for each phase of the TDD cycle
 
 ### Phase 1: Research — parallel
+
+Show the phase banner with running total (see swarm-output-style skill).
+
 Spawn 2 researcher teammates simultaneously, each with `team_name`, `name`, and `run_in_background: true`:
 - **Researcher A** (`researcher-code`, sonnet): Existing code patterns, interfaces, and the module where the feature belongs
 - **Researcher B** (`researcher-tests`, sonnet): Test patterns, fixtures, test infrastructure, and how similar features are tested
 
-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`.
 
 ### Phase 2: Write Failing Test — sequential (depends on Phase 1)
+
+Show the phase banner with running total (see swarm-output-style skill).
+
 Spawn a tester teammate (opus) with `team_name`, `name` (e.g., `tester-red`), and `run_in_background: true`, with research context. The tester must:
 1. Write test(s) that describe the desired behavior
 2. Run the tests
@@ -29,54 +49,52 @@ Spawn a tester teammate (opus) with `team_name`, `name` (e.g., `tester-red`), an
 
 If the tests pass, the feature already exists — report this and stop.
 
-As the teammate completes, send it a `shutdown_request` via `SendMessage` to close its split pane.
+As the teammate completes: show a one-line completion summary (see swarm-output-style skill), then send `shutdown_request` via `SendMessage`.
 
 Present the failing tests to the user. Proceed to implementation after approval.
 
 ### 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` (e.g., `implementer`), and `run_in_background: true`, with:
 - The failing test(s) as the specification
 - All research context from Phase 1
 - Goal: make the tests pass with **minimal code** — no extras
 
-As the teammate completes, send it a `shutdown_request` via `SendMessage` to close its split pane.
+As the teammate completes: show a one-line completion summary (see swarm-output-style skill), then send `shutdown_request` via `SendMessage`.
 
 ### Phase 4: Verify — sequential (depends on Phase 3)
+
+Show the phase banner with running total (see swarm-output-style skill).
+
 Spawn a tester teammate (sonnet) with `team_name`, `name` (e.g., `tester-green`), and `run_in_background: true` to run the full test suite:
 - All tests must pass (green phase)
 - If **new** tests fail → send back to implementer with failure details
 - If **unrelated** tests fail → report regression and stop
 
-As the teammate completes, send it a `shutdown_request` via `SendMessage` to close its split pane.
+As the teammate completes: show a one-line completion summary (see swarm-output-style skill), then send `shutdown_request` via `SendMessage`.
 
 ### Phase 5: Review — parallel (depends on Phase 4)
+
+Show the phase banner with running total (see swarm-output-style skill).
+
 Spawn 2 reviewer teammates simultaneously, each with `team_name`, `name`, and `run_in_background: true`, on the implementation (not the tests):
 1. **Correctness reviewer** (`reviewer-correctness`, opus) — Logic, edge cases, error handling
 2. **Convention reviewer** (`reviewer-convention`, sonnet) — Project patterns, naming, structure
 
-As each reviewer teammate completes, send it a `shutdown_request` via `SendMessage` to close its split pane.
+As each completes: show a one-line verdict (PASS/FAIL + finding count) (see swarm-output-style skill), then send `shutdown_request` via `SendMessage`.
 
 ### Phase 6: Report
 
-```
-## TDD Report
-
-### Feature
-[What was built]
-
-### Tests Written
-- [test file:line — what each test covers]
-
-### Implementation
-- [file:line — what was added/changed]
-
-### Review Findings
-- Correctness: [PASS/FAIL — findings]
-- Conventions: [PASS/FAIL — findings]
-
-### Test Results
-[Full suite pass/fail summary]
-```
+Show the full post-completion summary (see swarm-output-style skill). Include:
+- Status (PASS / NEEDS ATTENTION / FAILED)
+- Metrics (phases, agents, duration, tokens, cost)
+- What changed (test file:line and implementation file:line)
+- Review gate result with per-reviewer table
+- Test results (full suite pass/fail count)
+- Non-blocking suggestions
+- Next steps
 
 ### Cleanup
 1. Send `shutdown_request` via `SendMessage` to any remaining active teammates
@@ -89,3 +107,5 @@ As each reviewer teammate completes, send it a `shutdown_request` via `SendMessa
 - Implement minimally — no gold-plating, no anticipatory code
 - If tests pass before implementation, the feature already exists — stop and report
 - Use opus for writing tests and implementation, sonnet for verification and convention review
+- Follow the swarm-output-style skill for ALL output formatting
+- Show the plan first, spend tokens second

package/dist/cli/commands/acp.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"acp.d.ts","sourceRoot":"","sources":["../../../src/cli/commands/acp.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,OAAO,EAAE,MAAM,WAAW,CAAC;AAUpC,eAAO,MAAM,UAAU,SAoBnB,CAAC"}
+{"version":3,"file":"acp.d.ts","sourceRoot":"","sources":["../../../src/cli/commands/acp.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,OAAO,EAAE,MAAM,WAAW,CAAC;AAUpC,eAAO,MAAM,UAAU,SAgCnB,CAAC"}

package/dist/cli/commands/acp.js

@@ -19,11 +19,21 @@ export const acpCommand = new Command('acp')
     if (options.engine) {
         engine = new SwarmEngine({ registry, bus, logger, mock: false, nonInteractive: true });
     }
-    const server = new ACPServer({ port: parseInt(options.port, 10), host: options.host, registry, bus, logger, engine });
+    const server = new ACPServer({
+        port: parseInt(options.port, 10),
+        host: options.host,
+        registry,
+        bus,
+        logger,
+        engine,
+    });
     await server.start();
     console.log(chalk.green(`ACP server on http://${options.host}:${options.port}`));
     console.log(`  Engine: ${engine ? chalk.green('connected') : chalk.dim('disabled (--no-engine)')}`);
     console.log(`  GET /health | GET /agents | POST /sessions | POST /sessions/:id/messages`);
-    process.on('SIGINT', async () => { await server.stop(); process.exit(0); });
+    process.on('SIGINT', async () => {
+        await server.stop();
+        process.exit(0);
+    });
 });
 //# sourceMappingURL=acp.js.map

package/dist/cli/commands/acp.js.map

@@ -1 +1 @@
-{"version":3,"file":"acp.js","sourceRoot":"","sources":["../../../src/cli/commands/acp.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,OAAO,EAAE,MAAM,WAAW,CAAC;AACpC,OAAO,KAAK,MAAM,OAAO,CAAC;AAC1B,OAAO,EAAE,IAAI,EAAE,MAAM,MAAM,CAAC;AAC5B,OAAO,EAAE,OAAO,EAAE,MAAM,IAAI,CAAC;AAC7B,OAAO,EAAE,SAAS,EAAE,MAAM,sBAAsB,CAAC;AACjD,OAAO,EAAE,aAAa,EAAE,MAAM,wBAAwB,CAAC;AACvD,OAAO,EAAE,QAAQ,EAAE,MAAM,yBAAyB,CAAC;AACnD,OAAO,EAAE,MAAM,EAAE,MAAM,uBAAuB,CAAC;AAC/C,OAAO,EAAE,WAAW,EAAE,MAAM,yBAAyB,CAAC;AAEtD,MAAM,CAAC,MAAM,UAAU,GAAG,IAAI,OAAO,CAAC,KAAK,CAAC;KACzC,WAAW,CAAC,kDAAkD,CAAC;KAC/D,MAAM,CAAC,mBAAmB,EAAE,MAAM,EAAE,MAAM,CAAC;KAC3C,MAAM,CAAC,mBAAmB,EAAE,MAAM,EAAE,WAAW,CAAC;KAChD,MAAM,CAAC,aAAa,EAAE,oCAAoC,CAAC;KAC3D,MAAM,CAAC,KAAK,EAAE,OAAwD,EAAE,EAAE;IACzE,MAAM,GAAG,GAAG,IAAI,QAAQ,EAAE,EAAE,MAAM,GAAG,IAAI,MAAM,CAAC,KAAK,EAAE,MAAM,CAAC,EAAE,QAAQ,GAAG,IAAI,aAAa,CAAC,GAAG,CAAC,CAAC;IAClG,QAAQ,CAAC,aAAa,CAAC,IAAI,CAAC,OAAO,EAAE,EAAE,KAAK,EAAE,cAAc,EAAE,QAAQ,CAAC,CAAC,CAAC;IAEzE,IAAI,MAA+B,CAAC;IACpC,IAAI,OAAO,CAAC,MAAM,EAAE,CAAC;QACnB,MAAM,GAAG,IAAI,WAAW,CAAC,EAAE,QAAQ,EAAE,GAAG,EAAE,MAAM,EAAE,IAAI,EAAE,KAAK,EAAE,cAAc,EAAE,IAAI,EAAE,CAAC,CAAC;IACzF,CAAC;IAED,MAAM,MAAM,GAAG,IAAI,SAAS,CAAC,EAAE,IAAI,EAAE,QAAQ,CAAC,OAAO,CAAC,IAAI,EAAE,EAAE,CAAC,EAAE,IAAI,EAAE,OAAO,CAAC,IAAI,EAAE,QAAQ,EAAE,GAAG,EAAE,MAAM,EAAE,MAAM,EAAE,CAAC,CAAC;IACtH,MAAM,MAAM,CAAC,KAAK,EAAE,CAAC;IACrB,OAAO,CAAC,GAAG,CAAC,KAAK,CAAC,KAAK,CAAC,wBAAwB,OAAO,CAAC,IAAI,IAAI,OAAO,CAAC,IAAI,EAAE,CAAC,CAAC,CAAC;IACjF,OAAO,CAAC,GAAG,CAAC,aAAa,MAAM,CAAC,CAAC,CAAC,KAAK,CAAC,KAAK,CAAC,WAAW,CAAC,CAAC,CAAC,CAAC,KAAK,CAAC,GAAG,CAAC,wBAAwB,CAAC,EAAE,CAAC,CAAC;IACpG,OAAO,CAAC,GAAG,CAAC,4EAA4E,CAAC,CAAC;IAC1F,OAAO,CAAC,EAAE,CAAC,QAAQ,EAAE,KAAK,IAAI,EAAE,GAAG,MAAM,MAAM,CAAC,IAAI,EAAE,CAAC,CAAC,OAAO,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC;AAC9E,CAAC,CAAC,CAAC"}
+{"version":3,"file":"acp.js","sourceRoot":"","sources":["../../../src/cli/commands/acp.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,OAAO,EAAE,MAAM,WAAW,CAAC;AACpC,OAAO,KAAK,MAAM,OAAO,CAAC;AAC1B,OAAO,EAAE,IAAI,EAAE,MAAM,MAAM,CAAC;AAC5B,OAAO,EAAE,OAAO,EAAE,MAAM,IAAI,CAAC;AAC7B,OAAO,EAAE,SAAS,EAAE,MAAM,sBAAsB,CAAC;AACjD,OAAO,EAAE,aAAa,EAAE,MAAM,wBAAwB,CAAC;AACvD,OAAO,EAAE,QAAQ,EAAE,MAAM,yBAAyB,CAAC;AACnD,OAAO,EAAE,MAAM,EAAE,MAAM,uBAAuB,CAAC;AAC/C,OAAO,EAAE,WAAW,EAAE,MAAM,yBAAyB,CAAC;AAEtD,MAAM,CAAC,MAAM,UAAU,GAAG,IAAI,OAAO,CAAC,KAAK,CAAC;KACzC,WAAW,CAAC,kDAAkD,CAAC;KAC/D,MAAM,CAAC,mBAAmB,EAAE,MAAM,EAAE,MAAM,CAAC;KAC3C,MAAM,CAAC,mBAAmB,EAAE,MAAM,EAAE,WAAW,CAAC;KAChD,MAAM,CAAC,aAAa,EAAE,oCAAoC,CAAC;KAC3D,MAAM,CAAC,KAAK,EAAE,OAAwD,EAAE,EAAE;IACzE,MAAM,GAAG,GAAG,IAAI,QAAQ,EAAE,EACxB,MAAM,GAAG,IAAI,MAAM,CAAC,KAAK,EAAE,MAAM,CAAC,EAClC,QAAQ,GAAG,IAAI,aAAa,CAAC,GAAG,CAAC,CAAC;IACpC,QAAQ,CAAC,aAAa,CAAC,IAAI,CAAC,OAAO,EAAE,EAAE,KAAK,EAAE,cAAc,EAAE,QAAQ,CAAC,CAAC,CAAC;IAEzE,IAAI,MAA+B,CAAC;IACpC,IAAI,OAAO,CAAC,MAAM,EAAE,CAAC;QACnB,MAAM,GAAG,IAAI,WAAW,CAAC,EAAE,QAAQ,EAAE,GAAG,EAAE,MAAM,EAAE,IAAI,EAAE,KAAK,EAAE,cAAc,EAAE,IAAI,EAAE,CAAC,CAAC;IACzF,CAAC;IAED,MAAM,MAAM,GAAG,IAAI,SAAS,CAAC;QAC3B,IAAI,EAAE,QAAQ,CAAC,OAAO,CAAC,IAAI,EAAE,EAAE,CAAC;QAChC,IAAI,EAAE,OAAO,CAAC,IAAI;QAClB,QAAQ;QACR,GAAG;QACH,MAAM;QACN,MAAM;KACP,CAAC,CAAC;IACH,MAAM,MAAM,CAAC,KAAK,EAAE,CAAC;IACrB,OAAO,CAAC,GAAG,CAAC,KAAK,CAAC,KAAK,CAAC,wBAAwB,OAAO,CAAC,IAAI,IAAI,OAAO,CAAC,IAAI,EAAE,CAAC,CAAC,CAAC;IACjF,OAAO,CAAC,GAAG,CAAC,aAAa,MAAM,CAAC,CAAC,CAAC,KAAK,CAAC,KAAK,CAAC,WAAW,CAAC,CAAC,CAAC,CAAC,KAAK,CAAC,GAAG,CAAC,wBAAwB,CAAC,EAAE,CAAC,CAAC;IACpG,OAAO,CAAC,GAAG,CAAC,4EAA4E,CAAC,CAAC;IAC1F,OAAO,CAAC,EAAE,CAAC,QAAQ,EAAE,KAAK,IAAI,EAAE;QAC9B,MAAM,MAAM,CAAC,IAAI,EAAE,CAAC;QACpB,OAAO,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC;IAClB,CAAC,CAAC,CAAC;AACL,CAAC,CAAC,CAAC"}

package/dist/cli/commands/agents.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"agents.d.ts","sourceRoot":"","sources":["../../../src/cli/commands/agents.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,OAAO,EAAE,MAAM,WAAW,CAAC;AAOpC,eAAO,MAAM,aAAa,SACgB,CAAC"}
+{"version":3,"file":"agents.d.ts","sourceRoot":"","sources":["../../../src/cli/commands/agents.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,OAAO,EAAE,MAAM,WAAW,CAAC;AAOpC,eAAO,MAAM,aAAa,SAAgE,CAAC"}