sisyphi 1.0.2 → 1.0.4

package/dist/templates/agent-plugin/.claude/agents/review.md

@@ -1,56 +0,0 @@
----
-name: review
-description: Code review. Spawns parallel subagents by concern area. Read-only.
-model: opus
-color: orange
----
-
-You are a code reviewer. Investigate, validate, and report — never edit code.
-
-## Process
-
-1. **Scope** — Determine what to review:
-   - If a path is given, review those files
-   - If uncommitted changes exist, review the diff
-   - If clean tree, review recent commits vs main
-
-2. **Context** — Read CLAUDE.md, applicable `.claude/rules/*.md`, and codebase conventions in the target area.
-
-3. **Classify** — Determine review depth from change type:
-   - Hotfix/security: **maximum** depth
-   - New feature: **standard**
-   - Refactor: **behavior-focused** (verify equivalence)
-   - Test-only: **intent-focused**
-   - Documentation: **minimal**
-
-4. **Investigate** — Spawn parallel subagents by concern area, scaled to scope:
-   - <10 files: 3-4 subagents (grouped concerns)
-   - 10-25 files: 6-8 subagents
-   - 25+ files: 8-12 subagents
-
-5. **Validate** — Spawn validation subagents (~1 per 3 issues):
-   - Bugs/Security (opus): confirm exploitable/broken
-   - Everything else (sonnet): confirm significant, reject subjective nitpicks
-   - Drop anything that doesn't survive validation
-
-6. **Synthesize** — Deduplicate, filter low-confidence findings, prioritize by severity.
-
-## Concerns (ordered by AI risk)
-
-| Concern | Model | Risk | Focus |
-|---------|-------|------|-------|
-| Security | opus | 2.74x | Input validation, XSS, injection, auth |
-| Error Handling | opus | 2x | Missing guardrails, swallowed errors |
-| Logic Bugs | opus | 1.75x | Incorrect conditions, off-by-one, state bugs |
-| Over-engineering | sonnet | high | Abstractions without justification |
-| Dead Code/Bloat | sonnet | 1.64x | Unused code, duplication |
-| Compliance | sonnet | — | CLAUDE.md/rules adherence |
-| Pattern Consistency | sonnet | — | Naming, architecture, conventions |
-
-## Do NOT Flag
-
-Pre-existing issues, linter-catchable issues, subjective style, speculative problems without evidence.
-
-## Output
-
-Sectioned by severity (Critical, High, Medium). Every finding cites `file:line` with concrete evidence. No low-signal tier.

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

@@ -1,73 +0,0 @@
----
-name: spec-draft
-description: Investigate codebase, propose feature spec with open questions for human iteration.
-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/dist/templates/agent-plugin/.claude/agents/test-spec.md

@@ -1,56 +0,0 @@
----
-name: test-spec
-description: Define behavioral test properties — what must be provably true after implementation.
-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/dist/templates/orchestrator-plugin/.claude/commands/begin.md

@@ -1,62 +0,0 @@
----
-description: Quick reference for using sisyphus multi-agent orchestration
----
-
-# Sisyphus Quick Reference
-
-Sisyphus is a tmux-based daemon that orchestrates multi-agent Claude Code workflows. A background daemon manages sessions where an orchestrator breaks work into subtasks, spawns agents in tmux panes, and coordinates their lifecycle through cycles.
-
-## Start the daemon
-
-```bash
-sisyphus start "your task description"
-```
-
-This creates a session and spawns an orchestrator Claude in a tmux pane. The orchestrator plans work, spawns agents, then yields. Agents work in parallel and submit reports. The orchestrator respawns each cycle to review progress.
-
-## How it works
-
-1. **You** run `sisyphus start` with a complete, detailed task
-2. **Orchestrator** decomposes it into subtasks, spawns agents in parallel, yields
-3. **Agents** work in parallel tmux panes, submit reports when done
-4. **Daemon** detects completion, respawns orchestrator with updated state
-5. **Orchestrator** reviews reports, spawns more agents or calls complete
-
-Orchestrator pane is yellow. Agent panes cycle through blue, green, magenta, cyan, red, white.
-
-## Task description philosophy
-
-**Be bold and thorough.** Give sisyphus complete, meaty descriptions. Don't hold back out of concern that it's "too much" — detailed tasks produce better orchestration. The orchestrator figures out how to break it down; your job is to describe what done looks like.
-
-**No pre-planning needed.** You don't need to spec or plan before handing off to sisyphus. Skip the `/rpi:arch` → `/rpi:plan` ceremony unless you want to. Sisyphus spawns agents that can investigate, draft specs, write plans, implement, and review — all within a single session.
-
-**Good task descriptions include:**
-- What needs to be built or fixed (with context on why)
-- Where relevant code lives if you know it
-- What a successful outcome looks like
-- Any constraints or preferences (tech choices, style, tests)
-- Adjacent concerns to be aware of (don't break X, keep Y working)
-
-**Example — too sparse:**
-```
-sisyphus start "fix the auth bug"
-```
-
-**Example — good:**
-```
-sisyphus start "Fix the JWT refresh bug in src/auth/. When a token expires mid-session, the app shows a blank screen instead of redirecting to login. Root cause is probably in the token interceptor (src/auth/interceptor.ts) — it catches 401s but doesn't clear state before redirect. Fix the bug, add a test that simulates token expiry during an active session, and make sure the logout flow also clears tokens correctly."
-```
-
-## Key commands
-
-| Command | Purpose |
-|---------|---------|
-| `sisyphus start "task"` | Create a session and launch the orchestrator |
-| `sisyphus status` | Check current session state |
-| `sisyphus list` | List all sessions |
-| `sisyphus resume <id>` | Resume a paused session |
-| `sisyphus tasks list` | View tracked tasks |
-| `sisyphus spawn --instruction "..."` | Spawn an agent (orchestrator only) |
-| `sisyphus yield` | Hand control back to daemon (orchestrator only) |
-| `sisyphus submit --report "..."` | Report results (agent only) |
-| `sisyphus complete --report "..."` | Mark session done (orchestrator only) |

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

@@ -1,40 +0,0 @@
----
-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. **Tasks are the orchestrator's memory.** State.json persists across cycles — tasks and agent reports are all you have. Make task descriptions 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/.claude/skills/orchestration/task-patterns.md

@@ -1,222 +0,0 @@
-# Task Breakdown Patterns
-
-Patterns for how the orchestrator should structure tasks for common workflow types. Each pattern shows the task list 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.
-
-### Task structure
-```
-t1: Diagnose root cause of [bug description]
-t2: Implement fix for [root cause]
-t3: Validate fix — regression tests pass, bug is resolved
-t4: Review fix for unintended side effects
-```
-
-### Cycle plan
-- **Cycle 1**: Spawn `sisyphus:debug` for t1. Yield.
-- **Cycle 2**: Read diagnosis report. If confident root cause found, spawn `sisyphus:implement` for t2 with the diagnosis as context. Yield.
-- **Cycle 3**: Spawn `sisyphus:validate` for t3. Yield.
-- **Cycle 4**: If validation passes, spawn `sisyphus:review` for t4. If fails, update t2 with failure context and respawn implement. Yield.
-- **Cycle 5**: Review results. Complete or address review findings.
-
-### Failure modes
-- **Debug inconclusive**: Add more context to t1, respawn debug with narrower scope or different focus areas.
-- **Fix breaks other things**: t3 catches this. Feed validation failures back into a new implement cycle.
-- **Root cause was wrong**: Create new t1 variant 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.
-
-### Task structure
-```
-t1: Plan implementation for [feature]
-t2: Implement [feature]
-t3: Validate implementation
-```
-
-### Cycle plan
-- **Cycle 1**: Spawn `sisyphus:plan` for t1. Yield.
-- **Cycle 2**: Spawn `sisyphus:implement` for t2 with plan path. Yield.
-- **Cycle 3**: Spawn `sisyphus:validate` for t3. 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.
-
-### Task structure
-```
-t1: Draft spec for [feature] — investigate codebase, propose approach
-t2: Create implementation plan from spec
-t3: Review plan against spec
-t4: Phase 1 — [foundation/types/interfaces]
-t5: Phase 2 — [core logic]
-t6: Phase 3 — [integration/wiring]
-t7: Validate full implementation
-t8: Review implementation
-```
-
-### Cycle plan
-- **Cycle 1**: Spawn `sisyphus:spec-draft` for t1. Yield. (Human iterates on spec between cycles.)
-- **Cycle 2**: Spawn `sisyphus:plan` for t2. Yield.
-- **Cycle 3**: Spawn `sisyphus:review-plan` for t3. If fail, respawn plan with issues. Yield.
-- **Cycle 4**: Spawn `sisyphus:implement` for t4. Yield.
-- **Cycle 5**: Spawn `sisyphus:implement` for t5 + `sisyphus:validate` for t4 (parallel if t5 doesn't depend on t4 output). 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 (t4) must complete before implementation phases that consume them.
-
----
-
-## Feature Build (Large — 10+ files)
-
-### When to use
-Cross-cutting feature, multiple domains, needs team coordination.
-
-### Task structure
-```
-t1: Draft spec for [feature]
-t2: Create master implementation plan
-t3: Review plan against spec
-t4: Define behavioral test properties
-t5: Phase 1 — [domain A foundation]
-t6: Phase 2 — [domain B foundation]
-t7: Phase 3 — [domain A implementation]
-t8: Phase 4 — [domain B implementation]
-t9: Phase 5 — [integration layer]
-t10: Validate full implementation
-t11: Review implementation
-t12: Adversarial validation against test spec
-```
-
-### Cycle plan
-- **Cycle 1**: Spawn `sisyphus:spec-draft` for t1. Yield.
-- **Cycle 2**: Spawn `sisyphus:plan` for t2 + `sisyphus:test-spec` for t4 (parallel). Yield.
-- **Cycle 3**: Spawn `sisyphus:review-plan` for t3. Yield.
-- **Cycle 4**: Spawn `sisyphus:implement` for t5 + t6 (parallel — independent domains). Yield.
-- **Cycle 5**: Validate t5 + t6, then spawn t7 + t8 (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.
-
-### Task structure
-```
-t1: Analyze current structure and plan refactor
-t2: Capture behavioral snapshot (existing tests + manual checks)
-t3: Execute refactor phase 1 — [structural changes]
-t4: Execute refactor phase 2 — [update consumers]
-t5: Validate behavior preserved — all original tests pass
-t6: Review for missed references, dead code, broken imports
-```
-
-### Cycle plan
-- **Cycle 1**: Spawn `sisyphus:plan` for t1 + `sisyphus:validate` for t2 (capture baseline). Yield.
-- **Cycle 2**: Spawn `sisyphus:implement` for t3. Yield.
-- **Cycle 3**: Spawn `sisyphus:implement` for t4 + `sisyphus:validate` for t3 (parallel). Yield.
-- **Cycle 4**: Spawn `sisyphus:validate` for t5. Yield.
-- **Cycle 5**: Spawn `sisyphus:review` for t6. 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.
-
-### Task structure
-```
-t1: Review [scope] for issues
-t2: (conditional) Fix critical/high issues found
-t3: (conditional) Re-review fixes
-```
-
-### Cycle plan
-- **Cycle 1**: Spawn `sisyphus:review` for t1. Yield.
-- **Cycle 2**: If critical/high issues, spawn `sisyphus:implement` for t2. If clean, complete.
-- **Cycle 3**: Spawn `sisyphus:review` for t3 (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.
-
-### Task structure
-```
-t1: Investigate [question/area]
-t2: Summarize findings and recommendation
-```
-
-### Cycle plan
-- **Cycle 1**: Spawn `sisyphus:debug` (for code investigation) or `sisyphus:general` (for broader research) for t1. Yield.
-- **Cycle 2**: Spawn `sisyphus:general` for t2 to synthesize. 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 task at a time, and tracks progress.
-
-### Task structure
-```
-t1: Execute implementation plan at [path] using tactician loop
-```
-
-### Cycle plan
-This is a single-task 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