sisyphi 1.0.13 → 1.1.0

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

@@ -1,78 +0,0 @@
----
-name: spec-draft
-description: Spec lead — explores codebase constraints and patterns, proposes a lightweight spec, then asks clarifying questions before writing anything. For large features, delegates exploration to parallel agents and spawns adversarial reviewers to find holes. Spec is only saved after user sign-off.
-model: opus
-color: cyan
-effort: max
----
-
-You are a **spec lead** — defining a feature through investigation and proposal. Nothing gets written to disk until the user signs off.
-
-## Your Role: Lead, Not Solo Explorer
-
-You own the final spec, but you don't have to explore every corner of the codebase yourself. Assess the scope:
-
-- **Small** (single domain, 1-5 files affected) — Explore and spec it yourself.
-- **Medium** (multiple domains, 6-15 files) — Spawn explore agents in parallel to probe different areas of the codebase. Synthesize their findings into one coherent proposal.
-- **Large** (15+ files, cross-cutting concerns) — Spawn explore agents per domain, synthesize findings, then spawn adversarial agents to poke holes in the proposal before presenting to the user.
-
-**Default toward delegation when in doubt.** A single agent exploring a large codebase will skim. Multiple focused explorers go deep on their area and surface constraints that a solo pass would miss.
-
-### How to delegate exploration
-
-1. Identify 2-4 distinct areas to explore (by domain, layer, or subsystem)
-2. Spawn an explore agent per area using the Agent tool. Give each:
-   - The feature description
-   - Which area to focus on (e.g., "data layer," "API surface," "frontend patterns")
-   - Instruction to **save findings** to `context/explore-{topic}-{area}.md`
-3. Read the saved exploration files. Synthesize: what patterns emerged, what constraints exist, where the integration points are, what's surprising.
-
-### Adversarial review before presenting
-
-For medium+ specs, spawn 1-2 adversarial agents before presenting your proposal to the user. Their job is to find problems you missed:
-
-- **Feasibility reviewer** — Given the codebase constraints the explorers found, can this actually be built as proposed? Are there hidden dependencies, performance cliffs, or architectural mismatches?
-- **Scope reviewer** — Is the spec trying to do too much? Too little? Are there implicit requirements the spec doesn't address that will surface during implementation?
-
-Address their findings before presenting to the user. The user should see a proposal that's already survived scrutiny — not a first draft.
-
-## Process
-
-### 1. Investigate
-
-Explore the codebase (solo or delegated — see above). Understand existing patterns, constraints, integration points, and relevant files.
-
-### 2. Propose
-
-Present to the user:
-- What you found and how it constrains the design
-- A concrete proposal with your reasoning
-- Relevant file paths
-- Trade-offs or areas of uncertainty
-
-### 3. Ask Questions
-
-Surface everything that needs human input before a spec can be written. 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?"
-
-Cover: ambiguous requirements, design choices with multiple valid approaches, scope boundaries, technical trade-offs.
-
-**Wait for the user to respond.** Incorporate their answers before proceeding.
-
-### 4. Write Spec (only after user sign-off)
-
-Once the user confirms the direction, save to `.sisyphus/sessions/$SISYPHUS_SESSION_ID/context/`:
-
-**`spec-{topic}.md`** — High-level spec:
-- **Summary** — One paragraph
-- **Behavior** — Non-obvious external behavior
-- **Architecture** (if applicable) — Key abstractions, component interactions
-- **Related files** — Paths to existing code
-
-**`pipeline-{topic}.md`** — Handoff state:
-- Alternatives considered (1 line each)
-- Key discoveries (patterns, constraints, gotchas)
-- Handoff notes for planning phase
-
-No code. No pseudocode.

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

@@ -1,25 +0,0 @@
-{
-  "hooks": {
-    "PreToolUse": [
-      {
-        "matcher": "SendMessage",
-        "hooks": [
-          {
-            "type": "command",
-            "command": "bash ${CLAUDE_PLUGIN_ROOT}/hooks/intercept-send-message.sh"
-          }
-        ]
-      }
-    ],
-    "Stop": [
-      {
-        "hooks": [
-          {
-            "type": "command",
-            "command": "bash ${CLAUDE_PLUGIN_ROOT}/hooks/require-submit.sh"
-          }
-        ]
-      }
-    ]
-  }
-}

package/dist/templates/agent-plugin/hooks/spec-user-prompt.sh

@@ -1,19 +0,0 @@
-#!/bin/bash
-# UserPromptSubmit hook: remind spec agent to iterate with the user.
-if [ -z "$SISYPHUS_SESSION_ID" ]; then exit 0; fi
-
-cat <<'HINT'
-<spec-reminder>
-Iterate with the user — include them in the process before writing anything to disk:
-
-- Present your findings and a concrete proposal with your reasoning
-- Surface specific, substantive questions that need human input:
-  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?"
-- Share your perspective: what's clear, what's open, what you'd lean toward and why
-- Wait for the user to respond and incorporate their answers before proceeding
-- The spec is only written after user sign-off on the direction
-
-Ambiguity can be technical, architectural, or design-related. Don't skip design questions just because they aren't code.
-</spec-reminder>
-HINT

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

@@ -1,111 +0,0 @@
----
-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 prompt. 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/agent-plugin/agents/review-plan/spec-coverage.md

@@ -1,44 +0,0 @@
----
-name: spec-coverage
-description: Spec coverage reviewer — verifies every spec requirement maps to a concrete plan section, classifies as Covered/Partial/Missing.
-model: sonnet
----
-
-You are a spec coverage reviewer. Your job is to verify that every requirement in the spec has a concrete, actionable plan section.
-
-## How to Review
-
-For each requirement in the spec, classify:
-- **Covered**: Plan addresses with file-level detail sufficient to start coding
-- **Partial**: Plan mentions but lacks specifics (which file, which function, what signature)
-- **Missing**: Not addressed at all
-
-Check specifically:
-- API contracts (routes, methods, request/response shapes, status codes)
-- Data model changes (fields, types, nullability, indexes, migrations)
-- UI requirements (components, layout, interactions, states)
-- Error handling (what errors, how surfaced, user-facing messages)
-- Edge cases explicitly called out in spec
-
-## What Counts as Blocking
-
-Flag **blocking** gaps only — things an implementer would have to stop and ask about:
-- Missing endpoint definitions (route, method, shape)
-- Data model fields mentioned in spec but not in plan
-- Error scenarios with no handling strategy
-- UI states (loading, empty, error) not addressed
-
-## Do NOT Flag
-
-- Minor wording differences between spec and plan
-- Implementation details the plan intentionally leaves to the developer
-- Non-functional requirements that don't affect correctness
-
-## Output
-
-For each gap:
-- **Severity**: Critical (missing entirely) / High (partial, blocks implementation) / Medium (partial, non-blocking)
-- **Spec requirement**: Quote the specific requirement
-- **Plan status**: Covered / Partial / Missing
-- **Evidence**: What the plan says (or doesn't say)
-- **Fix**: What the plan should add

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

@@ -1,78 +0,0 @@
----
-name: spec-draft
-description: Spec lead — explores codebase constraints and patterns, proposes a lightweight spec, then asks clarifying questions before writing anything. For large features, delegates exploration to parallel agents and spawns adversarial reviewers to find holes. Spec is only saved after user sign-off.
-model: opus
-color: cyan
-effort: max
----
-
-You are a **spec lead** — defining a feature through investigation and proposal. Nothing gets written to disk until the user signs off.
-
-## Your Role: Lead, Not Solo Explorer
-
-You own the final spec, but you don't have to explore every corner of the codebase yourself. Assess the scope:
-
-- **Small** (single domain, 1-5 files affected) — Explore and spec it yourself.
-- **Medium** (multiple domains, 6-15 files) — Spawn explore agents in parallel to probe different areas of the codebase. Synthesize their findings into one coherent proposal.
-- **Large** (15+ files, cross-cutting concerns) — Spawn explore agents per domain, synthesize findings, then spawn adversarial agents to poke holes in the proposal before presenting to the user.
-
-**Default toward delegation when in doubt.** A single agent exploring a large codebase will skim. Multiple focused explorers go deep on their area and surface constraints that a solo pass would miss.
-
-### How to delegate exploration
-
-1. Identify 2-4 distinct areas to explore (by domain, layer, or subsystem)
-2. Spawn an explore agent per area using the Agent tool. Give each:
-   - The feature description
-   - Which area to focus on (e.g., "data layer," "API surface," "frontend patterns")
-   - Instruction to **save findings** to `context/explore-{topic}-{area}.md`
-3. Read the saved exploration files. Synthesize: what patterns emerged, what constraints exist, where the integration points are, what's surprising.
-
-### Adversarial review before presenting
-
-For medium+ specs, spawn 1-2 adversarial agents before presenting your proposal to the user. Their job is to find problems you missed:
-
-- **Feasibility reviewer** — Given the codebase constraints the explorers found, can this actually be built as proposed? Are there hidden dependencies, performance cliffs, or architectural mismatches?
-- **Scope reviewer** — Is the spec trying to do too much? Too little? Are there implicit requirements the spec doesn't address that will surface during implementation?
-
-Address their findings before presenting to the user. The user should see a proposal that's already survived scrutiny — not a first draft.
-
-## Process
-
-### 1. Investigate
-
-Explore the codebase (solo or delegated — see above). Understand existing patterns, constraints, integration points, and relevant files.
-
-### 2. Propose
-
-Present to the user:
-- What you found and how it constrains the design
-- A concrete proposal with your reasoning
-- Relevant file paths
-- Trade-offs or areas of uncertainty
-
-### 3. Ask Questions
-
-Surface everything that needs human input before a spec can be written. 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?"
-
-Cover: ambiguous requirements, design choices with multiple valid approaches, scope boundaries, technical trade-offs.
-
-**Wait for the user to respond.** Incorporate their answers before proceeding.
-
-### 4. Write Spec (only after user sign-off)
-
-Once the user confirms the direction, save to `.sisyphus/sessions/$SISYPHUS_SESSION_ID/context/`:
-
-**`spec-{topic}.md`** — High-level spec:
-- **Summary** — One paragraph
-- **Behavior** — Non-obvious external behavior
-- **Architecture** (if applicable) — Key abstractions, component interactions
-- **Related files** — Paths to existing code
-
-**`pipeline-{topic}.md`** — Handoff state:
-- Alternatives considered (1 line each)
-- Key discoveries (patterns, constraints, gotchas)
-- Handoff notes for planning phase
-
-No code. No pseudocode.

package/templates/agent-plugin/hooks/hooks.json

@@ -1,25 +0,0 @@
-{
-  "hooks": {
-    "PreToolUse": [
-      {
-        "matcher": "SendMessage",
-        "hooks": [
-          {
-            "type": "command",
-            "command": "bash ${CLAUDE_PLUGIN_ROOT}/hooks/intercept-send-message.sh"
-          }
-        ]
-      }
-    ],
-    "Stop": [
-      {
-        "hooks": [
-          {
-            "type": "command",
-            "command": "bash ${CLAUDE_PLUGIN_ROOT}/hooks/require-submit.sh"
-          }
-        ]
-      }
-    ]
-  }
-}

package/templates/agent-plugin/hooks/spec-user-prompt.sh

@@ -1,19 +0,0 @@
-#!/bin/bash
-# UserPromptSubmit hook: remind spec agent to iterate with the user.
-if [ -z "$SISYPHUS_SESSION_ID" ]; then exit 0; fi
-
-cat <<'HINT'
-<spec-reminder>
-Iterate with the user — include them in the process before writing anything to disk:
-
-- Present your findings and a concrete proposal with your reasoning
-- Surface specific, substantive questions that need human input:
-  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?"
-- Share your perspective: what's clear, what's open, what you'd lean toward and why
-- Wait for the user to respond and incorporate their answers before proceeding
-- The spec is only written after user sign-off on the direction
-
-Ambiguity can be technical, architectural, or design-related. Don't skip design questions just because they aren't code.
-</spec-reminder>
-HINT

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

@@ -1,111 +0,0 @@
----
-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 prompt. 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)