opencodekit 0.18.4 → 0.18.6

package/dist/template/.opencode/skill/memory-system/SKILL.md

@@ -1,300 +1,84 @@
 ---
 name: memory-system
 description: Use when persisting learnings, loading previous context, or searching past decisions - covers memory file structure, tools, and when to update each file
-version: 1.0.0
+version: 1.1.0
 tags: [context, workflow]
 dependencies: []
 ---
 
 # Memory System Best Practices
 
+> **Replaces** losing context between sessions — persistent knowledge that survives session boundaries
+
 ## When to Use
 
-- Starting work and needing to recall prior decisions, bugs, or patterns
-- Recording non-obvious learnings or decisions for future sessions
+- Starting work and needing prior decisions, bugfixes, or patterns
+- Recording non-obvious decisions/learnings for future sessions
+- Creating handoffs so the next session can continue quickly
 
 ## When NOT to Use
 
-- For ephemeral notes that won't matter beyond the current session
-- When you need to change actual markdown files (use read/write), not SQLite memory entries
-
-
-## Architecture
-
-```
-message.part.updated → capture.ts → temporal_messages
-                                        ↓ (session.idle, 10+ messages)
-                                     distill.ts → distillations (TF-IDF + key sentences)
-                                        ↓ (session.idle)
-                                     curator.ts → observations (pattern-matched)
-                                        ↓
-system.transform ← inject.ts ← FTS5 search → scored + packed → system prompt
-messages.transform ← context.ts → token budget enforcement
-```
-
-### 4 Tiers
-
-| Tier              | Storage       | Populated By        | Purpose                         |
-| ----------------- | ------------- | ------------------- | ------------------------------- |
-| temporal_messages | SQLite        | Automatic (capture) | Raw message text, 180-day TTL   |
-| distillations     | SQLite + FTS5 | Automatic (idle)    | TF-IDF compressed sessions      |
-| observations      | SQLite + FTS5 | Manual + curator    | Decisions, bugs, patterns, etc. |
-| memory_files      | SQLite        | Manual              | Static docs, handoffs, research |
+- Ephemeral debugging notes that won't matter after the current task
+- Storing generated artifacts/log dumps as long-term memory
 
 ## Core Principle
 
-**Progressive disclosure** — search compactly, fetch fully, timeline chronologically. Never load all memory at once.
-
----
-
-## The Ritual
-
-Follow this every session. Memory is not optional — it's how knowledge compounds.
-
-### 1. Ground — Search Before You Start
-
-Always search memory first.
-
-```typescript
-// Search for relevant past work
-memory - search({ query: "<task keywords>", limit: 5 });
-memory - search({ query: "bugfix <component>", type: "observations" });
-
-// Check recent handoffs
-memory - search({ query: "handoff", type: "handoffs", limit: 3 });
-```
-
-**Why:** Past you already solved this. Don't rediscover.
-
-### 2. Calibrate — Progressive Disclosure
-
-Don't fetch full content until you know you need it.
-
-```typescript
-// 1. Search returns compact index (50-100 tokens per result)
-const results = memory - search({ query: "auth patterns" });
-// Returns: [{id: 42, title: "Auth bug fixed", ...}]
-
-// 2. Fetch full details ONLY for relevant IDs
-memory - get({ ids: "42,45" });
-
-// 3. See what led to this decision
-memory - timeline({ anchor_id: 42, depth_before: 3 });
-```
-
-**Why:** Prevents context bloat. High signal, low noise.
-
-### 3. Transform — Record Discoveries
-
-Create observations for anything non-obvious. Don't wait until the end.
-
-```typescript
-observation({
-  type: "pattern", // decision | bugfix | pattern | discovery | warning | learning
-  title: "Brief description",
-  narrative: "Context and reasoning...",
-  facts: "key, facts, here",
-  concepts: "searchable, keywords",
-  files_modified: "src/file.ts",
-  source: "manual", // manual (default) | curator | imported
-});
-```
-
-| Type        | Use When                   | Example                            |
-| ----------- | -------------------------- | ---------------------------------- |
-| `decision`  | Architectural choice made  | "Use zod over yup"                 |
-| `bugfix`    | Root cause found & fixed   | "Race condition in async init"     |
-| `pattern`   | Reusable code pattern      | "Repository with error boundaries" |
-| `discovery` | New capability learned     | "Bun.test supports mocking"        |
-| `warning`   | Dangerous pattern to avoid | "Don't use fs.watch in Docker"     |
-| `learning`  | General insight            | "Always validate at boundary"      |
-
-### 4. Reset — Handoff for Next Session
-
-Document completion state for future you.
-
-```typescript
-memory -
-  update({
-    file: "handoffs/YYYY-MM-DD-task",
-    content: `## Completed
-- X
-
-## Blockers
-- Y
-
-## Next
-- Z`,
-    mode: "append",
-  });
-```
-
----
-
-## Memory Tools Reference
-
-### memory-search (Start Here)
+**Progressive disclosure**: search compactly, fetch fully only when relevant, then record high-signal observations.
 
-Fast FTS5 full-text search with porter stemming. Returns **compact index** for progressive disclosure.
+## Session Workflow
 
-```typescript
-memory - search({ query: "authentication" });
-memory - search({ query: "bugfix", type: "observations", limit: 5 });
-memory - search({ query: "session", type: "handoffs" });
-memory - search({ query: "patterns", type: "all" }); // Search everything
-```
-
-**Search modes:**
-
-- `observations` (default): Search SQLite with FTS5 BM25 ranking
-- `handoffs`, `research`, `templates`: Search specific directories
-- `beads`: Search .beads/artifacts
-- `all`: Search everything
-
-### memory-get (Progressive Disclosure)
-
-Fetch full observation details after identifying relevant IDs:
-
-```typescript
-memory - get({ ids: "42" }); // Single observation
-memory - get({ ids: "1,5,10" }); // Multiple observations
-```
-
-### memory-timeline (Chronological Context)
-
-See what happened before/after a specific observation:
-
-```typescript
-memory - timeline({ anchor_id: 42, depth_before: 5, depth_after: 5 });
-```
-
-### memory-read (Files)
-
-Load project files, handoffs, or templates:
-
-```typescript
-memory - read({ file: "project/gotchas" });
-memory - read({ file: "handoffs/2024-01-20-phase-1" });
-memory - read({ file: "research/auth-patterns" });
-```
-
-### memory-update (Files)
-
-Save to project files or handoffs:
-
-```typescript
-memory -
-  update({
-    file: "project/gotchas",
-    content: "### New Gotcha\n\nDescription...",
-    mode: "append", // or "replace"
-  });
-```
-
-### memory-admin (Maintenance)
-
-```typescript
-// Check current status (schema, FTS5, counts, DB size)
-memory - admin({ operation: "status" });
-
-// Full maintenance (archive >90 days, checkpoint WAL, vacuum)
-memory - admin({ operation: "full" });
-
-// Preview what would be archived
-memory - admin({ operation: "archive", older_than_days: 60, dry_run: true });
-
-// Capture pipeline stats (temporal messages, distillations, compression)
-memory - admin({ operation: "capture-stats" });
-
-// Force distillation for current session
-memory - admin({ operation: "distill-now" });
-
-// Force curator run (extract observations from distillations)
-memory - admin({ operation: "curate-now" });
-```
-
-**Automatic:** On session idle — distillation, curation, FTS5 optimize, WAL checkpoint.
-
-**Manual:** Run `memory-admin({ operation: "status" })` to check health.
-
----
+1. **Ground (search first)**
+   - Run `memory-search` with task keywords before implementation.
+   - Check recent handoffs when resuming interrupted work.
+2. **Calibrate (progressive disclosure)**
+   - Use search results as index.
+   - Fetch full entries only for relevant IDs (`memory-get`).
+   - Pull timeline context only when sequencing matters (`memory-timeline`).
+3. **Record (high-signal only)**
+   - Create `observation` for decisions, bugfixes, patterns, warnings, or durable learnings.
+   - Include searchable concepts and concrete file references.
+4. **Handoff (if session boundary)**
+   - Write a concise status note with completed work, blockers, and next steps using `memory-update` under `handoffs/`.
 
 ## What Goes Where
 
-### SQLite (observations)
+| Store | Put Here | Avoid Here |
+| --- | --- | --- |
+| `observation` (SQLite) | Events: decisions, bugfixes, reusable patterns, warnings | Temporary notes, speculative ideas without evidence |
+| `memory-update` files | Durable docs: handoffs, research, project notes | Every minor runtime detail from a single debug run |
+| Auto pipeline | Captured messages + distillations (automatic) | Manual copying of full transcripts |
 
-- Events: decisions, bugfixes, patterns discovered
-- Searchable via FTS5 with porter stemming
-- Created manually via `observation()` or automatically by curator
-- Use `observation()` to create
+## Observation Quality Bar
 
-### SQLite (distillations — automatic)
+Use this checklist before creating an observation:
 
-- Compressed session summaries with TF-IDF terms
-- Created automatically when 10+ messages accumulate
-- Searchable via FTS5
-- Used for relevance-scored LTM injection
+- Is it likely useful in a future session?
+- Is it non-obvious (not already in code/comments)?
+- Can I summarize it in one clear title + short narrative?
+- Did I include strong search terms in `concepts` and relevant files?
 
-### Markdown Files
+If most answers are "no", skip creating the observation.
 
-- Static knowledge: user preferences, tech stack
-- Handoffs: session summaries
-- Research: deep-dive documents
-- Use `memory-read()` / `memory-update()`
+## Anti-Patterns
 
-| Location                   | Content                    | Tool                                |
-| -------------------------- | -------------------------- | ----------------------------------- |
-| `project/user.md`          | User identity, preferences | `memory-read()`                     |
-| `project/tech-stack.md`    | Frameworks, constraints    | `memory-read()`                     |
-| `project/gotchas.md`       | Footguns, warnings         | `memory-update({ mode: "append" })` |
-| `handoffs/YYYY-MM-DD-*.md` | Session summaries          | `memory-update()`                   |
-| `research/*.md`            | Deep-dive analysis         | `memory-update()`                   |
-| SQLite observations        | Events, decisions          | `observation()`                     |
-| SQLite distillations       | Session summaries          | Automatic (idle) or `distill-now`   |
-| SQLite temporal_messages   | Raw captured text          | Automatic (message events)          |
+| Anti-Pattern | Why It Fails | Instead |
+| --- | --- | --- |
+| Storing transient debugging info as permanent observations | Pollutes search results with low-value noise | Keep transient info in session context; record only durable findings |
+| Creating observations for every small finding (signal-to-noise) | Important items get buried and retrieval quality drops | Batch minor notes; publish one distilled observation per meaningful outcome |
+| Not searching memory before creating duplicate observations | Produces conflicting/duplicated records | Run `memory-search` first; update/supersede existing records when appropriate |
+| Using `memory-update` for data that should be an observation | Durable events become hard to discover and rank | Use `observation` for events; reserve `memory-update` for document-style files |
 
----
-
-## Observations Schema
-
-```typescript
-observation({
-  type: "decision", // decision, bugfix, pattern, discovery, warning, learning
-  title: "Use JWT auth",
-  narrative: "Decided to use JWT because it's stateless...",
-  facts: "stateless, scalable, industry standard",
-  concepts: "auth, jwt, security",
-  confidence: "high", // high, medium, low
-  files_read: "src/auth.ts, src/middleware.ts",
-  files_modified: "src/auth.ts",
-  bead_id: "br-abc123", // Link to task (optional)
-  source: "manual", // manual (default), curator, imported
-});
-```
-
----
-
-## Anti-Patterns (Don't Do This)
-
-| ❌ Don't                            | ✅ Do Instead                          |
-| ----------------------------------- | -------------------------------------- |
-| Load full memory at session start   | Use progressive disclosure             |
-| Create observations for everything  | Only non-obvious decisions             |
-| Duplicate in files AND observations | Files = static, SQLite = events        |
-| Vague search queries                | Use specific keywords, file paths      |
-| Subagents writing to memory         | Only leader agents create observations |
-| Wait until end to record            | Create observations as you discover    |
-
----
+## Verification
 
-## Philosophy
+After creating an observation: `memory-search` with relevant keywords should find it.
 
-**Memory is not a dumping ground. It's curated signal.**
+## Practical Defaults
 
-- Search before you build
-- Record what you learned
-- Hand off to future you
+- Prefer specific queries over broad ones (`"auth race condition init"` > `"auth"`).
+- For ongoing work, append to one handoff file per task/day instead of many tiny files.
+- Keep observation titles concrete and action-oriented.
 
-> "The body is architecture. The breath is wiring. The rhythm is survival."
+## See Also
 
-Memory is rhythm — it carries knowledge across the silence between sessions.
+- `context-management`
+- `session-management`

package/dist/template/.opencode/skill/mockup-to-code/SKILL.md

@@ -8,6 +8,8 @@ dependencies: []
 
 # Mockup to Code Skill
 
+> **Replaces** manual pixel-by-pixel CSS translation from designs — structured extraction of layout, colors, typography, and components from visual references
+
 ## When to Use
 
 - Converting Figma/Sketch mockups to React/Vue/HTML
@@ -19,6 +21,12 @@ dependencies: []
 
 - No visual reference or mockup to implement.
 
+## Workflow
+
+1. **Analyze** — Use vision agent to extract: layout structure, color palette, typography, spacing, components
+2. **Map** — Match extracted elements to existing design tokens/components in the codebase
+3. **Implement** — Build components using extracted specs, reusing existing tokens where possible
+4. **Verify** — Screenshot the result and compare visually to the original mockup
 
 ## Core Workflow
 
@@ -156,14 +164,21 @@ Requirements:
 - [ ] Uses tokens (no hardcoded values)
 - [ ] Accessible markup
 
+## Anti-Patterns
+
+| Anti-Pattern                                                           | Why It Fails                                                | Instead                                                                 |
+| ---------------------------------------------------------------------- | ----------------------------------------------------------- | ----------------------------------------------------------------------- |
+| Hardcoding colors/sizes instead of using design tokens                 | Creates inconsistency and makes global updates expensive    | Map values to existing tokens first; add new tokens only when truly new |
+| Building from scratch when existing components cover 80% of the design | Reintroduces solved problems and increases maintenance cost | Compose and extend existing components, then patch gaps                 |
+| Pixel-perfect matching without responsive considerations               | Breaks on different viewport sizes and device classes       | Match intent at multiple breakpoints and validate mobile/tablet/desktop |
+| Not extracting reusable components from repeated patterns              | Duplicates code and drifts visual behavior over time        | Promote repeated UI blocks into reusable components with variants       |
+
 ## Storage
 
 Save implementations to `.opencode/memory/design/implementations/`
 
-## Related Skills
+## See Also
 
-| Need              | Skill                 |
-| ----------------- | --------------------- |
-| Aesthetic quality | `frontend-design`     |
-| Accessibility     | `accessibility-audit` |
-| Design tokens     | `design-system-audit` |
+- `frontend-design`
+- `visual-analysis`
+- `accessibility-audit`

package/dist/template/.opencode/skill/receiving-code-review/SKILL.md

@@ -8,6 +8,8 @@ dependencies: []
 
 # Code Review Reception
 
+> **Replaces** blind agreement with reviewer suggestions — requires technical verification and understanding before implementing any feedback
+
 ## When to Use
 
 - You received review feedback and need to evaluate it before implementing
@@ -242,3 +244,9 @@ You understand 1,2,3,6. Unclear on 4,5.
 Verify. Question. Then implement.
 
 No performative agreement. Technical rigor always.
+
+## See Also
+
+- **requesting-code-review** — the complementary skill for dispatching reviews
+- **verification-before-completion** — verification after implementing review feedback
+- **systematic-debugging** — when review feedback reveals a deeper issue

package/dist/template/.opencode/skill/root-cause-tracing/SKILL.md

@@ -8,6 +8,8 @@ dependencies: []
 
 # Root Cause Tracing
 
+> **Replaces** ad-hoc print-statement debugging and "try random fixes until it works" approaches
+
 ## When to Use
 
 - Errors occur deep in a call stack and the immediate failure is just a symptom
@@ -18,6 +20,15 @@ dependencies: []
 - The error is at the entry point and the root cause is obvious
 - You’re doing feature work with no failures to trace
 
+## Anti-Patterns
+
+| Anti-Pattern | Why It Fails | Instead |
+| --- | --- | --- |
+| Fixing symptoms where error appears | Hides origin; bug returns via other paths | Trace backward until original trigger is found |
+| Skipping stack trace analysis | Misses the real caller and bad input source | Read full stack, file paths, and line numbers first |
+| Adding instrumentation without hypothesis | Produces noisy logs and slows investigation | Instrument one boundary at a time to answer a specific question |
+| Guessing the cause without evidence | Leads to random fixes and regressions | Form evidence-backed hypothesis, then test |
+
 ## Overview
 
 Bugs often manifest deep in the call stack (git init in wrong directory, file created in wrong location, database opened with wrong path). Your instinct is to fix where the error appears, but that's treating a symptom.
@@ -175,3 +186,7 @@ From debugging session (2025-10-03):
 - Fixed at source (getter validation)
 - Added 4 layers of defense
 - 1847 tests passed, zero pollution
+
+## See Also
+
+- **systematic-debugging** - Full four-phase process before/after tracing deep stack failures

package/dist/template/.opencode/skill/session-management/SKILL.md

@@ -1,108 +1,9 @@
 ---
-name: session-management
-description: Use when context is growing large, switching tasks, or needing previous session context - covers thresholds, session tools, and workflow patterns
-version: 1.0.0
-tags: [context, workflow]
-dependencies: []
+description: "Merged into context-management. Load that skill instead."
 ---
 
 # Session Management
 
-## When to Use
-
-- Managing context growth, switching tasks, or resuming past sessions.
-
-## When NOT to Use
-
-- Single, short tasks that don't require session transitions.
-
-
-## Context Thresholds
-
-The environment monitors context usage and warns at these thresholds:
-
-| Threshold | Action                                                     |
-| --------- | ---------------------------------------------------------- |
-| **70%**   | Consolidate work; consider pruning irrelevant tool outputs |
-| **85%**   | Summarize findings and consider starting a new session     |
-| **95%**   | Critical: prune context immediately or restart session     |
-
-## Session Tools
-
-### find_sessions
-
-Search and discover sessions by keyword. Returns ranked results with match counts and snippets.
-
-```typescript
-find_sessions({ query: "auth bug", limit: 5 }); // Search by keyword
-find_sessions({ query: "refactor" }); // Default limit
-```
-
-**Parameters:**
-
-- `query` (required): Search keywords — multi-word queries use AND matching
-- `limit` (optional): Max results to return
-
-**Returns:** Ranked sessions with match count, snippets, and suggested next steps.
-
-### read_session
-
-Read messages from a specific session. Supports optional focus filtering.
-
-```typescript
-read_session({ session_id: "ses_abc123" }); // Full session
-read_session({ session_id: "ses_abc123", focus: "auth" }); // Filter to relevant messages
-```
-
-**Parameters:**
-
-- `session_id` (required): Session ID from find_sessions results
-- `focus` (optional): Keyword to filter messages within the session
-
-## When to Start New Session
-
-- Completing distinct task from `br ready`
-- Token usage approaching 150k
-- Switching phases (implementation → review → testing)
-- After handoff (`/handoff <bead-id>`)
-
-## Session Workflow Pattern
-
-```
-Session 1: Implement feature X (80k tokens)
-  ↓ close, update memory
-Session 2: find_sessions({ query: "feature X" }) → read_session(...) → Refactor (60k tokens)
-  ↓
-Session 3: find_sessions({ query: "feature X" }) → Add tests (90k tokens)
-  ↓
-Session 4: read_session(...) → Final review (100k tokens)
-```
-
-**Result**: 4 fresh contexts vs 1 degraded 330k context. Better performance, lower cost.
-
-## Context Transfer
-
-Use all available sources:
-
-1. `find_sessions` + `read_session` — Previous session work
-2. Git state — `git diff`, `git log` — Code changes
-3. Memory files — `.opencode/memory/*` — Persistent context
-4. Beads — `br show <id>` — Task specs
-
-**Don't**: Carry everything forward. Extract what's needed, discard the rest.
-
-## Pruning Strategy
-
-When context grows large:
-
-1. **Discard** completed task outputs (read files you won't edit again)
-2. **Extract** key findings before discarding research
-3. **Summarize** complex investigations into memory files
-4. **Restart** session if above 85% and work is at a natural break
-
-## Anti-Patterns
-
-- ❌ Running until context limit forces restart
-- ❌ Carrying all previous reads forward "just in case"
-- ❌ Not using memory files for cross-session persistence
-- ❌ Re-reading the same files every session instead of extracting key info
+> This skill has been merged into `context-management` which now covers both context and session lifecycle management.
+> 
+> Load `context-management` instead.

package/dist/template/.opencode/skill/subagent-driven-development/SKILL.md

@@ -8,6 +8,8 @@ dependencies: [executing-plans]
 
 # Subagent-Driven Development
 
+> **Replaces** monolithic single-agent implementation sessions that grow stale — dispatches fresh subagents per task with code review gates between them
+
 ## When to Use
 
 - Executing a plan with mostly independent tasks in the same session
@@ -18,8 +20,6 @@ dependencies: [executing-plans]
 - The plan requires review or revisions first (use executing-plans)
 - Tasks are tightly coupled and need manual sequencing
 
-
-
 ## Overview
 
 **vs. Executing Plans (parallel session):**
@@ -189,6 +189,21 @@ Done!
 - Dispatch fix subagent with specific instructions
 - Don't try to fix manually (context pollution)
 
+## Anti-Patterns
+
+| Anti-Pattern | Why It Fails | Instead |
+| --- | --- | --- |
+| Dispatching subagents for tasks with shared state/files | Creates edit conflicts, race conditions, and unclear ownership | Keep shared-state work sequential under one subagent at a time |
+| Skipping code review between subagent tasks | Lets defects accumulate and compounds later fixes | Run a review gate after each task before moving on |
+| Giving subagents vague prompts without file paths or acceptance criteria | Produces off-target changes and repeated back-and-forth | Provide exact file paths, task scope, and acceptance criteria |
+| Not verifying subagent output before moving to next task | Carries regressions forward into later tasks | Validate output immediately before starting the next task |
+
+## Verification
+
+- After each subagent completes: review its changes, run typecheck + lint on modified files
+- After all tasks: run full test suite to catch integration issues
+- Check: no conflicting edits between subagent outputs
+
 ## Integration
 
 **Required workflow skills:**
@@ -207,3 +222,9 @@ Done!
 
 See review template: requesting-code-review/review.md
 ```
+
+## See Also
+
+- **dispatching-parallel-agents** — for parallel investigation
+- **executing-plans** — for batch execution with checkpoints
+- **requesting-code-review** — for review between subagent tasks

package/dist/template/.opencode/skill/swarm-coordination/SKILL.md

@@ -13,6 +13,8 @@ dependencies: [beads-bridge]
 
 # Swarm Coordination - Kimi K2.5 PARL Multi-Agent Execution
 
+> **Replaces** manual task-by-task execution of large plans — sequential bottleneck when tasks have no dependencies
+
 ## When to Use
 
 - Implementing plans with 3+ independent tasks that can run in parallel
@@ -23,7 +25,6 @@ dependencies: [beads-bridge]
 - Single-task or tightly sequential work without parallelizable groups
 - Simple 1–2 file changes better handled by a single agent
 
-
 ## Overview
 
 **Swarm = Leader + Workers + Reconciler + Progress Tracking + Todo Persistence**
@@ -150,6 +151,15 @@ SHUTDOWN:
 10. **Use reconciler at scale** - Required for 50+ agents, recommended for 10+
 11. **Reconciler watches continuously** - Spawns fix tasks on detected failures
 
+## Anti-Patterns
+
+| Anti-Pattern                                            | Why It Fails                                               | Instead                                                           |
+| ------------------------------------------------------- | ---------------------------------------------------------- | ----------------------------------------------------------------- |
+| Spawning agents for tasks with shared file dependencies | Workers block or overwrite each other, causing merge churn | Partition work by non-overlapping files/modules first             |
+| Not tracking agent completion status                    | Leader loses visibility; work appears done when it is not  | Require `monitor.progress_update` lifecycle (start/progress/done) |
+| Dispatching without pre-computed dependency graph       | Tasks run out of order, causing rework and serial fallback | Run `swarm plan` first and dispatch by `parallelizable_groups`    |
+| Using swarm for < 3 tasks (overhead not worth it)       | Coordination overhead exceeds execution savings            | Use a single agent or 2 direct `Task()` calls                     |
+
 ## References
 
 - `references/architecture.md` - Swarm architecture diagram
@@ -161,3 +171,9 @@ SHUTDOWN:
 - `references/integration-beads.md` - Swarm integration workflow with Beads
 - `references/tmux-integration.md` - Tmux monitoring setup and commands
 - `references/tier-enforcement.md` - Tier enforcement (Longshot pattern)
+
+## See Also
+
+- `agent-teams` — for coordinated multi-role collaboration beyond large plan execution
+- `dispatching-parallel-agents` — for lightweight parallel debugging of independent failures
+- `executing-plans` — for plan-driven execution when parallelism is moderate or bounded