sisyphi 0.1.2 → 0.1.4

package/dist/templates/orchestrator-plugin/.claude/skills/orchestration/workflow-examples.md

@@ -0,0 +1,208 @@
+# Workflow Examples
+
+End-to-end examples showing how the orchestrator structures cycles for real scenarios.
+
+---
+
+## Example 1: Fix a Race Condition in WebSocket Reconnection
+
+**Starting task**: "WebSocket connections sometimes drop messages during reconnection"
+
+### Cycle 1 — Diagnosis
+```
+Tasks added:
+  t1: Diagnose message loss during WebSocket reconnection
+  t2: Fix root cause
+  t3: Validate fix under concurrent load
+  t4: Review fix
+
+Agents spawned:
+  debug agent → t1: "Diagnose why WebSocket messages are lost during reconnection.
+    Focus on src/ws/client.ts and src/ws/reconnect.ts.
+    Check for race conditions between disconnect handler and message queue.
+    Look at git blame for recent changes to reconnection logic."
+```
+
+### Cycle 2 — Read diagnosis, plan fix
+```
+Agent report: "Root cause: reconnect() clears the message queue before the new socket
+  is ready. Messages sent between disconnect and reconnect are dropped.
+  Line 47 of src/ws/reconnect.ts — queue.clear() is called in onDisconnect
+  but should be deferred until onReconnect confirms the new socket is live.
+  Confidence: High."
+
+Tasks updated:
+  t1: complete
+
+Agents spawned:
+  implement agent → t2: "Fix race condition in src/ws/reconnect.ts.
+    Root cause: queue.clear() at line 47 runs on disconnect, dropping pending messages.
+    Fix: defer queue drain until reconnect confirms new socket. Buffer messages during
+    reconnection window. See existing buffer pattern in src/ws/buffer.ts."
+```
+
+### Cycle 3 — Validate
+```
+Agent report: "Fixed. Moved queue.clear() to onReconnect callback after socket.readyState
+  confirms OPEN. Added message buffer during reconnection window. 2 files changed."
+
+Tasks updated:
+  t2: complete
+
+Agents spawned:
+  validate agent → t3: "Verify WebSocket reconnection fix. Run existing tests in
+    src/__tests__/ws/. Manually verify: disconnect simulation should not lose queued
+    messages. Check that buffer drains correctly on reconnect."
+```
+
+### Cycle 4 — Review and complete
+```
+Validation: PASS. Existing tests pass, reconnection preserves messages.
+
+Tasks updated:
+  t3: complete
+
+Agents spawned:
+  review agent → t4: "Review changes in src/ws/reconnect.ts and src/ws/buffer.ts.
+    Focus on: thread safety of the new buffer, memory leak potential if reconnect
+    never succeeds, edge case of rapid disconnect/reconnect cycles."
+```
+
+### Cycle 5 — Complete
+```
+Review: Clean. One medium finding — buffer should have a max size to prevent
+  memory issues if reconnect fails indefinitely. Not blocking.
+
+Tasks updated:
+  t4: complete
+
+Action: complete — "Fixed WebSocket message loss during reconnection. Messages now
+  buffered during reconnection window and drained on successful reconnect."
+```
+
+---
+
+## Example 2: Add API Rate Limiting
+
+**Starting task**: "Add rate limiting to the REST API — per-user, configurable limits"
+
+### Cycle 1 — Spec
+```
+Tasks added:
+  t1: Draft spec for API rate limiting
+  t2: Plan implementation
+  t3: Review plan
+  t4: Implement rate limiting middleware
+  t5: Implement rate limit configuration
+  t6: Implement rate limit headers and error responses
+  t7: Validate implementation
+  t8: Review implementation
+
+Agents spawned:
+  spec-draft agent → t1: "Investigate codebase and draft spec for per-user API rate
+    limiting. Check existing middleware patterns in src/api/middleware/.
+    Questions to resolve: storage backend (Redis vs in-memory), limit granularity
+    (per-endpoint vs global), response format for rate-limited requests."
+```
+
+### Cycle 2 — Plan (after human reviews spec)
+```
+Agent report: "Spec saved to context/spec-rate-limiting.md.
+  Approach: Redis-backed sliding window. Per-user with endpoint-specific overrides.
+  Standard 429 response with Retry-After header. Config via environment variables.
+  Open questions resolved with user: Redis is already in stack, use it."
+
+Tasks updated:
+  t1: complete
+
+Agents spawned:
+  plan agent → t2: "Create implementation plan from spec at context/spec-rate-limiting.md"
+  test-spec agent → (new task): "Define behavioral properties for rate limiting from spec"
+```
+
+### Cycle 3 — Review plan
+```
+Both agents complete. Plan at context/plan-rate-limiting.md.
+Plan has 3 phases: middleware (t4), config (t5), response format (t6).
+
+Agents spawned:
+  review-plan agent → t3: "Validate plan at context/plan-rate-limiting.md
+    against spec at context/spec-rate-limiting.md"
+```
+
+### Cycle 4 — Implement (phases 1+2 parallel)
+```
+Plan review: PASS.
+
+Tasks updated:
+  t3: complete
+
+Agents spawned:
+  implement agent → t4: "Implement Phase 1 from context/plan-rate-limiting.md —
+    rate limiting middleware in src/api/middleware/rate-limit.ts"
+  implement agent → t5: "Implement Phase 2 from context/plan-rate-limiting.md —
+    rate limit configuration in src/config/rate-limits.ts"
+```
+
+### Cycle 5-7 — Continue phases, validate, review, complete
+
+---
+
+## Example 3: Refactor Authentication Module
+
+**Starting task**: "Refactor auth — extract token logic from route handlers into dedicated service"
+
+### Cycle 1 — Plan + baseline
+```
+Tasks added:
+  t1: Plan auth refactor — extract token service
+  t2: Capture behavioral baseline (run all auth tests)
+  t3: Create TokenService class with extracted logic
+  t4: Update route handlers to use TokenService
+  t5: Update tests to use new service interface
+  t6: Validate all auth tests still pass
+  t7: Review for dead code and missed references
+
+Agents spawned (parallel):
+  plan agent → t1: "Plan refactor: extract token creation, validation, and refresh
+    logic from src/api/routes/auth.ts into a new src/services/token-service.ts.
+    Map all token-related functions, their callers, and the extraction plan."
+  validate agent → t2: "Run all tests in src/__tests__/auth/ and record results.
+    This is the behavioral baseline — these must all pass after refactor."
+```
+
+### Cycle 2 — Extract (serial — must happen before consumer updates)
+```
+Plan complete, baseline captured (47 tests passing).
+
+Agents spawned:
+  implement agent → t3: "Execute Phase 1 of refactor plan: create TokenService class
+    at src/services/token-service.ts. Extract validateToken, createToken, refreshToken
+    from src/api/routes/auth.ts. Export the class. Do NOT modify route handlers yet."
+```
+
+### Cycle 3 — Update consumers (parallel where possible)
+```
+TokenService created.
+
+Agents spawned:
+  implement agent → t4: "Update route handlers in src/api/routes/auth.ts to import
+    and use TokenService instead of inline token logic. Remove extracted functions."
+  implement agent → t5: "Update tests in src/__tests__/auth/ to use TokenService
+    where they directly tested extracted functions."
+```
+
+### Cycle 4 — Validate + review
+```
+Agents spawned (parallel):
+  validate agent → t6: "Run all auth tests. Compare against baseline of 47 passing.
+    Every test must still pass."
+  review agent → t7: "Review src/api/routes/auth.ts and src/services/token-service.ts.
+    Check for: dead code left behind, missed references to old functions, broken imports."
+```
+
+### Cycle 5 — Complete
+```
+All 47 tests passing. Review clean.
+Complete — "Extracted token logic into TokenService. All existing tests pass."
+```

package/dist/templates/orchestrator-plugin/.claude-plugin/plugin.json

@@ -0,0 +1,5 @@
+{
+  "name": "sisyphus-orchestrator",
+  "version": "1.0.0",
+  "description": "Skills and commands for the sisyphus orchestrator"
+}

package/dist/templates/orchestrator-plugin/hooks/hooks.json

@@ -0,0 +1,25 @@
+{
+  "hooks": {
+    "PreToolUse": [
+      {
+        "matcher": "Task",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "\"${CLAUDE_PLUGIN_ROOT}/scripts/block-task.sh\""
+          }
+        ]
+      }
+    ],
+    "Stop": [
+      {
+        "hooks": [
+          {
+            "type": "command",
+            "command": "\"${CLAUDE_PLUGIN_ROOT}/scripts/stop-suggest.sh\""
+          }
+        ]
+      }
+    ]
+  }
+}

package/dist/templates/orchestrator-plugin/scripts/block-task.sh

@@ -0,0 +1,4 @@
+#!/bin/bash
+cat <<'EOF'
+{"decision":"block","reason":"Do not use the Task tool. Use `sisyphus spawn` to spawn agents in tmux panes instead."}
+EOF

package/dist/templates/orchestrator-plugin/scripts/stop-suggest.sh

@@ -0,0 +1,4 @@
+#!/bin/bash
+cat <<'EOF'
+{"decision":"block","reason":"Before stopping, consider: use `sisyphus yield` to end this cycle and let the daemon respawn you with updated state, or use AskUserQuestion if you need clarification from the user."}
+EOF

package/dist/templates/orchestrator-plugin/skills/git-management/SKILL.md

@@ -0,0 +1,111 @@
+---
+name: git-management
+description: >
+  Set up and manage git worktree isolation for parallel agents. How to analyze a project for worktree config, create .sisyphus/worktree.json, handle merge conflicts surfaced by the daemon, and decide when to use --worktree vs not.
+---
+
+# Git Worktree Management
+
+## Setting Up Worktree Config
+
+Analyze the project to determine what gitignored files/directories agents need. Create `.sisyphus/worktree.json`:
+
+### Config Format
+
+```json
+{
+  "copy": [],
+  "clone": [],
+  "symlink": [],
+  "init": ""
+}
+```
+
+**Fields:**
+- `copy` — Files/dirs to copy from main worktree (e.g., `.env`, `.env.local`). Use for small files that may need per-worktree modifications.
+- `clone` — Files/dirs to APFS copy-on-write clone (e.g., `node_modules`, `vendor`, `target`). Near-zero cost on macOS. Falls back to regular copy on other systems. Use for large directories.
+- `symlink` — Files/dirs to symlink from main worktree. Use for things that should stay in sync across all worktrees.
+- `init` — Shell command to run after worktree setup (e.g., `npm install`, `pip install -e .`, `cargo build`). Runs with cwd set to the worktree. Failures are logged but don't block agent startup.
+
+**Note:** `.sisyphus` and `.claude` directories are ALWAYS symlinked automatically — you don't need to include them.
+
+### Analysis Checklist
+
+Scan the project root for gitignored files that agents will need:
+
+1. **Environment files**: `.env`, `.env.local`, `.env.development` — usually `copy` (agents may need different ports)
+2. **Dependencies**: `node_modules`, `vendor`, `target`, `.venv`, `__pycache__` — use `clone` for large dirs
+3. **Build artifacts**: `dist`, `.next`, `build`, `.turbo` — usually `clone` for warm cache, or skip and let `init` rebuild
+4. **Tool config**: `.eslintcache`, `.pretterircache`, `.tsbuildinfo` — usually skip, tools regenerate
+5. **Other dotfiles**: Check what exists at root. Err on the side of including too much rather than too little.
+
+### Example Configs
+
+**Node.js (npm/yarn):**
+```json
+{
+  "copy": [".env", ".env.local"],
+  "clone": ["node_modules"],
+  "init": "npm install --prefer-offline"
+}
+```
+
+**Node.js (pnpm):**
+```json
+{
+  "copy": [".env"],
+  "clone": [],
+  "init": "pnpm install --frozen-lockfile"
+}
+```
+
+**Python:**
+```json
+{
+  "copy": [".env"],
+  "clone": [".venv"],
+  "init": "source .venv/bin/activate && pip install -e ."
+}
+```
+
+**Rust:**
+```json
+{
+  "clone": ["target"],
+  "init": "cargo build"
+}
+```
+
+**No dependencies (simple project):**
+```json
+{
+  "copy": [".env"]
+}
+```
+
+## Handling Merge Conflicts
+
+When the daemon merges agent branches back, conflicts appear in the `## Worktrees` section of your state block. For each conflicting agent you'll see:
+- The branch name (still exists, unmerged)
+- The worktree path (still exists on disk)
+- The conflict details (git merge stderr output)
+
+**Resolution approaches:**
+1. **Spawn a resolution agent** in the conflicting worktree to manually resolve and commit
+2. **Rebase the branch** onto current HEAD and resolve conflicts
+3. **Cherry-pick specific commits** instead of merging the whole branch
+4. **Discard the branch** if the work can be redone more cleanly
+
+After resolution, the branch can be merged manually or left for the next cycle's automatic merge attempt.
+
+## When to Use Worktrees
+
+**Use `--worktree`** when:
+- Multiple agents will work on different features that touch overlapping files
+- Agents need to make structural changes (renames, moves, deletes)
+- The task involves feature branches that should be independently testable
+
+**Skip `--worktree`** when:
+- Agents work on completely separate files with no overlap
+- Quick fixes or single-file changes
+- Agents only read code (exploration, review)

package/dist/templates/orchestrator-plugin/skills/orchestration/SKILL.md

@@ -0,0 +1,40 @@
+---
+name: orchestration
+description: >
+  Task breakdown patterns for sisyphus orchestrator sessions. How to structure tasks, sequence agents, and manage cycles for debugging, feature builds, refactors, and other common workflows. Use when planning orchestration strategy or structuring a multi-agent session.
+---
+
+# Orchestration Patterns
+
+How to structure sisyphus sessions for common task types. This skill helps the orchestrator break work into tasks, choose agent types, sequence cycles, and handle failures.
+
+## Core Principles
+
+1. **plan.md is the orchestrator's memory.** plan.md and agent reports persist across cycles — they're all you have. Keep plan.md current and specific enough that a fresh orchestrator can pick up where you left off.
+
+2. **Agents are disposable.** Each agent gets one focused instruction. If it fails or the scope changes, spawn a new one — don't try to redirect a running agent.
+
+3. **Parallelize when independent.** If two tasks don't share files or depend on each other's output, spawn agents for both in the same cycle.
+
+4. **Validate at boundaries.** After each logical phase completes, spawn a validation agent before moving on. Catching problems early prevents cascading rework.
+
+5. **Reports are handoffs.** Agent reports should contain everything the next cycle's orchestrator needs — what was done, what was found, what's unresolved, where artifacts were saved.
+
+## Agent Types Quick Reference
+
+| Agent | Model | Use For |
+|-------|-------|---------|
+| `sisyphus:general` | sonnet | Ad-hoc tasks, summarization, simple questions |
+| `sisyphus:debug` | opus | Bug diagnosis and root cause analysis |
+| `sisyphus:spec-draft` | opus | Feature investigation and spec drafting |
+| `sisyphus:plan` | opus | Implementation planning from spec |
+| `sisyphus:review-plan` | opus | Validate plan covers spec completely |
+| `sisyphus:test-spec` | opus | Define behavioral properties to verify |
+| `sisyphus:implement` | sonnet | Execute plan phases, write code |
+| `sisyphus:validate` | opus | Verify implementation matches plan |
+| `sisyphus:review` | opus | Code review with parallel concern subagents |
+| `sisyphus:tactician` | opus | Track plan progress, dispatch next task |
+| `sisyphus:triage` | sonnet | Classify tickets by type/size |
+
+For task breakdown patterns per workflow type, see [task-patterns.md](task-patterns.md).
+For end-to-end workflow examples, see [workflow-examples.md](workflow-examples.md).

package/dist/templates/orchestrator-plugin/skills/orchestration/task-patterns.md

@@ -0,0 +1,248 @@
+# Work Breakdown Patterns
+
+Patterns for how the orchestrator should structure plan.md for common workflow types. Each pattern shows the plan structure, agent assignments, cycle sequencing, and failure handling.
+
+---
+
+## Bug Fix
+
+### When to use
+Something is broken. User reports a bug, test is failing, behavior is wrong.
+
+### Plan structure
+```
+## Bug Fix: [description]
+
+- [ ] Diagnose root cause of [bug description]
+- [ ] Implement fix for [root cause]
+- [ ] Validate fix — regression tests pass, bug is resolved
+- [ ] Review fix for unintended side effects
+```
+
+### Cycle plan
+- **Cycle 1**: Spawn `sisyphus:debug` for diagnosis. Yield.
+- **Cycle 2**: Read diagnosis report. If confident root cause found, spawn `sisyphus:implement` for fix with the diagnosis as context. Yield.
+- **Cycle 3**: Spawn `sisyphus:validate` for validation. Yield.
+- **Cycle 4**: If validation passes, spawn `sisyphus:review` for review. If fails, update plan with failure context and respawn implement. Yield.
+- **Cycle 5**: Review results. Complete or address review findings.
+
+### Failure modes
+- **Debug inconclusive**: Add more context to plan, respawn debug with narrower scope or different focus areas.
+- **Fix breaks other things**: Validation catches this. Feed validation failures back into a new implement cycle.
+- **Root cause was wrong**: Update plan with what was learned, respawn debug.
+
+### Parallelization
+Usually serial — diagnosis must complete before fix, fix before validation. Exception: if the bug affects multiple independent areas, spawn multiple debug agents in parallel.
+
+---
+
+## Feature Build (Small — 1-3 files)
+
+### When to use
+Clear requirements, small scope, no spec needed.
+
+### Plan structure
+```
+## Feature: [description]
+
+- [ ] Plan implementation for [feature]
+- [ ] Implement [feature]
+- [ ] Validate implementation
+```
+
+### Cycle plan
+- **Cycle 1**: Spawn `sisyphus:plan` for planning. Yield.
+- **Cycle 2**: Spawn `sisyphus:implement` with plan path. Yield.
+- **Cycle 3**: Spawn `sisyphus:validate` for validation. Yield.
+- **Cycle 4**: Complete or fix issues.
+
+### Parallelization
+Serial. Too small to benefit from parallel agents.
+
+---
+
+## Feature Build (Medium — 4-10 files)
+
+### When to use
+Feature with moderate complexity. Requirements may need clarification. Multiple files across a few modules.
+
+### Plan structure
+```
+## Feature: [description]
+
+### Spec & Planning
+- [ ] Draft spec — investigate codebase, propose approach
+- [ ] Create implementation plan from spec
+- [ ] Review plan against spec
+
+### Implementation
+- [ ] Phase 1 — [foundation/types/interfaces]
+- [ ] Phase 2 — [core logic]
+- [ ] Phase 3 — [integration/wiring]
+
+### Validation
+- [ ] Validate full implementation
+- [ ] Review implementation
+```
+
+### Cycle plan
+- **Cycle 1**: Spawn `sisyphus:spec-draft` for spec. Yield. (Human iterates on spec between cycles.)
+- **Cycle 2**: Spawn `sisyphus:plan` for plan. Yield.
+- **Cycle 3**: Spawn `sisyphus:review-plan` for review. If fail, respawn plan with issues. Yield.
+- **Cycle 4**: Spawn `sisyphus:implement` for Phase 1. Yield.
+- **Cycle 5**: Spawn `sisyphus:implement` for Phase 2 + `sisyphus:validate` for Phase 1 (parallel if independent). Yield.
+- **Cycle 6-8**: Continue phases, validate, review.
+
+### Failure modes
+- **Spec needs human input**: Mark session as needing human review. Orchestrator notes open questions.
+- **Plan fails review**: Feed review issues back, respawn planner.
+- **Phase fails validation**: Feed specifics back to implement agent for that phase only.
+
+### Parallelization
+Phases without dependencies can run in parallel. Types/interfaces (Phase 1) must complete before implementation phases that consume them.
+
+---
+
+## Feature Build (Large — 10+ files)
+
+### When to use
+Cross-cutting feature, multiple domains, needs team coordination.
+
+### Plan structure
+```
+## Feature: [description]
+
+### Spec & Planning
+- [ ] Draft spec
+- [ ] Create master implementation plan
+- [ ] Review plan against spec
+- [ ] Define behavioral test properties
+
+### Implementation
+- [ ] Phase 1 — [domain A foundation]
+- [ ] Phase 2 — [domain B foundation]
+- [ ] Phase 3 — [domain A implementation]
+- [ ] Phase 4 — [domain B implementation]
+- [ ] Phase 5 — [integration layer]
+
+### Validation
+- [ ] Validate full implementation
+- [ ] Review implementation
+- [ ] Adversarial validation against test spec
+```
+
+### Cycle plan
+- **Cycle 1**: Spawn `sisyphus:spec-draft` for spec. Yield.
+- **Cycle 2**: Spawn `sisyphus:plan` for plan + `sisyphus:test-spec` for test properties (parallel). Yield.
+- **Cycle 3**: Spawn `sisyphus:review-plan` for review. Yield.
+- **Cycle 4**: Spawn `sisyphus:implement` for Phase 1 + Phase 2 (parallel — independent domains). Yield.
+- **Cycle 5**: Validate Phase 1 + Phase 2, then spawn Phase 3 + Phase 4 (parallel). Yield.
+- **Cycle 6+**: Integration, validation, review.
+
+### Failure modes
+- **Integration failures**: Often means contracts between domains don't match. Spawn debug agent targeting the integration seam.
+- **Test spec violations**: Feed specific property failures back to implement.
+
+### Parallelization
+Maximize. Independent domains run in parallel. Foundation phases complete before implementation phases in the same domain. Integration waits for all domain implementations.
+
+---
+
+## Refactor
+
+### When to use
+Restructure code without changing behavior. Move files, rename abstractions, consolidate patterns.
+
+### Plan structure
+```
+## Refactor: [description]
+
+- [ ] Analyze current structure and plan refactor
+- [ ] Capture behavioral snapshot (existing tests + manual checks)
+- [ ] Execute refactor phase 1 — [structural changes]
+- [ ] Execute refactor phase 2 — [update consumers]
+- [ ] Validate behavior preserved — all original tests pass
+- [ ] Review for missed references, dead code, broken imports
+```
+
+### Cycle plan
+- **Cycle 1**: Spawn `sisyphus:plan` for analysis + `sisyphus:validate` to capture baseline (parallel). Yield.
+- **Cycle 2**: Spawn `sisyphus:implement` for phase 1. Yield.
+- **Cycle 3**: Spawn `sisyphus:implement` for phase 2 + `sisyphus:validate` for phase 1 (parallel). Yield.
+- **Cycle 4**: Spawn `sisyphus:validate` for full validation. Yield.
+- **Cycle 5**: Spawn `sisyphus:review` for final review. Complete.
+
+### Key principle
+**Behavior preservation is the only metric.** The refactor is correct if and only if all existing tests pass and externally observable behavior is unchanged.
+
+### Parallelization
+Limited. Refactor phases are often sequential (move before update consumers). Validation can run in parallel with the next phase if they touch different files.
+
+---
+
+## Code Review
+
+### When to use
+PR review, pre-merge check, or periodic quality audit.
+
+### Plan structure
+```
+## Review: [scope]
+
+- [ ] Review [scope] for issues
+- [ ] (conditional) Fix critical/high issues found
+- [ ] (conditional) Re-review fixes
+```
+
+### Cycle plan
+- **Cycle 1**: Spawn `sisyphus:review` for review. Yield.
+- **Cycle 2**: If critical/high issues, spawn `sisyphus:implement` for fixes. If clean, complete.
+- **Cycle 3**: Spawn `sisyphus:review` for re-review (targeted at fixes only). Complete.
+
+### Parallelization
+Review itself parallelizes internally (subagents per concern). Fix cycle is usually serial.
+
+---
+
+## Investigation / Spike
+
+### When to use
+Need to understand something before committing to an approach. Prototype, explore, or answer a technical question.
+
+### Plan structure
+```
+## Investigation: [question/area]
+
+- [ ] Investigate [question/area]
+- [ ] Summarize findings and recommendation
+```
+
+### Cycle plan
+- **Cycle 1**: Spawn `sisyphus:debug` (for code investigation) or `sisyphus:general` (for broader research). Yield.
+- **Cycle 2**: Spawn `sisyphus:general` to synthesize findings. Complete.
+
+### Parallelization
+If investigating multiple independent areas, spawn parallel agents each exploring a different angle.
+
+---
+
+## Tactician-Driven Implementation
+
+### When to use
+The plan exists and you want automated cycle-by-cycle execution without manual orchestrator decisions. The tactician reads the plan, dispatches one phase at a time, and tracks progress.
+
+### Plan structure
+```
+## Tactician Execution
+
+- [ ] Execute implementation plan at [path] using tactician loop
+```
+
+### Cycle plan
+This is a single-item pattern. The orchestrator spawns the tactician once:
+- **Cycle 1**: Spawn `sisyphus:tactician` with plan path. The tactician internally dispatches implement/validate agents via submit tool actions. The orchestrator's role is minimal — just monitor the tactician's completion report.
+
+### When NOT to use
+- When you need human checkpoints between phases
+- When phases have external dependencies (waiting on API access, design review, etc.)
+- When the task requires creative decisions the tactician shouldn't make alone