@complexthings/superpowers-agent 9.2.1 → 10.0.1

package/skills/architecture/preserving-productive-tensions/SKILL.md

@@ -1,146 +0,0 @@
----
-name: preserving-productive-tensions
-description: Recognizes when tensions between valid approaches are features rather than bugs, and preserves multiple valid approaches instead of forcing premature consensus. Invoke when oscillating between two approaches across messages, when stakeholders have conflicting but equally valid concerns, when someone says "just pick one" without a clear reason, when implementation approaches optimize for different legitimate priorities, or when forcing a choice would destroy flexibility that different contexts legitimately need. Helps agents avoid arbitrarily resolving disagreements just to "move forward" — premature consensus destroys context-dependent flexibility.
-metadata:
-  version: 1.2.0
----
-
-# Preserving Productive Tensions
-
-## Overview
-
-Some tensions aren't problems to solve — they're valuable information to preserve. When multiple approaches are genuinely valid in different contexts, forcing a choice destroys flexibility that different deployments or users need.
-
-**Core principle:** Preserve tensions that reveal context-dependence. Force resolution only when necessary.
-
-## Recognizing Productive Tensions
-
-**A tension is productive when:**
-- Both approaches optimize for different valid priorities (cost vs latency, simplicity vs features)
-- The "better" choice depends on deployment context, not technical superiority
-- Different users/deployments would legitimately choose differently
-- The trade-off is real and won't disappear with clever engineering
-- Stakeholders have conflicting but equally valid concerns
-
-**A tension needs resolution when:**
-- Implementation cost of preserving both is prohibitive
-- The approaches fundamentally conflict (can't coexist)
-- There's clear technical superiority for this specific use case
-- It's a one-way door (choice locks architecture)
-- Preserving both adds complexity without value
-
-## Symptom Check — Are You Forcing Resolution?
-
-Watch for these in your own reasoning:
-
-- "We need to pick one" — without stating why both can't be preserved
-- "I'll just go with X" — choosing based on your preference, not user/deployment context
-- Oscillating between A and B on consecutive messages — you're sensing a real tension, not making a mistake
-- Resolving a disagreement to "move forward" — consensus for consensus's sake destroys information
-- "Which is best?" — when the real answer is "it depends on your context"
-
-**All of these are STOP signals. Consider preserving the tension instead.**
-
-## Preservation Patterns
-
-### Pattern 1: Configuration
-Make the choice configurable rather than baked in:
-
-```python
-class Config:
-    mode: Literal["optimize_cost", "optimize_latency"]
-    # Each mode gets a clean, simple implementation
-```
-
-**When to use:** Both approaches are architecturally compatible; switching is a runtime decision.
-
-### Pattern 2: Parallel Implementations
-Maintain both as separate, clean modules with a shared contract:
-
-```python
-# processor/batch.py    — optimizes for cost
-# processor/stream.py   — optimizes for latency
-# Both implement: def process(data) -> Result
-```
-
-**When to use:** Approaches diverge significantly but share the same interface.
-
-### Pattern 3: Documented Trade-off
-Capture the tension explicitly in documentation or an ADR:
-
-```markdown
-## Unresolved Tension: Authentication Strategy
-
-**Option A: JWT** — Stateless, scales easily, but token revocation is hard
-**Option B: Sessions** — Easy revocation, but requires shared state
-
-**Why unresolved:** Different deployments need different trade-offs
-**Decision deferred to:** Deployment configuration
-**Review trigger:** If 80% of deployments choose one option
-```
-
-**When to use:** Can't preserve both in code, but want to document the choice was deliberate and reversible.
-
-## When to Force Resolution
-
-Force resolution when one of these is true:
-
-1. **Implementation cost is prohibitive** — building and maintaining both would meaningfully slow development or the team lacks bandwidth
-2. **Fundamental conflict** — approaches make contradictory architectural assumptions and can't cleanly coexist
-3. **Clear technical superiority** — one approach objectively solves the constraints; not "I prefer X" but "X meets our requirements, Y doesn't"
-4. **One-way door** — the choice locks architecture; migrating between options would be expensive
-5. **Simplicity requires choice** — preserving both genuinely adds complexity and YAGNI applies
-
-When forcing resolution, state which of the above applies. "We need to pick one" is not a reason — it's a symptom of wanting to avoid the tension.
-
-**Ask explicitly:** "Should I pick one, or preserve both as options for different contexts?"
-
-## Documentation Format
-
-When preserving a tension, document it clearly:
-
-```markdown
-## Tension: [Name]
-
-**Context:** [Why this tension exists]
-
-**Option A:** [Approach]
-- Optimizes for: [Priority]
-- Trade-off: [Cost]
-- Best when: [Context]
-
-**Option B:** [Approach]
-- Optimizes for: [Different priority]
-- Trade-off: [Different cost]
-- Best when: [Different context]
-
-**Preservation strategy:** [Configuration / Parallel / Documented]
-
-**Resolution trigger:** [Conditions that would justify forcing a choice]
-```
-
-## Examples
-
-### Preserve — Context-dependent trade-off
-"Should we optimize for cost or latency in the inference pipeline?"
-- **Preserve:** Make it configurable — interactive use cases need latency, batch jobs need cost. Different deployments will choose differently.
-
-### Resolve — Technical constraint settles it
-"Should we use SSE or WebSockets for real-time updates?"
-- **Resolve:** SSE — we only need server-to-client communication; WebSockets adds bidirectional complexity without value for this use case.
-
-### Defer — Business decision, not technical
-"Should we support offline mode?"
-- **Defer to stakeholder:** Don't preserve both in code speculatively — ask who the users are and whether offline is part of the product promise.
-
-### Preserve — Stakeholder disagreement reveals context
-A stakeholder wants strict input validation upfront; another wants lenient parsing that handles messy real-world data.
-- **Preserve:** Both are valid for different integration contexts. Offer a `strict` vs `lenient` mode rather than overruling either.
-
-## Core Reminders
-
-- Oscillating between A and B is often a signal that both are right — for different contexts
-- Premature consensus destroys the flexibility that reveals context-dependence
-- Configuration beats forced choice (when the implementation overhead is low)
-- Document trade-offs so future engineers can revisit with better information
-- Forcing resolution is always valid — but state the reason explicitly

package/skills/architecture/preserving-productive-tensions/skill.json

@@ -1,9 +0,0 @@
-{
-    "version": "1.2.0",
-    "name": "superpowers:architecture/preserving-productive-tensions",
-    "title": "Preserving Productive Tensions",
-    "aliases": [
-        "preserving-productive-tensions",
-        "architecture/preserving-productive-tensions"
-    ]
-}

package/skills/collaboration/brainstorming/spec-document-reviewer-prompt.md

@@ -1,50 +0,0 @@
-# Spec Document Reviewer Prompt Template
-
-Use this template when dispatching a spec document reviewer subagent.
-
-**Purpose:** Verify the spec is complete, consistent, and ready for implementation planning.
-
-**Dispatch after:** Spec document is written to `docs/superpowers/specs/`
-
-```
-Task tool (general-purpose):
-  description: "Review spec document"
-  prompt: |
-    You are a spec document reviewer. Verify this spec is complete and ready for planning.
-
-    **Spec to review:** [SPEC_FILE_PATH]
-
-    ## What to Check
-
-    | Category | What to Look For |
-    |----------|------------------|
-    | Completeness | TODOs, placeholders, "TBD", incomplete sections |
-    | Coverage | Missing error handling, edge cases, integration points |
-    | Consistency | Internal contradictions, conflicting requirements |
-    | Clarity | Ambiguous requirements |
-    | YAGNI | Unrequested features, over-engineering |
-    | Scope | Focused enough for a single plan — not covering multiple independent subsystems |
-    | Architecture | Units with clear boundaries, well-defined interfaces, independently understandable and testable |
-
-    ## CRITICAL
-
-    Look especially hard for:
-    - Any TODO markers or placeholder text
-    - Sections saying "to be defined later" or "will spec when X is done"
-    - Sections noticeably less detailed than others
-    - Units that lack clear boundaries or interfaces — can you understand what each unit does without reading its internals?
-
-    ## Output Format
-
-    ## Spec Review
-
-    **Status:** ✅ Approved | ❌ Issues Found
-
-    **Issues (if any):**
-    - [Section X]: [specific issue] - [why it matters]
-
-    **Recommendations (advisory):**
-    - [suggestions that don't block approval]
-```
-
-**Reviewer returns:** Status, Issues (if any), Recommendations

package/skills/collaboration/brainstorming/visual-companion.md

@@ -1,277 +0,0 @@
-# Visual Companion Guide
-
-Browser-based visual brainstorming companion for showing mockups, diagrams, and options.
-
-## When to Use
-
-Decide per-question, not per-session. The test: **would the user understand this better by seeing it than reading it?**
-
-**Use the browser** when the content itself is visual:
-
-- **UI mockups** — wireframes, layouts, navigation structures, component designs
-- **Architecture diagrams** — system components, data flow, relationship maps
-- **Side-by-side visual comparisons** — comparing two layouts, two color schemes, two design directions
-- **Design polish** — when the question is about look and feel, spacing, visual hierarchy
-- **Spatial relationships** — state machines, flowcharts, entity relationships rendered as diagrams
-
-**Use the terminal** when the content is text or tabular:
-
-- **Requirements and scope questions** — "what does X mean?", "which features are in scope?"
-- **Conceptual A/B/C choices** — picking between approaches described in words
-- **Tradeoff lists** — pros/cons, comparison tables
-- **Technical decisions** — API design, data modeling, architectural approach selection
-- **Clarifying questions** — anything where the answer is words, not a visual preference
-
-A question *about* a UI topic is not automatically a visual question. "What kind of wizard do you want?" is conceptual — use the terminal. "Which of these wizard layouts feels right?" is visual — use the browser.
-
-## How It Works
-
-The server watches a directory for HTML files and serves the newest one to the browser. You write HTML content, the user sees it in their browser and can click to select options. Selections are recorded to a `.events` file that you read on your next turn.
-
-**Content fragments vs full documents:** If your HTML file starts with `<!DOCTYPE` or `<html`, the server serves it as-is (just injects the helper script). Otherwise, the server automatically wraps your content in the frame template — adding the header, CSS theme, selection indicator, and all interactive infrastructure. **Write content fragments by default.** Only write full documents when you need complete control over the page.
-
-## Starting a Session
-
-```bash
-# Start server with persistence (mockups saved to project)
-scripts/start-server.sh --project-dir /path/to/project
-
-# Returns: {"type":"server-started","port":52341,"url":"http://localhost:52341",
-#           "screen_dir":"/path/to/project/.superpowers/brainstorm/12345-1706000000"}
-```
-
-Save `screen_dir` from the response. Tell user to open the URL.
-
-**Finding connection info:** The server writes its startup JSON to `$SCREEN_DIR/.server-info`. If you launched the server in the background and didn't capture stdout, read that file to get the URL and port. When using `--project-dir`, check `<project>/.superpowers/brainstorm/` for the session directory.
-
-**Note:** Pass the project root as `--project-dir` so mockups persist in `.superpowers/brainstorm/` and survive server restarts. Without it, files go to `/tmp` and get cleaned up. Remind the user to add `.superpowers/` to `.gitignore` if it's not already there.
-
-**Launching the server by platform:**
-
-**Claude Code / OpenCode:**
-```bash
-# Default mode works — the script backgrounds the server itself
-scripts/start-server.sh --project-dir /path/to/project
-```
-
-**Codex:**
-```bash
-# Codex reaps background processes. The script auto-detects CODEX_CI and
-# switches to foreground mode. Run it normally — no extra flags needed.
-scripts/start-server.sh --project-dir /path/to/project
-```
-
-**Gemini CLI:**
-```bash
-# Use --foreground and set is_background: true on your shell tool call
-# so the process survives across turns
-scripts/start-server.sh --project-dir /path/to/project --foreground
-```
-
-**Other environments:** The server must keep running in the background across conversation turns. If your environment reaps detached processes, use `--foreground` and launch the command with your platform's background execution mechanism.
-
-If the URL is unreachable from your browser (common in remote/containerized setups), bind a non-loopback host:
-
-```bash
-scripts/start-server.sh \
-  --project-dir /path/to/project \
-  --host 0.0.0.0 \
-  --url-host localhost
-```
-
-Use `--url-host` to control what hostname is printed in the returned URL JSON.
-
-## The Loop
-
-1. **Check server is alive**, then **write HTML** to a new file in `screen_dir`:
-   - Before each write, check that `$SCREEN_DIR/.server-info` exists. If it doesn't (or `.server-stopped` exists), the server has shut down — restart it with `start-server.sh` before continuing. The server auto-exits after 30 minutes of inactivity.
-   - Use semantic filenames: `platform.html`, `visual-style.html`, `layout.html`
-   - **Never reuse filenames** — each screen gets a fresh file
-   - Use Write tool — **never use cat/heredoc** (dumps noise into terminal)
-   - Server automatically serves the newest file
-
-2. **Tell user what to expect and end your turn:**
-   - Remind them of the URL (every step, not just first)
-   - Give a brief text summary of what's on screen (e.g., "Showing 3 layout options for the homepage")
-   - Ask them to respond in the terminal: "Take a look and let me know what you think. Click to select an option if you'd like."
-
-3. **On your next turn** — after the user responds in the terminal:
-   - Read `$SCREEN_DIR/.events` if it exists — this contains the user's browser interactions (clicks, selections) as JSON lines
-   - Merge with the user's terminal text to get the full picture
-   - The terminal message is the primary feedback; `.events` provides structured interaction data
-
-4. **Iterate or advance** — if feedback changes current screen, write a new file (e.g., `layout-v2.html`). Only move to the next question when the current step is validated.
-
-5. **Unload when returning to terminal** — when the next step doesn't need the browser (e.g., a clarifying question, a tradeoff discussion), push a waiting screen to clear the stale content:
-
-   ```html
-   <!-- filename: waiting.html (or waiting-2.html, etc.) -->
-   <div style="display:flex;align-items:center;justify-content:center;min-height:60vh">
-     <p class="subtitle">Continuing in terminal...</p>
-   </div>
-   ```
-
-   This prevents the user from staring at a resolved choice while the conversation has moved on. When the next visual question comes up, push a new content file as usual.
-
-6. Repeat until done.
-
-## Writing Content Fragments
-
-Write just the content that goes inside the page. The server wraps it in the frame template automatically (header, theme CSS, selection indicator, and all interactive infrastructure).
-
-**Minimal example:**
-
-```html
-<h2>Which layout works better?</h2>
-<p class="subtitle">Consider readability and visual hierarchy</p>
-
-<div class="options">
-  <div class="option" data-choice="a" onclick="toggleSelect(this)">
-    <div class="letter">A</div>
-    <div class="content">
-      <h3>Single Column</h3>
-      <p>Clean, focused reading experience</p>
-    </div>
-  </div>
-  <div class="option" data-choice="b" onclick="toggleSelect(this)">
-    <div class="letter">B</div>
-    <div class="content">
-      <h3>Two Column</h3>
-      <p>Sidebar navigation with main content</p>
-    </div>
-  </div>
-</div>
-```
-
-That's it. No `<html>`, no CSS, no `<script>` tags needed. The server provides all of that.
-
-## CSS Classes Available
-
-The frame template provides these CSS classes for your content:
-
-### Options (A/B/C choices)
-
-```html
-<div class="options">
-  <div class="option" data-choice="a" onclick="toggleSelect(this)">
-    <div class="letter">A</div>
-    <div class="content">
-      <h3>Title</h3>
-      <p>Description</p>
-    </div>
-  </div>
-</div>
-```
-
-**Multi-select:** Add `data-multiselect` to the container to let users select multiple options. Each click toggles the item. The indicator bar shows the count.
-
-```html
-<div class="options" data-multiselect>
-  <!-- same option markup — users can select/deselect multiple -->
-</div>
-```
-
-### Cards (visual designs)
-
-```html
-<div class="cards">
-  <div class="card" data-choice="design1" onclick="toggleSelect(this)">
-    <div class="card-image"><!-- mockup content --></div>
-    <div class="card-body">
-      <h3>Name</h3>
-      <p>Description</p>
-    </div>
-  </div>
-</div>
-```
-
-### Mockup container
-
-```html
-<div class="mockup">
-  <div class="mockup-header">Preview: Dashboard Layout</div>
-  <div class="mockup-body"><!-- your mockup HTML --></div>
-</div>
-```
-
-### Split view (side-by-side)
-
-```html
-<div class="split">
-  <div class="mockup"><!-- left --></div>
-  <div class="mockup"><!-- right --></div>
-</div>
-```
-
-### Pros/Cons
-
-```html
-<div class="pros-cons">
-  <div class="pros"><h4>Pros</h4><ul><li>Benefit</li></ul></div>
-  <div class="cons"><h4>Cons</h4><ul><li>Drawback</li></ul></div>
-</div>
-```
-
-### Mock elements (wireframe building blocks)
-
-```html
-<div class="mock-nav">Logo | Home | About | Contact</div>
-<div style="display: flex;">
-  <div class="mock-sidebar">Navigation</div>
-  <div class="mock-content">Main content area</div>
-</div>
-<button class="mock-button">Action Button</button>
-<input class="mock-input" placeholder="Input field">
-<div class="placeholder">Placeholder area</div>
-```
-
-### Typography and sections
-
-- `h2` — page title
-- `h3` — section heading
-- `.subtitle` — secondary text below title
-- `.section` — content block with bottom margin
-- `.label` — small uppercase label text
-
-## Browser Events Format
-
-When the user clicks options in the browser, their interactions are recorded to `$SCREEN_DIR/.events` (one JSON object per line). The file is cleared automatically when you push a new screen.
-
-```jsonl
-{"type":"click","choice":"a","text":"Option A - Simple Layout","timestamp":1706000101}
-{"type":"click","choice":"c","text":"Option C - Complex Grid","timestamp":1706000108}
-{"type":"click","choice":"b","text":"Option B - Hybrid","timestamp":1706000115}
-```
-
-The full event stream shows the user's exploration path — they may click multiple options before settling. The last `choice` event is typically the final selection, but the pattern of clicks can reveal hesitation or preferences worth asking about.
-
-If `.events` doesn't exist, the user didn't interact with the browser — use only their terminal text.
-
-## Design Tips
-
-- **Scale fidelity to the question** — wireframes for layout, polish for polish questions
-- **Explain the question on each page** — "Which layout feels more professional?" not just "Pick one"
-- **Iterate before advancing** — if feedback changes current screen, write a new version
-- **2-4 options max** per screen
-- **Use real content when it matters** — for a photography portfolio, use actual images (Unsplash). Placeholder content obscures design issues.
-- **Keep mockups simple** — focus on layout and structure, not pixel-perfect design
-
-## File Naming
-
-- Use semantic names: `platform.html`, `visual-style.html`, `layout.html`
-- Never reuse filenames — each screen must be a new file
-- For iterations: append version suffix like `layout-v2.html`, `layout-v3.html`
-- Server serves newest file by modification time
-
-## Cleaning Up
-
-```bash
-scripts/stop-server.sh $SCREEN_DIR
-```
-
-If the session used `--project-dir`, mockup files persist in `.superpowers/brainstorm/` for later reference. Only `/tmp` sessions get deleted on stop.
-
-## Reference
-
-- Frame template (CSS reference): `scripts/frame-template.html`
-- Helper script (client-side): `scripts/helper.js`

package/skills/collaboration/dispatching-parallel-agents/SKILL.md

@@ -1,174 +0,0 @@
----
-name: dispatching-parallel-agents
-description: Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies. Invoke this skill whenever you have multiple unrelated problems, parallel research tasks, independent features, or concurrent investigations where agents can work simultaneously without interfering with each other.
-metadata:
-  version: 1.3.0
-  languages: all
-  context: AI-assisted development (Claude Code or similar)
----
-
-# Dispatching Parallel Agents
-
-## Overview
-
-When you have multiple independent tasks — different failing tests, separate research questions, unrelated features, distinct subsystems — handling them sequentially wastes time. Each task can be delegated to a focused agent working in isolation.
-
-**Core principle:** Dispatch one agent per independent problem domain. Let them work concurrently.
-
-**Key insight:** Agents work with isolated context. They never inherit your session's history — you construct exactly what they need. This keeps each agent focused on its task and preserves your own context for coordination work.
-
-## When to Use
-
-```mermaid
-flowchart TD
-    A[Multiple independent tasks?] -->|yes| B[Are they independent?]
-    B -->|no - related| C[Single agent handles all]
-    B -->|yes| D[Can they run in parallel?]
-    D -->|yes| E[Parallel dispatch]
-    D -->|no - shared state| F[Sequential agents]
-```
-
-**Use when:**
-- 2+ test files failing with different root causes
-- Multiple subsystems need investigation independently
-- Parallel research across different sources or topics
-- Independent features that don't share state
-- Each task can be understood without context from the others
-
-**Don't use when:**
-- Tasks are related (completing one reveals what the next needs)
-- Need to understand the full system state before acting
-- Agents would edit the same files or shared resources
-- Exploratory debugging where you don't know what's broken yet
-
-## The Pattern
-
-### 1. Identify Independent Domains
-
-Group tasks by what they involve and confirm they don't share state:
-- Task A: Tool approval flow tests
-- Task B: Batch completion behavior
-- Task C: Abort functionality
-
-Verify: fixing A doesn't affect B or C. If unsure, investigate one first.
-
-### 2. Craft Focused, Self-Contained Agent Prompts
-
-Each agent prompt must include everything the agent needs — it has no access to your session's context. Include:
-- **Specific scope:** One test file, subsystem, or question
-- **Clear goal:** What does success look like?
-- **Relevant context:** Error messages, file contents, background
-- **Constraints:** What should the agent avoid touching?
-- **Expected output:** What should the agent return?
-
-### 3. Dispatch in Parallel
-
-```typescript
-// All three run concurrently — don't await between them
-Task("Fix agent-tool-abort.test.ts failures")
-Task("Fix batch-completion-behavior.test.ts failures")
-Task("Fix tool-approval-race-conditions.test.ts failures")
-```
-
-For research tasks, the same applies:
-```typescript
-Task("Research rate limiting patterns in REST APIs")
-Task("Research websocket reconnection strategies")
-Task("Research OAuth2 PKCE flow implementation")
-```
-
-### 4. Review and Integrate
-
-When agents return:
-- Read each summary
-- Verify fixes don't conflict with each other
-- Run the full test suite or integration check
-- Combine the results
-
-## Writing Good Agent Prompts
-
-The quality of the prompt determines whether the agent succeeds. Because agents start with isolated context, you are responsible for giving them exactly what they need.
-
-**Debugging example:**
-```markdown
-Fix the 3 failing tests in src/agents/agent-tool-abort.test.ts:
-
-1. "should abort tool with partial output capture" - expects 'interrupted at' in message
-2. "should handle mixed completed and aborted tools" - fast tool aborted instead of completed
-3. "should properly track pendingToolCount" - expects 3 results but gets 0
-
-These are likely timing/race condition issues. Your task:
-1. Read the test file and understand what each test verifies
-2. Identify root cause — timing issues or actual bugs?
-3. Fix by replacing arbitrary timeouts with event-based waiting,
-   or fixing bugs in the abort implementation
-4. Do NOT just increase timeouts — find the real issue
-5. Do NOT change production code outside this domain
-
-Return: Summary of root cause and what you changed.
-```
-
-**Research example:**
-```markdown
-Research best practices for handling WebSocket reconnection in browser clients.
-
-Focus on:
-- Exponential backoff with jitter
-- Maximum retry limits
-- Detecting intentional vs. unintentional disconnects
-- Common pitfalls (memory leaks, event listener accumulation)
-
-Return: A concise summary of patterns with pros/cons for each.
-```
-
-## Common Mistakes
-
-| Problem | Bad | Good |
-|---|---|---|
-| Scope too broad | "Fix all the tests" | "Fix agent-tool-abort.test.ts" |
-| Missing context | "Fix the race condition" | Include error messages and test names |
-| No constraints | (none given) | "Do NOT change production code" |
-| Vague output | "Fix it" | "Return summary of root cause and changes" |
-| Assuming context | (no background) | Include relevant code snippets or file contents |
-
-## When NOT to Dispatch in Parallel
-
-- **Related failures:** Fix one might fix others — investigate sequentially first
-- **Unknown breakage:** You don't know what's broken yet — explore first, then parallelize
-- **Shared state:** Agents would interfere (editing same files, consuming same resources)
-- **Dependent tasks:** Task B needs the output of Task A to know what to do
-
-## Verification After Agents Return
-
-1. **Review each summary** — understand what each agent changed and why
-2. **Check for conflicts** — did any agents edit the same code?
-3. **Run the full suite** — verify all fixes work together
-4. **Spot check** — agents can make systematic errors; sample a few outputs
-
-## Example: Debugging Session
-
-**Scenario:** 6 test failures across 3 files after a major refactoring
-
-| File | Failures | Root cause domain |
-|---|---|---|
-| `agent-tool-abort.test.ts` | 3 | Timing/race conditions |
-| `batch-completion-behavior.test.ts` | 2 | Event structure bug |
-| `tool-approval-race-conditions.test.ts` | 1 | Async execution timing |
-
-**Decision:** Three independent domains — abort logic is separate from batch completion, which is separate from race conditions.
-
-**Dispatch:** Three agents in parallel, each scoped to one file.
-
-**Results:**
-- Agent 1: Replaced arbitrary timeouts with event-based waiting
-- Agent 2: Fixed event structure bug (threadId in wrong location)
-- Agent 3: Added wait for async tool execution to complete
-
-**Integration:** All fixes independent, no conflicts, full suite green.
-
-## Key Benefits
-
-1. **Speed** — N problems solved in the time of 1
-2. **Focus** — Each agent has narrow scope and less context to track
-3. **Independence** — Agents don't interfere with each other
-4. **Context preservation** — Your coordination context stays clean while agents work

package/skills/collaboration/dispatching-parallel-agents/skill.json

@@ -1,9 +0,0 @@
-{
-    "version": "1.1.0",
-    "name": "superpowers:collaboration/dispatching-parallel-agents",
-    "title": "Dispatching Parallel Agents",
-    "aliases": [
-        "dispatching-parallel-agents",
-        "collaboration/dispatching-parallel-agents"
-    ]
-}