@arthai/agents 1.0.0

package/skills/sre/SKILL.md

@@ -0,0 +1,362 @@
+---
+name: sre
+description: "Run SRE operations. Usage: /sre [command]. Commands: status, health, logs, deploy-check, ci, sleep, wake, debug, rebuild, dialog"
+user-invocable: true
+arguments: "<command> <options>"
+---
+
+# SRE Skill
+
+Wraps the SRE agent for infrastructure operations. Reads project context from CLAUDE.md to route to the right tools.
+
+## Project Context Discovery (Deep)
+
+Before ANY operation, discover the full infrastructure landscape. This runs on every /sre invocation
+to ensure context is current.
+
+### Step 1: Read existing context
+
+Read in this order (skip gracefully if missing):
+1. `CLAUDE.md` — Infrastructure table, services, health endpoints
+2. `.claude/project-profile.md` — Architecture, deploy platform (from /calibrate)
+3. `.claude/knowledge/agents/sre.md` — Past incidents, platform patterns learned
+4. `.claude/knowledge/shared/decisions.md` — Infrastructure decisions made
+5. `.claude/qa-knowledge/incidents/` — Past production incidents
+
+### Step 2: Detect deploy platform (if not in profile)
+
+Scan project files to identify the FULL infrastructure stack:
+
+**Cloud Provider Detection:**
+| Signal | Provider | What to check |
+|--------|----------|--------------|
+| `AWS_*` env vars, `~/.aws/`, `samconfig.toml`, `cdk.json` | AWS | Regions, services, IAM roles |
+| `GOOGLE_*` env vars, `app.yaml`, `cloudbuild.yaml` | GCP | Projects, regions, services |
+| `AZURE_*` env vars, `azure-pipelines.yml` | Azure | Subscriptions, resource groups |
+
+**Platform Detection:**
+| Signal | Platform | CLI | MCP Available |
+|--------|----------|-----|--------------|
+| `railway.json`, `railway.toml`, `Procfile` | Railway | `railway` | Railway MCP |
+| `vercel.json`, `.vercel/` | Vercel | `vercel` | Vercel MCP |
+| `fly.toml` | Fly.io | `flyctl` | — |
+| `render.yaml` | Render | `render` | — |
+| `heroku.yml`, `Procfile` + Heroku remote | Heroku | `heroku` | — |
+| `netlify.toml` | Netlify | `netlify` | — |
+| `terraform/`, `*.tf` | Terraform (IaC) | `terraform` | AWS/GCP MCP |
+| `pulumi/`, `Pulumi.yaml` | Pulumi (IaC) | `pulumi` | AWS/GCP MCP |
+| `cdk/`, `cdk.json` | AWS CDK | `cdk` | AWS MCP |
+| `k8s/`, `helm/`, `Chart.yaml`, `kustomize/` | Kubernetes | `kubectl`, `helm` | K8s MCP |
+| `docker-compose.yml` + no platform | Docker only | `docker` | Docker MCP |
+| `serverless.yml` | Serverless Framework | `sls` | AWS/GCP MCP |
+| `firebase.json` | Firebase | `firebase` | Firebase MCP |
+| `supabase/config.toml` | Supabase | `supabase` | Supabase MCP |
+
+**Database Detection:**
+| Signal | Database | Monitoring |
+|--------|----------|-----------|
+| `DATABASE_URL` contains `postgres` | PostgreSQL | pg_stat, connection pool health |
+| `DATABASE_URL` contains `mysql` | MySQL | slow query log, connection health |
+| `MONGODB_URI` | MongoDB | mongosh status, replica set health |
+| `REDIS_URL` | Redis | `redis-cli info`, memory, connections |
+| `ELASTICSEARCH_URL` | Elasticsearch | cluster health, index status |
+
+**Monitoring/Observability Detection:**
+| Signal | Tool | What it provides |
+|--------|------|-----------------|
+| `SENTRY_DSN` or `@sentry/` import | Sentry | Error tracking, performance |
+| `DATADOG_*` env vars | Datadog | APM, logs, metrics |
+| `NEW_RELIC_*` env vars | New Relic | APM, infrastructure |
+| `GRAFANA_*` or `grafana/` | Grafana | Dashboards, alerting |
+| `PROMETHEUS_*` or `prometheus/` | Prometheus | Metrics collection |
+| `PAGERDUTY_*` env vars | PagerDuty | Incident management |
+| `OPSGENIE_*` env vars | OpsGenie | Alert routing |
+
+**CI/CD Detection (used by /ci-fix but discovered here for completeness):**
+| Signal | CI Platform | CLI |
+|--------|------------|-----|
+| `.github/workflows/` | GitHub Actions | `gh run` |
+| `.gitlab-ci.yml` | GitLab CI | `glab ci` |
+| `Jenkinsfile` | Jenkins | Jenkins API |
+| `.circleci/config.yml` | CircleCI | `circleci` CLI |
+| `bitbucket-pipelines.yml` | Bitbucket Pipelines | Bitbucket API |
+| `.buildkite/` | Buildkite | `buildkite-agent` |
+| `azure-pipelines.yml` | Azure DevOps | `az pipelines` |
+| `.travis.yml` | Travis CI | Travis API |
+
+### Step 3: Recommend missing tools
+
+Based on what was detected, recommend tools the project SHOULD have:
+
+**Format:**
+```
+SRE Recommendations for {project}:
+
+Platform: {detected platform}
+Database: {detected databases}
+Monitoring: {detected or MISSING}
+CI/CD: {detected CI platform}
+
+Missing (recommended):
+  ⚠ No monitoring detected — recommend Sentry (free tier, 5K errors/mo)
+    Install: pip install sentry-sdk / npm install @sentry/node
+  ⚠ No Redis health monitoring — recommend redis-cli in health checks
+  ⚠ No MCP server for {platform} — would enable direct platform queries
+    /calibrate can install this automatically
+
+Data sources to connect:
+  • {platform} logs → available via {CLI/MCP}
+  • {database} metrics → available via {query/MCP}
+  • {monitoring tool} alerts → available via {API/MCP}
+  • Health endpoints: {list from CLAUDE.md or recommend adding}
+```
+
+### Step 4: Write discoveries to knowledge base
+
+After discovery, update these files (if `.claude/knowledge/` exists):
+- Append to `knowledge/agents/sre.md`: platform detected, services found, health endpoints
+- If first time: create the file with initial platform context
+
+## Argument Parsing
+
+Parse from the argument string:
+- `command`: Optional. One of: `status`, `health`, `logs`, `deploy-check`, `ci`, `sleep`, `wake`, `debug`, `rebuild`, `dialog`. Defaults to `status` if omitted.
+- Options vary by command (see below).
+
+## Commands
+
+### `/sre` or `/sre status`
+Full system status — all services, all environments.
+
+Spawn SRE agent:
+```
+subagent_type: "sre"
+model: "sonnet"
+prompt: "Run a full status check. Read CLAUDE.md ## Environments table. For each environment, check status using the appropriate method from the Access Methods table in project-profile.md.
+1. Check deployment platform service status (Railway MCP, Vercel CLI, etc.)
+2. Hit all health endpoints listed in CLAUDE.md
+3. Check latest GitHub Actions: gh run list --branch main --limit 3
+Report a structured pass/fail table."
+```
+
+### `/sre health`
+Quick health check — just hit endpoints.
+
+Spawn SRE agent:
+```
+subagent_type: "sre"
+model: "sonnet"
+prompt: "Quick health check. Read CLAUDE.md ## Environments table. Hit the health endpoint for every listed environment (URL + Health column). Report pass/fail per environment. Skip environments with <!-- TODO --> URLs."
+```
+
+### `/sre logs [service]`
+View recent deploy logs. Default service: first service in Infrastructure table.
+
+Spawn SRE agent:
+```
+subagent_type: "sre"
+model: "sonnet"
+prompt: "Get recent deploy logs for '{service or default}'. Read CLAUDE.md for infrastructure details. Use platform-appropriate tools (Railway MCP, Vercel CLI, etc.). Filter for errors and summarize issues found."
+```
+
+### `/sre deploy-check`
+Verify latest deployment succeeded end-to-end.
+
+Spawn SRE agent:
+```
+subagent_type: "sre"
+model: "sonnet"
+prompt: "Full deployment verification. Read CLAUDE.md for infrastructure.
+1. Check recent CI runs: gh run list --branch main --limit 5
+2. Check deployment platform for latest deploys
+3. Hit all health endpoints
+4. Compare migration state if applicable
+Report structured pass/fail for each step."
+```
+
+### `/sre ci`
+Check CI/CD pipeline status and diagnose failures.
+
+Spawn SRE agent:
+```
+subagent_type: "sre"
+model: "sonnet"
+prompt: "Check CI/CD status:
+1. gh run list --branch main --limit 5
+2. If any failed: gh run view <id> --log-failed
+3. Report which workflows passed/failed, failure details, suggested fixes."
+```
+
+### `/sre sleep`
+Sleep staging to save costs (platform-specific).
+
+Spawn SRE agent:
+```
+subagent_type: "sre"
+model: "sonnet"
+prompt: "Sleep the specified environment (default: first staging-type environment from CLAUDE.md ## Environments table). Read CLAUDE.md for environment details. Use platform-appropriate commands. Verify services scaled to 0. Report estimated savings."
+```
+
+### `/sre wake`
+Wake staging environment.
+
+Spawn SRE agent:
+```
+subagent_type: "sre"
+model: "sonnet"
+prompt: "Wake the specified environment (default: first staging-type environment from CLAUDE.md ## Environments table). Read CLAUDE.md for environment details. Use platform-appropriate commands. Wait for health checks to pass. Report status."
+```
+
+### `/sre debug [description]`
+Systematic debugging of a production issue.
+
+Spawn SRE agent:
+```
+subagent_type: "sre"
+model: "sonnet"
+prompt: "Debug this issue: '{description}'. Read CLAUDE.md for infrastructure.
+Read CLAUDE.md ## Environments table. For each environment, check status using the appropriate
+method from the Access Methods table in project-profile.md.
+
+Systematic approach:
+1. CONFIRM — check health endpoints + metrics for all environments in the Environments table
+2. SCOPE — which service(s) and environment(s) affected?
+3. DIAGNOSE — RED method (Rate/Errors/Duration) for API, USE method (Utilization/Saturation/Errors) for infra
+4. Check deployment logs for errors
+5. Check GitHub Actions for recent failures
+6. ROOT CAUSE — what specifically caused the issue?
+7. CLASSIFY FIX TYPE — determine if this is:
+   a. Infra-only fix (restart, config change, scale, DNS) → fix directly, verify health
+   b. Code bug → escalate to /fix (do NOT fix code directly — /fix has verification pipeline)
+8. IF INFRA FIX:
+   - Apply the fix (restart, config change, etc.)
+   - Verify health endpoints for affected environments
+   - Ask user to smoke-test if config was changed
+   - Write incident report
+9. IF CODE BUG:
+   - Document findings (root cause, affected files, evidence)
+   - Escalate to /fix with all context — /fix will handle QA, testing, and PR
+   - Do NOT write code or create PRs from /sre debug
+
+After root cause is identified, also write a QA incident file at
+.claude/qa-knowledge/incidents/{YYYY-MM-DD}-{slug}.md with root cause, how QA missed it, and regression test recommendation."
+```
+
+**Post-debug handoff:**
+
+After `/sre debug` completes:
+
+| Fix type | What happens next |
+|----------|------------------|
+| Infra fix applied | Verify health → ask user to smoke-test → "What's next?" |
+| Code bug identified | Route to `/fix {description} --severity {severity}` with all gathered evidence. `/fix` handles: root cause verification → scope lock → behavior contract → implement → QA → user test → PR |
+| Inconclusive | Present findings → ask user: "Should I investigate further, or route to /fix?" |
+
+**What's next (after infra fix):**
+```
+Fix applied and verified. Environments healthy.
+
+What's next?
+  [1] Monitor — /sre health in 5 min to confirm fix holds
+  [2] Investigate further — check related systems
+  [3] See project status — /onboard
+  [4] Done for now
+```
+
+### `/sre dialog`
+Analyze the latest local agent interview dialog. Checks verbosity, Q-tag leaks, NOTES leaks, and TTS filter activity.
+
+**Do NOT spawn an agent.** Run directly:
+
+1. Read `/tmp/agent.log`
+2. Extract all `Agent said:` lines (deduplicate — each appears twice in logs)
+3. Report:
+
+```
+## Interview Dialog Analysis
+
+| # | Turn | Response (truncated) | Words | Chars |
+|---|------|---------------------|-------|-------|
+| 1 | Intro | "Hi! I'm Sarah..." | 37 | 186 |
+| 2 | Reaction | "Great answer!..." | 12 | 58 |
+...
+
+**Verbosity**: avg X words/turn (target: <40, Feb 8 baseline: 15-20)
+**Q-tag leaks**: [Q1]-[Q5] found in raw output? YES/NO
+**NOTES leaks**: [NOTES] blocks in raw output? YES/NO
+**TTS filter**: [TTS-FILTER] log entries found? (shows filter activity)
+**Truncation**: Any responses cut off mid-sentence? (sign of token limit)
+**max_completion_tokens**: Read from agent/main.py line with max_completion_tokens
+```
+
+4. If verbosity avg > 40 words, recommend lowering `max_completion_tokens`
+5. If Q-tag leaks found, check if `[TTS-FILTER]` logs show they were stripped before TTS
+
+### `/sre rebuild`
+Clean rebuild of a monorepo — nuke caches, rebuild all packages, restart services.
+
+This is the nuclear option when turbo/next/tsc caching causes stale builds, phantom errors, or "works locally but not in dev server" issues.
+
+Steps to execute directly (do NOT spawn an agent — run these yourself):
+
+1. **Read CLAUDE.md** for project root, build commands, and Local Dev Services table.
+
+2. **Stop running services** using the stop/kill commands from CLAUDE.md:
+   ```bash
+   # Read Local Dev Services table for ports and kill running processes
+   lsof -ti:<port> | xargs kill -9 2>/dev/null
+   ```
+
+3. **Nuke all caches**:
+   ```bash
+   cd <project-root> && rm -rf node_modules/.cache .next .turbo packages/*/dist packages/*/.next packages/*/.turbo
+   ```
+
+4. **Rebuild from scratch** using the project's build command from CLAUDE.md:
+   ```bash
+   cd <project-root> && <build-command>
+   ```
+   For monorepos, if the top-level build fails, try building packages individually in dependency order (read `pnpm-workspace.yaml` or `package.json` workspaces to determine order).
+
+5. **Restart services** using start commands from CLAUDE.md Local Dev Services table.
+
+6. **Verify**:
+   - Hit health endpoints from CLAUDE.md (or the ports listed in Local Dev Services table)
+   - Check no build errors in output
+
+Report success/failure with before/after comparison (which packages rebuilt, any errors).
+
+## Knowledge Base Integration
+
+### On every /sre invocation:
+1. **Read** `.claude/knowledge/agents/sre.md` for past incidents and patterns
+2. **Read** `.claude/qa-knowledge/incidents/` for production issues in this area
+
+### After /sre debug:
+1. **Write** incident to `.claude/qa-knowledge/incidents/{date}-{slug}.md`
+2. **Append** to `.claude/knowledge/agents/sre.md`:
+   ```
+   ### {date} — {incident title}
+   **Platform**: {platform}
+   **Root cause**: {what happened}
+   **Fix**: {what was done}
+   **Prevention**: {how to avoid next time}
+   ```
+
+### After first discovery on a project:
+1. **Write** platform summary to `knowledge/agents/sre.md`
+2. **Update** `project-profile.md` if infrastructure section is incomplete
+3. **Recommend** MCP servers to /calibrate's recommendations
+
+## /calibrate Integration
+
+When `/calibrate` runs, it reads all agent definitions to build recommendations.
+The SRE skill contributes:
+
+1. **Platform detection results** → /calibrate uses for MCP server recommendations
+2. **Missing monitoring tools** → /calibrate includes in "recommended tools"
+3. **Health endpoint inventory** → /calibrate writes to project profile
+4. **CI/CD platform** → /calibrate uses for ci-fix configuration
+
+If `/calibrate` has already run, /sre reads `project-profile.md` instead of re-discovering.
+If `/calibrate` hasn't run, /sre does its own discovery and recommends running `/calibrate`.

package/skills/superpowers/brainstorming/SKILL.md

@@ -0,0 +1,96 @@
+---
+name: brainstorming
+description: "You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation."
+---
+
+# Brainstorming Ideas Into Designs
+
+## Overview
+
+Help turn ideas into fully formed designs and specs through natural collaborative dialogue.
+
+Start by understanding the current project context, then ask questions one at a time to refine the idea. Once you understand what you're building, present the design and get user approval.
+
+<HARD-GATE>
+Do NOT invoke any implementation skill, write any code, scaffold any project, or take any implementation action until you have presented a design and the user has approved it. This applies to EVERY project regardless of perceived simplicity.
+</HARD-GATE>
+
+## Anti-Pattern: "This Is Too Simple To Need A Design"
+
+Every project goes through this process. A todo list, a single-function utility, a config change — all of them. "Simple" projects are where unexamined assumptions cause the most wasted work. The design can be short (a few sentences for truly simple projects), but you MUST present it and get approval.
+
+## Checklist
+
+You MUST create a task for each of these items and complete them in order:
+
+1. **Explore project context** — check files, docs, recent commits
+2. **Ask clarifying questions** — one at a time, understand purpose/constraints/success criteria
+3. **Propose 2-3 approaches** — with trade-offs and your recommendation
+4. **Present design** — in sections scaled to their complexity, get user approval after each section
+5. **Write design doc** — save to `docs/plans/YYYY-MM-DD-<topic>-design.md` and commit
+6. **Transition to implementation** — invoke writing-plans skill to create implementation plan
+
+## Process Flow
+
+```dot
+digraph brainstorming {
+    "Explore project context" [shape=box];
+    "Ask clarifying questions" [shape=box];
+    "Propose 2-3 approaches" [shape=box];
+    "Present design sections" [shape=box];
+    "User approves design?" [shape=diamond];
+    "Write design doc" [shape=box];
+    "Invoke writing-plans skill" [shape=doublecircle];
+
+    "Explore project context" -> "Ask clarifying questions";
+    "Ask clarifying questions" -> "Propose 2-3 approaches";
+    "Propose 2-3 approaches" -> "Present design sections";
+    "Present design sections" -> "User approves design?";
+    "User approves design?" -> "Present design sections" [label="no, revise"];
+    "User approves design?" -> "Write design doc" [label="yes"];
+    "Write design doc" -> "Invoke writing-plans skill";
+}
+```
+
+**The terminal state is invoking writing-plans.** Do NOT invoke frontend-design, mcp-builder, or any other implementation skill. The ONLY skill you invoke after brainstorming is writing-plans.
+
+## The Process
+
+**Understanding the idea:**
+- Check out the current project state first (files, docs, recent commits)
+- Ask questions one at a time to refine the idea
+- Prefer multiple choice questions when possible, but open-ended is fine too
+- Only one question per message - if a topic needs more exploration, break it into multiple questions
+- Focus on understanding: purpose, constraints, success criteria
+
+**Exploring approaches:**
+- Propose 2-3 different approaches with trade-offs
+- Present options conversationally with your recommendation and reasoning
+- Lead with your recommended option and explain why
+
+**Presenting the design:**
+- Once you believe you understand what you're building, present the design
+- Scale each section to its complexity: a few sentences if straightforward, up to 200-300 words if nuanced
+- Ask after each section whether it looks right so far
+- Cover: architecture, components, data flow, error handling, testing
+- Be ready to go back and clarify if something doesn't make sense
+
+## After the Design
+
+**Documentation:**
+- Write the validated design to `docs/plans/YYYY-MM-DD-<topic>-design.md`
+- Use elements-of-style:writing-clearly-and-concisely skill if available
+- Commit the design document to git
+
+**Implementation:**
+- Invoke the writing-plans skill to create a detailed implementation plan
+- Do NOT invoke any other skill. writing-plans is the next step.
+
+## Key Principles
+
+- **One question at a time** - Don't overwhelm with multiple questions
+- **Multiple choice preferred** - Easier to answer than open-ended when possible
+- **YAGNI ruthlessly** - Remove unnecessary features from all designs
+- **Explore alternatives** - Always propose 2-3 approaches before settling
+- **Incremental validation** - Present design, get approval before moving on
+- **Be flexible** - Go back and clarify when something doesn't make sense

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

@@ -0,0 +1,180 @@
+---
+name: dispatching-parallel-agents
+description: Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies
+---
+
+# Dispatching Parallel Agents
+
+## Overview
+
+When you have multiple unrelated failures (different test files, different subsystems, different bugs), investigating them sequentially wastes time. Each investigation is independent and can happen in parallel.
+
+**Core principle:** Dispatch one agent per independent problem domain. Let them work concurrently.
+
+## When to Use
+
+```dot
+digraph when_to_use {
+    "Multiple failures?" [shape=diamond];
+    "Are they independent?" [shape=diamond];
+    "Single agent investigates all" [shape=box];
+    "One agent per problem domain" [shape=box];
+    "Can they work in parallel?" [shape=diamond];
+    "Sequential agents" [shape=box];
+    "Parallel dispatch" [shape=box];
+
+    "Multiple failures?" -> "Are they independent?" [label="yes"];
+    "Are they independent?" -> "Single agent investigates all" [label="no - related"];
+    "Are they independent?" -> "Can they work in parallel?" [label="yes"];
+    "Can they work in parallel?" -> "Parallel dispatch" [label="yes"];
+    "Can they work in parallel?" -> "Sequential agents" [label="no - shared state"];
+}
+```
+
+**Use when:**
+- 3+ test files failing with different root causes
+- Multiple subsystems broken independently
+- Each problem can be understood without context from others
+- No shared state between investigations
+
+**Don't use when:**
+- Failures are related (fix one might fix others)
+- Need to understand full system state
+- Agents would interfere with each other
+
+## The Pattern
+
+### 1. Identify Independent Domains
+
+Group failures by what's broken:
+- File A tests: Tool approval flow
+- File B tests: Batch completion behavior
+- File C tests: Abort functionality
+
+Each domain is independent - fixing tool approval doesn't affect abort tests.
+
+### 2. Create Focused Agent Tasks
+
+Each agent gets:
+- **Specific scope:** One test file or subsystem
+- **Clear goal:** Make these tests pass
+- **Constraints:** Don't change other code
+- **Expected output:** Summary of what you found and fixed
+
+### 3. Dispatch in Parallel
+
+```typescript
+// In Claude Code / AI environment
+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")
+// All three run concurrently
+```
+
+### 4. Review and Integrate
+
+When agents return:
+- Read each summary
+- Verify fixes don't conflict
+- Run full test suite
+- Integrate all changes
+
+## Agent Prompt Structure
+
+Good agent prompts are:
+1. **Focused** - One clear problem domain
+2. **Self-contained** - All context needed to understand the problem
+3. **Specific about output** - What should the agent return?
+
+```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 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
+   - Fixing bugs in abort implementation if found
+   - Adjusting test expectations if testing changed behavior
+
+Do NOT just increase timeouts - find the real issue.
+
+Return: Summary of what you found and what you fixed.
+```
+
+## Common Mistakes
+
+**❌ Too broad:** "Fix all the tests" - agent gets lost
+**✅ Specific:** "Fix agent-tool-abort.test.ts" - focused scope
+
+**❌ No context:** "Fix the race condition" - agent doesn't know where
+**✅ Context:** Paste the error messages and test names
+
+**❌ No constraints:** Agent might refactor everything
+**✅ Constraints:** "Do NOT change production code" or "Fix tests only"
+
+**❌ Vague output:** "Fix it" - you don't know what changed
+**✅ Specific:** "Return summary of root cause and changes"
+
+## When NOT to Use
+
+**Related failures:** Fixing one might fix others - investigate together first
+**Need full context:** Understanding requires seeing entire system
+**Exploratory debugging:** You don't know what's broken yet
+**Shared state:** Agents would interfere (editing same files, using same resources)
+
+## Real Example from Session
+
+**Scenario:** 6 test failures across 3 files after major refactoring
+
+**Failures:**
+- agent-tool-abort.test.ts: 3 failures (timing issues)
+- batch-completion-behavior.test.ts: 2 failures (tools not executing)
+- tool-approval-race-conditions.test.ts: 1 failure (execution count = 0)
+
+**Decision:** Independent domains - abort logic separate from batch completion separate from race conditions
+
+**Dispatch:**
+```
+Agent 1 → Fix agent-tool-abort.test.ts
+Agent 2 → Fix batch-completion-behavior.test.ts
+Agent 3 → Fix tool-approval-race-conditions.test.ts
+```
+
+**Results:**
+- Agent 1: Replaced timeouts with event-based waiting
+- Agent 2: Fixed event structure bug (threadId in wrong place)
+- Agent 3: Added wait for async tool execution to complete
+
+**Integration:** All fixes independent, no conflicts, full suite green
+
+**Time saved:** 3 problems solved in parallel vs sequentially
+
+## Key Benefits
+
+1. **Parallelization** - Multiple investigations happen simultaneously
+2. **Focus** - Each agent has narrow scope, less context to track
+3. **Independence** - Agents don't interfere with each other
+4. **Speed** - 3 problems solved in time of 1
+
+## Verification
+
+After agents return:
+1. **Review each summary** - Understand what changed
+2. **Check for conflicts** - Did agents edit same code?
+3. **Run full suite** - Verify all fixes work together
+4. **Spot check** - Agents can make systematic errors
+
+## Real-World Impact
+
+From debugging session (2025-10-03):
+- 6 failures across 3 files
+- 3 agents dispatched in parallel
+- All investigations completed concurrently
+- All fixes integrated successfully
+- Zero conflicts between agent changes