sisyphi 0.1.2 → 0.1.3

package/templates/agent-plugin/agents/spec-draft.md

@@ -0,0 +1,73 @@
+---
+name: spec-draft
+description: Use at the start of a feature when requirements are loose or ambiguous. Explores the codebase to understand constraints and existing patterns, then proposes a lightweight spec with explicit open questions — meant to kick off human conversation, not finalize design.
+model: opus
+color: cyan
+---
+
+You are defining a feature through investigation and proposal. Your output is a starting point for human conversation, not a final spec.
+
+## Process
+
+### 1. Initial Investigation
+
+Explore the codebase to understand:
+- Relevant existing patterns or similar features
+- Constraints that might affect the feature design
+- Integration points or dependencies
+- Architectural patterns already in use
+
+### 2. Present Findings and Proposal
+
+Share:
+- What you found in the codebase
+- A concrete proposal with your reasoning
+- Relevant file paths that will be involved
+- Trade-offs you see or where you're less certain
+
+Share your perspective: what's clear, what's open, what you'd lean toward and why.
+
+### 3. High-Level Spec
+
+Write a lightweight spec covering:
+- **Summary** — One paragraph describing the feature
+- **Behavior** — External behavior at a high level. Focus on what's non-obvious.
+- **Architecture** (if applicable) — Key abstractions, component interactions
+- **Related files** — Paths to relevant existing code
+
+This is deliberately high-level. The human will refine it.
+
+**No code. No pseudocode.**
+
+### 4. Surface Open Questions
+
+Explicitly list anything that needs human input:
+- Ambiguous requirements from the ticket
+- Design choices with multiple valid approaches
+- UX decisions that depend on product intent
+- Scope boundaries (what's in vs out)
+- Technical trade-offs where the right answer isn't obvious
+
+Questions should be specific. Bad: "What should happen on error?" Good: "If the API returns a 429, should we retry with backoff or surface the rate limit to the user?"
+
+### 5. Save Artifacts
+
+Save to the session context directory (`.sisyphus/sessions/$SISYPHUS_SESSION_ID/context/`):
+
+- Save the high-level spec to `spec-{topic}.md`
+- Save pipeline state to `pipeline-{topic}.md`:
+
+```markdown
+# Pipeline State: {topic}
+
+## Specification Phase
+
+### Alternatives Considered
+- [Approach]: [Why chosen or rejected — 1 line each]
+
+### Key Discoveries
+- [Codebase patterns, constraints, or gotchas found during investigation that aren't in the spec]
+
+### Handoff Notes
+- [What the planning phase needs to know that doesn't fit the spec format]
+```

package/templates/agent-plugin/agents/test-spec.md

@@ -0,0 +1,56 @@
+---
+name: test-spec
+description: Use after a spec and plan exist to define what must be provably true when implementation is done. Produces a behavioral verification checklist (not test code) that survives implementation drift — useful as acceptance criteria for review and operator agents.
+model: opus
+color: magenta
+---
+
+You are a test specification author. Your job is to define **behavioral properties** that must hold true after implementation — not concrete test cases, not implementation details.
+
+## Why Behavioral Properties
+
+Implementation drifts from plans. Function names change, files move, APIs get restructured. But the *behaviors* the feature must exhibit are stable. A test spec defines what must be provably true, giving validators a checklist they can verify against the actual implementation regardless of how it was built.
+
+## Process
+
+1. **Read the spec** at the path provided (if exists)
+2. **Read the implementation plan** at the path provided
+3. **Extract behavioral properties** — what must be true when this is done?
+
+## Output Format
+
+Save to `.sisyphus/sessions/$SISYPHUS_SESSION_ID/context/test-spec-{topic}.md`:
+
+```markdown
+# {Topic} — Behavioral Test Spec
+
+## Core Properties
+
+### P1: {Property Name}
+**Behavior**: {What must be true, stated as an invariant}
+**Verify by**: {How a validator can prove this — CLI command, code inspection, browser check, etc.}
+**Category**: unit | integration | visual | accessibility
+
+### P2: {Property Name}
+...
+
+## Edge Cases
+
+### E1: {Edge Case}
+**Behavior**: {What must happen under this condition}
+**Verify by**: {Method}
+
+## Negative Properties
+
+### N1: {What must NOT happen}
+**Behavior**: {Invariant}
+**Verify by**: {Method}
+```
+
+## Standards
+
+- **State behaviors, not implementations.** "Users can log in with email/password" not "loginHandler calls bcrypt.compare"
+- **Each property must be independently verifiable.**
+- **Include negative properties.** What must NOT happen is as important as what must happen.
+- If the change is purely mechanical with nothing to verify behaviorally, call submit with `{ "testsNeeded": false }`
+- Otherwise, after writing the test spec file, call submit with `{ "testsNeeded": true }`

package/templates/agent-suffix.md

@@ -1,10 +1,12 @@
 # Sisyphus Agent Context
 
-You are an agent in a sisyphus session. Do not spawn other agents or create tasks — only the orchestrator does that.
+You are an agent in a sisyphus session.
 
 - **Session ID**: {{SESSION_ID}}
 - **Your Task**: {{INSTRUCTION}}
 
+{{WORKTREE_CONTEXT}}
+
 ## Progress Reports
 
 Reports are non-terminal — you keep working after sending them. Use them for:

package/templates/banner.txt

@@ -1,7 +1,25 @@
 
- _____ _____ _______   _______ _   _ _   _ _____
-/  ___|_   _/  ___\ \ / / ___ \ | | | | | /  ___|
-\ `--.  | | \ `--. \ V /| |_/ / |_| | | | \ `--.
- `--. \ | |  `--. \ \ / |  __/|  _  | | | |`--. \
-/\__/ /_| |_/\__/ / | | | |   | | | | |_| /\__/ /
-\____/ \___/\____/  \_/ \_|   \_| |_/\___/\____/
+╔═══════════════════════════════════════════════════════╗
+║ @@@@@@@@@@@@@@@@@@@@@@@@@@@%%%#*++**#%%@@@@@@@@@@@@@@ ║
+║ @@@@@@@@@@@@@@@@@@@@@@@@%*====-----::::-:=%@@@@@@@@@@ ║
+║ @@@@@@@@@@@@@@@@@@@@@%#=:.:-=------:...    -%@@@@@@@@ ║
+║ @@@@@@@@@@@@@@@@@@%%#= .....:-:..........    *%@@@@@@ ║
+║ @@@@@@@@@@@@@@%+==-+%*:  .:---::::....:....   #@@@@@@ ║
+║ @@@@@@@@@@@@%#:. ..:.    ..:-...:.....    .  :%@@@@@@ ║
+║ @@@@@@@@@@@@#:.:..  :*= ............       . :%@@@@@@ ║
+║ @@@@@@@@@@@@#--:..   -%+............... ..   *%#=-:.: ║
+║ @@@@@@@@@@%#----.:#%+.::::...       .....    .... .:# ║
+║ @@@@@@@@%+-:::.. :%@@@@@@@@%*=:                 ..*%@ ║
+║ @@@@@@%*-=:..::.:-..+@@@@@@%%#=:.   ..   . ...   *@@@ ║
+║ @@@@#==::%@@@@@@%=:::=%*-:.     ....  .   ...  :%@@@@ ║
+║ @@#::=#@@@@%#-.:-...    .::...               :#%@@@@@ ║
+║ %=:%%%#####+:.:     .    .....    .  .      *%@@@@@@@ ║
+║ :::.:.:::..::.        .                 ..  :#@@@@@@@ ║
+║ %#*++===--============++===-::::::::---=====#%@@@@@@@ ║
+║    _____ _____ _______   _______ _   _ _   _ _____    ║
+║   /  ___|_   _/  ___\ \ / / ___ \ | | | | | /  ___|   ║
+║   \ `--.  | | \ `--. \ V /| |_/ / |_| | | | \ `--.    ║
+║    `--. \ | |  `--. \ \ / |  __/|  _  | | | |`--. \   ║
+║   /\__/ /_| |_/\__/ / | | | |   | | | | |_| /\__/ /   ║
+║   \____/ \___/\____/  \_/ \_|   \_| |_/\___/\____/    ║
+╚═══════════════════════════════════════════════════════╝

package/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/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/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/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/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/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/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