sisyphi 1.0.2 → 1.0.5

package/dist/templates/resources/.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/resources/.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

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

@@ -1,208 +0,0 @@
-# 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/resources/.claude-plugin/plugin.json

@@ -1,8 +0,0 @@
-{
-  "name": "sisyphus",
-  "version": "1.1.0",
-  "description": "Orchestration agents and workflow patterns for sisyphus multi-agent sessions",
-  "author": {
-    "name": "Silas Rhyneer"
-  }
-}