sisyphi 1.1.34 → 1.1.36

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "sisyphi",
-  "version": "1.1.34",
+  "version": "1.1.36",
   "description": "tmux-integrated orchestration daemon for Claude Code multi-agent workflows",
   "license": "MIT",
   "repository": {

package/templates/agent-plugin/agents/operator.md

@@ -7,8 +7,12 @@ effort: low
 interactive: true
 permissionMode: bypassPermissions
 systemPrompt: append
+skills:
+  - operator
+  - operator-memory
 plugins:
   - capture@crouton-kit
+  - authoring@crouton-kit
 ---
 
 You are the human in the loop. When the team needs someone to actually use the product, test a flow, check what's on screen, read logs, interact with an external service, or do anything that a developer would alt-tab to a browser for — that's you.
@@ -31,6 +35,12 @@ Key thing: prefer interacting via accessible names (`capture click "Submit"`, `c
 
 Don't guess the target. The product might be a browser page, an Electron app, or something else entirely. If the spawn instructions don't specify what to attach to, run `capture detect` / `capture list` and ask for guidance rather than assuming Chrome.
 
+## Project-Local Memory
+
+You have a memory file at `.sisyphus/agent-plugin/skills/operator/SKILL.md`, plus per-task-family reference files alongside it. **Read it now** — it's accumulated knowledge from prior operator runs in this project (auth flow, db reset, common surfaces, known footguns). It scaffolds itself on first use; if it looks like a stub, you're the first.
+
+**Before submitting your final report**, invoke the `operator-memory` skill — it covers when and how to update the memory so the next operator starts ahead of where you started. For generic skill-authoring conventions (frontmatter, length, structure), defer to `/authoring:skills`.
+
 ## Unblock Yourself
 
 You are the operator. If something stands between you and testing, **fix it yourself**. Never give up and never fall back to reading code and making assumptions — that defeats the entire point of your role.

package/templates/agent-plugin/hooks/CLAUDE.md

@@ -1,5 +1,4 @@
 - The bundled `hooks.json` here is the **manifest** — the daemon merges it with project (`.sisyphus/agent-plugin/hooks/hooks.json`) and user (`~/.sisyphus/agent-plugin/hooks/hooks.json`) layers at spawn time, then writes the merged result into the per-agent plugin dir. Script edits are invisible to running agents; **respawn required**.
-- New hooks register declaratively: add a manifest entry with `agentTypes: [...]` (or `["all"]`) and the script gets copied automatically. No `src/daemon/agent.ts` edits needed for new agent-type-specific hooks. The merge logic lives in `src/daemon/extensions.ts` (`mergeHookManifests`, `collectReferencedHookScripts`).
 - A bundled hook script is only copied into a spawned agent's plugin dir if the merged manifest references it for that agent type — scripts whose entries filter out (e.g. `plan-validate.sh` for a `review` agent) are skipped. Higher layers can suppress a bundled script by basename via `"disable": ["script.sh"]` at the manifest's top level.
 - `interactive: true` in agent frontmatter triggers `condition: "non-interactive"` filtering — entries with that condition (currently the bundled `require-submit.sh` Stop hook) are dropped from the merged manifest for interactive agents.
 - Scripts receive no `{{placeholder}}` substitution — placeholders appear as literal text, unlike `.md` templates.

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

@@ -1,7 +1,39 @@
 #!/bin/bash
-# UserPromptSubmit hook: reinforce paranoid testing for operator agents.
+# UserPromptSubmit hook: scaffold project-local operator memory on first run,
+# then reinforce paranoid testing.
 if [ -z "$SISYPHUS_SESSION_ID" ]; then exit 0; fi
 
+# ── Scaffold project-local operator memory ──────────────────────────────────
+# On first run in a project, .sisyphus/agent-plugin/skills/operator/ doesn't
+# exist. The bundled seed has already been copied into this agent's per-spawn
+# plugin dir by the daemon (operator.md frontmatter lists skills: [operator]),
+# so it's reachable via $CLAUDE_PLUGIN_ROOT — copy it from there to the
+# project layer so future operator runs pick up the project-layer overlay.
+SCAFFOLDED=0
+if [ -n "$SISYPHUS_CWD" ] && [ -n "$CLAUDE_PLUGIN_ROOT" ]; then
+  PROJECT_MEMORY_DIR="$SISYPHUS_CWD/.sisyphus/agent-plugin/skills/operator"
+  BUNDLED_SEED_DIR="$CLAUDE_PLUGIN_ROOT/skills/operator"
+  if [ ! -f "$PROJECT_MEMORY_DIR/SKILL.md" ] && [ -d "$BUNDLED_SEED_DIR" ]; then
+    mkdir -p "$PROJECT_MEMORY_DIR"
+    cp -R "$BUNDLED_SEED_DIR/." "$PROJECT_MEMORY_DIR/"
+    SCAFFOLDED=1
+  fi
+fi
+
+if [ "$SCAFFOLDED" = "1" ]; then
+  cat <<'HINT'
+<operator-memory-scaffolded>
+Project-local operator memory was just scaffolded at .sisyphus/agent-plugin/skills/operator/ — read it now (it's a stub; you're the first operator in this project). Before submitting your final report, invoke the `operator-memory` skill and update the memory with whatever future operators should not have to rediscover.
+</operator-memory-scaffolded>
+HINT
+else
+  cat <<'HINT'
+<operator-memory>
+Project-local operator memory is at .sisyphus/agent-plugin/skills/operator/ — read it now to inherit what prior operators learned. Before submitting your final report, invoke the `operator-memory` skill and update the memory with anything new you discovered.
+</operator-memory>
+HINT
+fi
+
 cat <<'HINT'
 <operator-reminder>
 Click EVERYTHING — assume something is broken and prove it:

package/templates/agent-plugin/skills/operator/SKILL.md

@@ -0,0 +1,38 @@
+---
+name: operator
+description: Project-local operational knowledge for THIS app, accumulated by prior operator runs. Covers app surfaces (routes, ports, processes, admin overlays), auth/login flow, db state management, common UI flows, and known footguns. Use whenever the operator agent needs project-specific operating knowledge — read at session start, update before submitting.
+---
+
+# Operator memory for this project
+
+This is the operator agent's accumulated memory for THIS project. Each prior operator run added what it learned. You should add what you learn before submitting.
+
+If this file looks mostly empty, you're early — populate as you go. The structure below is the target shape, not a requirement to fill all sections immediately.
+
+## App surfaces
+
+Routes, ports, processes, admin overlays, debug flags. One line each — link to a reference file if there's depth.
+
+- *(populate as you discover them)*
+
+## Common operational patterns
+
+Login, logout, db reset, seeding, environment toggles. Brief — defer details to reference files.
+
+- *(populate as you discover them)*
+
+## Known footguns
+
+Things that broke once and might break again — race conditions, ordering requirements, stale-cache traps.
+
+- *(populate as you discover them)*
+
+## Reference files
+
+One line per file in this directory. Add an entry here when you create a new reference.
+
+- *(none yet)*
+
+---
+
+For guidance on what to capture, where to put it (SKILL.md vs new reference file), and naming conventions, invoke the `operator-memory` skill before submitting.

package/templates/agent-plugin/skills/operator-memory/SKILL.md

@@ -0,0 +1,64 @@
+---
+name: operator-memory
+description: Use right before the operator agent submits its final report. Provides guidance for updating the project-local operator memory at .sisyphus/agent-plugin/skills/operator/ — what to capture, where to put it (SKILL.md vs a new reference file), naming conventions, and what to skip. Defers to /authoring:skills for generic skill conventions (frontmatter, length budgets, structure).
+user-invocable: false
+---
+
+# Updating operator memory
+
+You're about to submit. Spend a minute capturing what the next operator should not have to rediscover.
+
+The memory lives at `.sisyphus/agent-plugin/skills/operator/`:
+- `SKILL.md` — the high-level map of this app's surfaces and operations
+- per-task-family reference files alongside it (`auth.md`, `db-reset.md`, `checkout-flow.md`, etc.)
+
+## When to update (and when NOT to)
+
+The bar is **"will future operators benefit from this?"** Specifics:
+
+UPDATE when you discovered:
+- A repeatable operational procedure (login flow, db reset, seed step, environment toggle)
+- A surface that wasn't obvious (admin route, debug overlay, hidden flag, internal port)
+- A footgun you hit and worked around (race condition, ordering requirement, stale-cache trap)
+- A convention this app uses that differs from defaults (custom auth headers, non-standard ports, weird redirect chains)
+
+DON'T update when:
+- It's session-specific state (this user's email, this session's seeded data)
+- It's a one-off observation that won't reproduce
+- It's already covered (read existing files first — duplication is worse than nothing)
+- It's about the codebase, not about operating the app — that's the orchestrator's domain, not yours
+
+## SKILL.md vs a reference file
+
+**SKILL.md** is the high-level map. It answers "what surfaces does this app have, what are the most common operations, where do I find deep dives?" Keep it dense — under ~80 lines. Each entry is a line or two with a pointer.
+
+**A reference file** is the deep dive for one task family. It answers "exactly how do I do X step by step in this project". Each file has scope: `auth.md`, `db-reset.md`, `checkout-flow.md`, `feature-flags.md`.
+
+Decision rule:
+- New task family the operator might face → new reference file (and add a one-line entry to SKILL.md's Reference Files section).
+- Refinement to existing knowledge → update the existing reference file or SKILL.md.
+- A surface name you keep referencing → add it to SKILL.md's App Surfaces section once.
+
+## Naming conventions
+
+- Reference files: kebab-case, task-family scope, no `operator-` prefix (the directory already implies it), `.md` extension.
+- Good: `auth.md`, `admin-panel.md`, `db-reset.md`, `feature-flags.md`.
+- Bad: `operator-auth.md`, `flows.md`, `notes.md`, `stuff.md`.
+- One file per task family. If `auth.md` exists, append to it; don't create `auth-new.md` or `auth-2.md`.
+
+## How to update
+
+1. **Read first.** Open the current `SKILL.md` and any reference file you'll touch — orient before writing. Avoid duplicating what's already there.
+2. **Write/edit with the Write or Edit tool.** The directory already exists at `.sisyphus/agent-plugin/skills/operator/` (the hook scaffolds it on first run).
+3. **Keep prose dense.** The next operator pays in tokens for everything you write. If a step is obvious, omit it.
+4. **Register new reference files** by adding a one-line entry to `SKILL.md`'s "Reference files" section so they're discoverable.
+
+For frontmatter, length budgets, and general skill structure rules, invoke `/authoring:skills`. Don't reinvent those rules here — this skill only covers operator-specific guidance.
+
+## Examples
+
+**Discovered magic-link auth flow:** Create `auth.md` with the steps (email submit → check inbox → click link → cookie set). Add a one-liner to `SKILL.md` App Surfaces (`/login` — magic-link, see `auth.md`). Add to Common Operational Patterns (`Log in: see auth.md`).
+
+**Hit a stale-cache footgun:** The `/dashboard` route serves stale data for ~30s after a write because of an SWR cache. Add a single bullet to `SKILL.md` Known Footguns: `Dashboard SWR cache holds stale data ~30s after writes — hard refresh or wait`. No new reference file needed — it's a one-liner.
+
+**Found admin overlay:** `?admin=1` query param toggles an admin panel with seed/reset buttons. Add to `SKILL.md` App Surfaces: `Admin overlay: append ?admin=1 to any page; has seed/reset/feature-flag buttons`. If the overlay is rich enough to need step-by-step coverage, create `admin-panel.md` and link from there.

package/templates/companion-plugin/hooks/user-prompt-context.sh

@@ -1,3 +1,6 @@
 #!/bin/bash
-if [ -z "$SISYPHUS_COMPANION_CWD" ]; then exit 0; fi
-sisyphus companion context --cwd "$SISYPHUS_COMPANION_CWD" 2>/dev/null
+set -euo pipefail
+if [ -z "${SISYPHUS_COMPANION_CWD:-}" ]; then exit 0; fi
+SESSION_ID=$(jq -r '.session_id // empty')
+[ -n "$SESSION_ID" ] || exit 0
+exec sisyphus companion context --cwd "$SISYPHUS_COMPANION_CWD" --session-id "$SESSION_ID"

package/templates/orchestrator-planning.md

@@ -110,10 +110,16 @@ The cycle shape:
 plan phase 1 → implement phase 1 → validate phase 1 → plan phase 2 → implement phase 2 → validate phase 2 → ...
 ```
 
-After a phase's implementation passes e2e validation, yield back to planning mode for the next phase:
+**Not every phase needs its own plan cycle.** Before yielding back, look at phase N+1 in `strategy.md`. If it's wrapper-shaped (every change backs onto an existing CLI/API/handler), mechanical (rename, move, reformat), or scoped to a single agent-cycle of work, yield directly to implementation and let the implement agent work from `strategy.md` plus what phase N taught you. Reserve the plan cycle for phases where the *how* is genuinely open.
+
+After a phase's implementation passes e2e validation, yield for the next phase — pick the mode that matches its shape:
 
 ```bash
+# Phase N+1 needs planning (default):
 sis orch yield --mode planning --prompt "Phase N validated. Plan phase N+1 per strategy.md."
+
+# Phase N+1 is wrapper-shaped or single-cycle:
+sis orch yield --mode implementation --prompt "Phase N validated. Implement phase N+1 per strategy.md."
 ```
 
 When spawning the phase-scoped plan lead, name in the prompt: