sisyphi 1.1.18 → 1.1.19

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

@@ -14,10 +14,14 @@ You are a review coordinator — do NOT review code directly. Spawn sub-agents u
 
 Always spawn core three (reuse, quality, efficiency). Add security for hotfix/security or sensitive code. Add compliance when CLAUDE.md/rules are extensive or scope is 5+ files.
 
+Sub-agent dispatch must be scope-only — pass the diff and file boundaries, NOT your hypotheses, suspicions, or specific things to look for. Sub-agents that receive a leading conclusion will anchor on it and miss independent findings. Let each sub-agent form its own assessment from the code. If you tell a quality agent "I think there's redundant state in foo.ts", it will find redundant state in foo.ts whether or not it's real.
+
+**A clean review is a valid and common outcome.** You are assessing a change, not hunting for something to flag. If all sub-agents come back clean, report clean — do not backfill. You are not deciding what's worth fixing; the orchestrator handles that. Your job is accurate detection. This review runs once per stage (there is no re-review after fixes), so make it thorough and honest, not padded.
+
 After sub-agents report, validate findings (~1 validation agent per 3 issues):
 - Bugs/Security: opus validates exploitable/broken
-- Everything else: sonnet confirms significant (not nitpick)
-- Drop anything subjective, pre-existing, or linter-catchable
+- Everything else: sonnet confirms the finding is concrete and accurate (not speculative or subjective)
+- Drop anything subjective, pre-existing, linter-catchable, or speculative without evidence
 - Every finding needs `file:line` + concrete evidence — no "this could be a problem"
 
 You are read-only. Investigate and direct fixes through implementers — never edit code yourself.

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

@@ -0,0 +1,43 @@
+#!/bin/bash
+# UserPromptSubmit hook: fire only on the first prompt to prime the spec lead
+# for a three-stage interactive spec session (shape → requirements → deepen).
+if [ -z "$SISYPHUS_SESSION_ID" ] || [ -z "$SISYPHUS_AGENT_ID" ]; then exit 0; fi
+
+FLAG_DIR="/tmp/sisyphus-hooks/${SISYPHUS_SESSION_ID}"
+FLAG_FILE="${FLAG_DIR}/${SISYPHUS_AGENT_ID}-spec-primed"
+
+# Only fire once per agent session
+if [ -f "$FLAG_FILE" ]; then exit 0; fi
+
+mkdir -p "$FLAG_DIR"
+touch "$FLAG_FILE"
+
+# IMPORTANT: heredoc delimiter is single-quoted (<<'HINT') — do NOT change to unquoted.
+# Single quotes prevent bash from expanding $INSTRUCTION, $SISYPHUS_*, backticks,
+# or any other dollar-sign content inside the prompt body. The body is static
+# instructional prose and must be byte-for-byte literal.
+#
+# If you ever need to interpolate an env var into this output, do NOT switch the
+# delimiter to unquoted. Instead, assign to a local var BEFORE the heredoc and
+# emit the interpolated part via a separate printf call after the heredoc.
+cat <<'HINT'
+<spec-first-prompt>
+This is a three-stage spec session: Stage 1 (shape), Stage 2 (requirements), Stage 3 (deepen). Do not treat it as a single requirements pass.
+
+Your first message to the user should:
+1. Briefly acknowledge what you understand from the instruction
+2. Ask 1–2 clarifying questions about scope or intent
+3. Be short — a few sentences and the questions, nothing more
+
+Before dispatching any subagent:
+- Explore the codebase relevant to the topic (Bash, Glob, Grep, Read)
+- Complete at least one round of user dialogue
+- Do NOT spawn the engineer until exploration is done and the user has responded to you at least once
+
+When you do dispatch subagents:
+- Engineer: Agent tool with subagent_type "engineer"
+- Requirements-writer: Agent tool with subagent_type "requirements-writer"
+
+You are the only pane the user sees. Narrate subagent activity in real time — tell the user when you dispatch a subagent and what it is doing, and tell them what came back when it returns.
+</spec-first-prompt>
+HINT

package/dist/templates/agent-plugin/skills/humanloop/SKILL.md

@@ -0,0 +1,147 @@
+---
+name: humanloop
+description: >
+  Read before calling `sisyphus ask`. Triggers when surfacing multiple questions or decisions to the user, presenting work for review/sign-off, or proposing concrete alternatives. Covers when a deck beats chat, how to design options as real forks the user can pick between, how to bundle related questions into one deck, and how to submit via the Bash tool's `run_in_background` so you can end your turn while the user takes their time answering.
+---
+
+# Talking to the user via decks
+
+`sisyphus ask` posts a structured deck of questions to the user's dashboard inbox. They walk through it on their own time and you read structured JSON back. Use it instead of dumping a wall of questions into chat.
+
+This skill covers **what to put in a deck** and **how to invoke it**. Run `sisyphus ask -h` for the CLI shape (file path, `--session`, the `poll` and `peek` subcommands).
+
+## Reach for a deck when
+
+- You have **2+ questions** to surface in one beat (bundle them into one deck).
+- You're presenting **work for review or sign-off** (a design, a plan, a completion summary).
+- You're choosing between **concrete alternatives** the user must pick.
+- The work will sit while the user thinks. Decks survive across cycles; chat does not.
+
+## Skip the deck when
+
+- It's a single, low-stakes question whose answer barely changes downstream work — just ask in chat.
+- You can settle the question yourself by reading code or running a tool. **Default to investigating before asking.**
+- The user is actively conversing with you — converting a live exchange into a deck adds friction.
+
+## How to invoke
+
+The CLI **always blocks** until the user resolves the deck (potentially 10+ minutes). Submit through the Bash tool with `run_in_background: true` and **end your turn**. Do not peek, poll, or output filler chat between submit and answer — the bash completion notification is the only signal you need; it will wake you with stdout ready to parse. Same pattern for orchestrator, sub-agents, and one-off Claude Code sessions.
+
+```
+Bash tool call:
+  command:           sisyphus ask "$deck"
+  run_in_background: true
+```
+
+Stdout on completion is one line of JSON: `{responses: [{id, selectedOptionId?, freetext?}, ...], completedAt}`. Branch on each response by its interaction `id`.
+
+If you already hold an `askId` from a prior cycle (e.g. respawned mid-wait), `sisyphus ask poll <askId>` blocks on it and `sisyphus ask peek <askId>` returns status without blocking. Use these only for respawn-recovery — **never to monitor a deck you just submitted in the current turn**. See `sisyphus ask -h`.
+
+## Designing interactions
+
+### Each option is a concrete path forward
+
+The user picks an option to commit to a direction. Each option should name a real path with its tradeoffs spelled out, grounded in *this* codebase. Sign-off decks branch differently per option ("looks good", "minor fixes", "moderate fixes", "scope rework" each route the orchestrator somewhere different). Decision decks present mutually exclusive directions with named consequences.
+
+<example type="good">
+```
+title: "Session store backend?"
+subtitle: "Auth needs persistent sessions across restarts"
+kind: decision
+options:
+  in-memory:  "In-memory map — simplest. Loses sessions on restart; single-process only."
+  redis:      "Redis — survives restart, supports horizontal scale. New ops dependency."
+  postgres:   "Reuse existing Postgres — no new infra; ~10ms read latency vs Redis ~1ms."
+  defer:      "Ship in-memory now, migrate later if scale becomes real."
+allowFreetext: true
+freetextLabel: "Different framing — describe it"
+```
+</example>
+
+<example type="bad">
+```
+title: "Happy with this design?"
+options:
+  1. Yes
+  2. No, start over
+  3. Maybe, with comments
+  4. (no option, just freetext)
+```
+"Happy?" names a feeling, not a fork. Options 3 and 4 both collapse to freetext, forcing the user to invent the actual decision. Rewrite as specific decisions about specific elements of the design.
+</example>
+
+### Use `allowFreetext: true` as a safety valve, not the primary input
+
+Freetext catches "anything else?" — opinions or context the options didn't anticipate. When freetext IS the answer you want, write a chat message instead.
+
+<example type="bad">
+```
+title: "Approve?"
+options:
+  1. Approve
+  2. Reject
+  3. Comment
+allowFreetext: true
+```
+A freetext form wearing option clothing. Either name what "reject" actually routes to (back to design? abandon? try a different framing?), or drop the deck and ask in chat.
+</example>
+
+### Bound option count to 2–4
+
+Above four, options become too granular for the user to weigh; below two, you've collapsed into a yes/no that's faster to ask in chat.
+
+### Ground options in what you've already gathered
+
+Each option label should reference specifics from the codebase, plan, or exploration you just did — file names, framework constraints, prior decisions. When you can't fill in specifics, investigate before asking.
+
+### One concern per interaction
+
+When two questions interact, give them separate `id` / `title` / `options` inside the same deck (see Bundling below). One interaction asks one thing.
+
+## `kind` — display hint
+
+| kind | use for |
+|---|---|
+| `decision` | fork in the road; user picks a path forward |
+| `validation` | sign-off on completed work |
+| `notify` | FYI; user acknowledges |
+| `context` | surfacing background that needs a response |
+| `error` | something went wrong; user picks a recovery |
+
+The dashboard uses `kind` for inbox icons and sort weight. Mis-tagging trains the user to ignore the icons. Pick the closest fit.
+
+## Bundling
+
+If you'd otherwise submit two decks in the same beat, merge them. One deck with multiple `interactions` is one context switch for the user; two decks is two.
+
+```bash
+deck="$SISYPHUS_SESSION_DIR/context/.ask-$(date +%s).json"
+cat > "$deck" <<'EOF'
+{
+  "title": "Phase 2 sign-off + follow-on decisions",
+  "interactions": [
+    {
+      "id": "approve-phase-2",
+      "title": "Phase 2 looks good?",
+      "kind": "validation",
+      "options": [...]
+    },
+    {
+      "id": "phase-3-scope",
+      "title": "Phase 3 scope?",
+      "kind": "decision",
+      "options": [...]
+    }
+  ]
+}
+EOF
+# Then invoke `sisyphus ask "$deck"` via the Bash tool with run_in_background: true.
+# Each interaction returns its own selectedOptionId / freetext in output.responses[], indexed by id.
+```
+
+## Submission notes
+
+- The deck is validated at submit (precise errors — trust them).
+- `bodyPath` lets an interaction point at a markdown file (e.g. a completion summary) instead of inlining the markdown in JSON.
+- On completion, stdout is one line of JSON: `{responses, completedAt}`. Parse `responses[]` and dispatch on each interaction's `id`.
+- See `sisyphus ask -h` for the full CLI surface.

package/dist/templates/agent-plugin/skills/perspective-fanout/SKILL.md

@@ -0,0 +1,115 @@
+---
+name: perspective-fanout
+description: >
+  Load when the problem-agent dialogue has produced enough substance to react to but conclusions haven't hardened — typically four or more turns in, with a framing solidifying. Provides the protocol for spawning eight perspective sub-agents in parallel, synthesizing their outputs, and presenting the synthesis back to the user via a render+deck pair. Available only at MEDIUM, HIGH, or XHIGH effort.
+---
+
+# Perspective fanout
+
+Spawn the eight perspective lenses as parallel sub-agents to challenge convergence before the framing locks in. The agents operate from a shared problem statement so their outputs are directly comparable. After they return, synthesize and surface to the user — convergence, surprises, insights — as the seed for the next dialogue turn.
+
+## When to spawn
+
+- The conversation has substance to react to (typically four or more turns in)
+- A framing is starting to solidify
+- You want to challenge convergence, not rescue a stalled discussion
+- You have already formed your own take
+
+If the conversation is stalled, use a plateau-breaker instead — perspective fanout needs material to push against.
+
+## Before spawning: write the shared problem statement
+
+Two or three sentences, given verbatim to all eight agents:
+
+- What's happening (or not happening)
+- What's been considered so far (from your exploration and the user input)
+- What a good outcome looks like
+
+This shared framing is what makes the eight outputs comparable. Different framings produce different conversations and the synthesis collapses.
+
+## The eight lenses
+
+Spawn one sub-agent per lens, all in the background, in parallel:
+
+| Lens | Brief |
+|---|---|
+| First Principles | Strip away assumptions. What is the actual problem at its most fundamental level? |
+| User Empathy | Forget the code. What does the person using this actually need? |
+| Simplifier | What can be deleted, removed, or skipped? The best solution might be no solution. |
+| Systems Thinker | Zoom out. What are the second-order effects? What breaks downstream? |
+| Contrarian | Take the opposite position of whatever seems obvious. |
+| Time Traveler | Six months from now, what will we wish we had done? |
+| Adversarial | Assume the current approach is wrong. Find the flaw, the hidden assumption that breaks under stress. |
+| Precedent | Has this been solved before? In this codebase, in open source, in a different domain entirely? |
+
+Continue the conversation with the user while the agents run. Do not block.
+
+## Synthesis
+
+When the eight return, write to `$SISYPHUS_SESSION_DIR/context/perspective-synthesis.md` covering:
+
+- **Convergence** — where multiple lenses pointed the same direction (signal worth trusting)
+- **Surprises** — which perspective said something nobody else did (potential breakthroughs)
+- **Insights** — name each key finding in a memorable sentence the user can carry forward
+
+Then render in the side pane:
+
+```bash
+termrender --tmux "$SISYPHUS_SESSION_DIR/context/perspective-synthesis.md"
+```
+
+Bail on non-zero exit with the file path and exit code.
+
+## Surface to the user
+
+Issue the synthesis deck. No `${var}` shell assignments needed; angle-bracket placeholders are pre-substituted:
+
+- `<one-line convergence>` — where multiple lenses pointed the same direction
+- `<one-line surprise>` — what a single lens said that nobody else did
+
+```bash
+synth_deck="$SISYPHUS_SESSION_DIR/context/.ask-problem-synth-$(date +%s)-$$.json"
+cat > "$synth_deck" <<EOF
+{
+  "interactions": [{
+    "id": "problem-perspective-synth",
+    "title": "Lens synthesis",
+    "subtitle": "After 8 perspective agents",
+    "body": "## In the side pane\n\n- Synthesis rendered via termrender — scroll and react below.\n\n## What I'm hearing\n\n- <one-line convergence>\n- <one-line surprise>",
+    "kind": "decision",
+    "options": [
+      {"id": "breakthrough",    "label": "Breakthrough — this lens reframes it"},
+      {"id": "useful",          "label": "Useful but not load-bearing"},
+      {"id": "wrong-direction", "label": "Wrong direction — discard"},
+      {"id": "mixed",           "label": "Mixed — see freetext"}
+    ],
+    "allowFreetext": true,
+    "freetextLabel": "Which lens, what landed, what's still missing"
+  }]
+}
+EOF
+result=$(sisyphus ask "$synth_deck") || { sisyphus agent submit "Synthesis deck failed — deck: $synth_deck"; exit 1; }
+[ -n "$result" ] || { sisyphus agent submit "Synthesis deck: empty result — deck: $synth_deck"; exit 1; }
+choice=$(echo "$result" | jq -r '.responses[0].selectedOptionId // empty')
+notes=$(echo  "$result" | jq -r '.responses[0].freetext // ""')
+```
+
+## Routing after synthesis
+
+All four option ids return to the dialogue loop's turn-deck flow.
+
+- `breakthrough`, `useful`, `mixed` — carry the synthesis forward into the next turn's framing (the next turn deck body should reference what landed)
+- `wrong-direction` — discards the synthesis but does not exit the loop
+- `notes` flows into the next turn's framing regardless of `choice`
+
+**Increment the turn counter `N`** before issuing the next turn deck. Skipping the increment produces two consecutive `Turn N — <lens>` subtitles with the same N, breaking inbox scannability.
+
+## Failure handling
+
+- If more than four of eight agents return errors, surface partial results if any returned cleanly, otherwise bail
+- If `termrender --tmux` fails on the synthesis render, bail with file path and exit code
+- If the synthesis deck fails or returns empty, bail with the deck path
+
+## Body content rules
+
+The deck `body` field uses `##` headings, bullet lists, and bold only — no tables, no code fences, no termrender directives.

package/dist/templates/agent-plugin/skills/problem-document/SKILL.md

@@ -0,0 +1,105 @@
+---
+name: problem-document
+description: >
+  Load when ready to draft `context/problem.md` — the thinking artifact that orients downstream agents (spec, plan, implement) to why the work exists. Provides design principles, the section vocabulary to pick from, and an anchor example showing the target style. Use this before writing the draft, not after.
+---
+
+# Designing the problem document
+
+The problem document is a **thinking artifact**, not a spec. Its job is to orient downstream agents (spec, plan, implement) to *why* the work exists — what hurts, what's the non-obvious trick, what matters, what's risky — tightly enough that they can read the whole thing in under thirty seconds.
+
+## Design principles
+
+- **Scannable, not exhaustive.** A downstream agent reads this once before doing real work. It needs to walk away with the right mental model, not every detail of the conversation that produced it.
+- **Sections are a vocabulary, not a checklist.** Use the sections that earn their place for *this* problem. Skip ones that don't. Add ones that do. Different problems need different shapes.
+- **Each section answers a question a downstream agent would ask:** "What hurts? What's the trick? What are we building? Why is it tricky? What does done look like? What can't we do? What's still up in the air?" If a section doesn't answer one of those, cut it.
+- **Tables and bullets do the structural work; prose fills gaps where tables would feel forced.** A central decision shown as a 2-row table is worth ten sentences of paragraph.
+- **No alternatives section.** The forks you considered and rejected lived in the conversation — they don't need to live in the artifact. Downstream agents care about the path forward, not the paths not taken.
+- **Length follows from clarity, not from rules.** When the thinking is crisp, the document is short on its own. If a section feels like it wants more words, the answer is usually to tighten the thinking, not expand the section.
+
+## Section vocabulary
+
+Pick what earns its place; rename freely.
+
+- **The pain / what's wrong** — what hurts and why now
+- **Key insight** — the non-obvious understanding that reframes the problem
+- **What we're building** — the artifact(s) or change(s) the work produces
+- **Why it's tricky** — failure modes, mental traps, things that defeat the obvious approach
+- **What success looks like** — concrete outcomes, not metrics theater
+- **Constraints** — what bounds the solution (not assumptions, not anti-goals — actual bounds)
+- **Open questions** — unresolved choices the next phase needs to make
+
+## Anchor example
+
+This is the target style — terse, scannable, structured by what serves the content rather than by template:
+
+<example>
+# Session debugging is too expensive to do
+
+## The pain
+When a sisyphus session produces unexpected output, the maintainer can't
+cheaply learn from it. The choice is between re-teaching Claude the
+architecture every conversation, or doing manual archaeology across raw
+JSONL files. Both are expensive enough that the learning loop gets skipped
+entirely.
+
+## Key insight
+The data is already on disk — sisyphus just doesn't read it. Every agent's
+full transcript lives at `~/.claude/projects/<cwd>/<sessionId>.jsonl` with
+file touches, tokens, subagent spawns, and timing. The fix is a reader, not
+new instrumentation.
+
+## The two artifacts
+
+| What | Why it's needed |
+|---|---|
+| **Debugging toolkit** (CLI verbs) | Cheap "what happened in session X" lookups Claude can compose with grep/jq |
+| **Architecture skill** (SKILL.md) | A mental model Claude can pull when reasoning about sisyphus runtime — the novel multi-agent design defeats its priors |
+
+Useless apart, powerful together. The toolkit answers *what*; the skill
+answers *how to make sense of what*.
+
+## Why the skill matters
+
+Claude's failure modes when reasoning about sisyphus are predictable:
+- Treats the orchestrator as a long-running process with memory (it's
+  stateless, fork-per-cycle)
+- Conflates sisyphus-managed agents with Claude-Code-managed Task-tool
+  subagents
+- Misses that "completed" means three different things at three levels
+- Loses track of which channel agents communicate over
+
+These aren't undocumented — they're scattered across CLAUDE.md files framed
+as traps, not mental models. The skill is synthesis with decision heuristics,
+not new philosophy.
+
+## What success looks like
+
+- Maintainer says "investigate session X", Claude pulls the skill, runs a
+  couple of CLI queries, gives a grounded diagnosis citing real file paths
+  and JSONL evidence — no re-teaching
+- Same skill loads automatically for high-level architecture discussions,
+  not just debugging
+- Zero new instrumentation — derived from data already on disk plus a
+  one-line fix to complete an existing index
+
+## Constraints
+
+- Claude Code JSONL format isn't a stable contract — reader must degrade
+  gracefully if Anthropic changes it
+- Codex/OpenAI agents have no equivalent transcript — known blind spot,
+  not in scope
+
+## Open questions
+
+- Skill scope: one broad "sisyphus" skill (architecture + debugging) or
+  split into two?
+- Pre-fix sessions: accept they're harder to debug, or add an mtime-proximity
+  fallback in the reader?
+</example>
+
+Notice what this example *doesn't* have: no "Alternatives Considered," no "Assumptions" section, no "User Experience" header (folded into success), no "Anti-Goals." Each section earned its place because the content needed it. A different problem would skip "Why the skill matters" and add "Migration path" or "User flows" — whatever the content demands.
+
+## Bifurcation case
+
+If the conversation revealed that the scope contains **independent sub-problems** rather than one problem with sub-parts, do not write a unified `problem.md`. Instead, use the bifurcation-exit pattern from the agent prompt — the orchestrator handles re-entering discovery for each sub-problem.

package/dist/templates/agent-plugin/skills/problem-plateau-breakers/SKILL.md

@@ -0,0 +1,83 @@
+---
+name: problem-plateau-breakers
+description: >
+  Load when the problem-agent dialogue loop signals the conversation has stalled — repeated circling, user freetext like "different angle" / "going nowhere" / "feels stuck", or the agent senses it has been chasing the same framing for several turns without traction. Provides four breaker-deck shapes (flip, zoom-out, zoom-in, name-tension) and the routing for each. Increments the turn counter and returns control to the dialogue loop.
+---
+
+# Plateau-breaker decks
+
+When the conversation circles, the user wants a *different shape of question*, not another variation of the same one. Pick the breaker whose move matches the stall pattern, issue the deck, then resume the turn loop.
+
+## Pick the breaker type
+
+| Type | Use when | Move |
+|---|---|---|
+| `flip` | The conversation keeps assuming a position is correct | Embrace the opposite — what changes if we believed the inverse? |
+| `zoom-out` | The conversation is litigating details before establishing whether they matter | Step back — does this distinction even change the outcome? |
+| `zoom-in` | The conversation is trading abstractions without testing them against a real case | Pick a concrete scenario and see if the framing survives |
+| `name-tension` | Two values are being held in tension without naming the trade-off | Surface the tension itself as the question |
+
+Choose one per stall. Do not chain breakers — if a breaker doesn't unstick the conversation, the next one is the *next* stall, counted toward the repeated-stuck guard.
+
+## Issue the deck
+
+Required prior assignments before the heredoc:
+- `type` — one of `flip` / `zoom-out` / `zoom-in` / `name-tension`
+
+Angle-bracket placeholders (substitute literally before writing the heredoc):
+- `<observation>` — what the conversation has been circling
+- `<reframe>` — provisional alternative tied to the breaker type
+
+```bash
+type=flip  # or zoom-out / zoom-in / name-tension
+deck="$SISYPHUS_SESSION_DIR/context/.ask-problem-plateau-${type}-$(date +%s)-$$.json"
+cat > "$deck" <<EOF
+{
+  "interactions": [{
+    "id": "problem-plateau-${type}",
+    "title": "Plateau breaker",
+    "subtitle": "Plateau breaker — ${type}",
+    "body": "## Stalled\n\n- <observation>\n\n## Reframe\n\n- <reframe>",
+    "kind": "decision",
+    "options": [
+      <options for this type — see table below>
+    ],
+    "allowFreetext": true,
+    "freetextLabel": "Or describe the angle differently"
+  }]
+}
+EOF
+result=$(sisyphus ask "$deck") || { sisyphus agent submit "Plateau-breaker deck failed — type: $type — deck: $deck"; exit 1; }
+[ -n "$result" ] || { sisyphus agent submit "Plateau-breaker deck: empty result — type: $type — deck: $deck"; exit 1; }
+choice=$(echo "$result" | jq -r '.responses[0].selectedOptionId // empty')
+notes=$(echo  "$result" | jq -r '.responses[0].freetext // ""')
+```
+
+## Per-breaker options
+
+Pre-substitute the matching row before writing the heredoc:
+
+| `type` | Options (id / label) |
+|---|---|
+| `flip` | `embrace-flipped` / "Embrace the flipped position" · `stick-original` / "Stick with original" · `merge-both` / "Merge both" |
+| `zoom-out` | `drop-doesnt-matter` / "Doesn't matter — drop" · `smaller-scope` / "Matters but smaller" · `matters-as-is` / "Matters as is" |
+| `zoom-in` | `scenario-breaks-it` / "This scenario breaks it" · `scenario-holds` / "Scenario holds" · `different-scenario` / "Different scenario" |
+| `name-tension` | `pick-side-A` / "Pick A" · `pick-side-B` / "Pick B" · `tension-itself` / "The tension itself is the problem" |
+
+## After the response
+
+Increment the turn counter `N` and return to the dialogue loop's turn-deck flow. The user's `choice` and `notes` flow into the next turn's framing.
+
+## Body content rules
+
+The deck `body` field uses `##` headings, bullet lists, and bold only — no tables, no code fences, no termrender directives. Violations fail `termrender --check` inside `parseDeck`.
+
+## Sanitize freetext on bail
+
+If you bail with the user's freetext in the message, sanitize it first:
+
+```bash
+safe_notes=$(printf '%s' "$notes" | tr -d '`$"\\')
+```
+
+Raw `"$notes"` in a shell-interpolated bail message is a defect.

package/dist/templates/agent-suffix.md

@@ -3,11 +3,10 @@
 You are an agent in a sisyphus session.
 
 - **Session ID**: {{SESSION_ID}}
-- **Your Task**: {{INSTRUCTION}}
 
 ## Reports
 
-Reports are non-terminal — you keep working after sending them. Use `sisyphus report` to flag things the orchestrator needs to know about:
+Reports are non-terminal — you keep working after sending them. Use `sisyphus agent report` to flag things the orchestrator needs to know about:
 
 - **Code smells** — unexpected complexity, unclear architecture, code that seems wrong
 - **Out-of-scope issues** — failing tests, missing error handling, broken assumptions
@@ -16,7 +15,7 @@ Reports are non-terminal — you keep working after sending them. Use `sisyphus
 Report problems rather than working around them — the orchestrator can route these to the right agent. Stay focused on your task.
 
 ```bash
-echo "src/auth.ts:45 — session token not refreshed on redirect, circular dep between auth and session modules" | sisyphus report
+echo "src/auth.ts:45 — session token not refreshed on redirect, circular dep between auth and session modules" | sisyphus agent report
 ```
 
 ## Finishing
@@ -24,7 +23,7 @@ echo "src/auth.ts:45 — session token not refreshed on redirect, circular dep b
 When done, submit your final report via the CLI. This is terminal — your pane closes after.
 
 ```bash
-echo "your full report here" | sisyphus submit
+echo "your full report here" | sisyphus agent submit
 ```
 
 If you're blocked by ambiguity, contradictions, or unclear requirements — **don't guess**. Submit what you found instead. A clear report is more valuable than a wrong implementation.
@@ -33,6 +32,10 @@ If you're blocked by ambiguity, contradictions, or unclear requirements — **do
 
 A human may interact with you directly in your pane — if they do, prioritize their input over your original instruction. Otherwise, communicate through the orchestrator via reports. 
 
+## Context
+
+Session context directory: @{{CONTEXT_DIR}}
+
 ## Guidelines
 
 - Always include exact file paths and line numbers in reports and submissions

package/dist/templates/baleia.lua

@@ -0,0 +1,42 @@
+-- Sisyphus: ANSI escape code rendering for neovim
+-- Auto-detects buffers containing ANSI escape codes and colorizes them.
+-- Installed by `sisyphus admin setup`. Safe to customize or remove.
+return {
+  "m00qek/baleia.nvim",
+  version = "*",
+  event = "BufReadPost",
+  config = function()
+    local b = require("baleia").setup({ async = false })
+
+    local function has_ansi(buf)
+      local count = vim.api.nvim_buf_line_count(buf)
+      local lines = vim.api.nvim_buf_get_lines(buf, 0, math.min(100, count), false)
+      for _, line in ipairs(lines) do
+        if line:find("\27%[") then
+          return true
+        end
+      end
+      return false
+    end
+
+    -- Colorize the buffer that triggered the plugin load
+    if has_ansi(0) then
+      b.once(0)
+    end
+
+    -- Auto-detect for all future buffers
+    vim.api.nvim_create_autocmd("BufReadPost", {
+      callback = function(ev)
+        if has_ansi(ev.buf) then
+          vim.defer_fn(function()
+            b.once(ev.buf)
+          end, 10)
+        end
+      end,
+    })
+
+    vim.api.nvim_create_user_command("BaleiaColorize", function()
+      b.once(vim.api.nvim_get_current_buf())
+    end, {})
+  end,
+}

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

@@ -1,3 +1,3 @@
 #!/bin/bash
 if [ -z "$SISYPHUS_COMPANION_CWD" ]; then exit 0; fi
-sisyphus companion-context --cwd "$SISYPHUS_COMPANION_CWD" 2>/dev/null
+sisyphus companion context --cwd "$SISYPHUS_COMPANION_CWD" 2>/dev/null

package/dist/templates/dashboard-claude.md

@@ -18,9 +18,13 @@ Session context is injected automatically via hook on each prompt. Run `sisyphus
 ```
 sisyphus list                                    # List sessions for this project
 sisyphus status <session-id>                     # Show detailed session status
-sisyphus message "<content>" --session <id>      # Queue message for orchestrator
-sisyphus kill <session-id>                       # Kill a session and all its agents
-sisyphus resume <session-id> "instructions"      # Resume a completed/paused session
+sisyphus message "<content>" --session <id>      # Queue message for orchestrator (read on next cycle)
+sisyphus tell <target> "<text>" --session <id>   # Type prompt directly into a running pane (immediate); target = orchestrator | agent-NNN
+                                                 #   --no-submit pastes without pressing Enter; --text-from-stdin reads body from stdin
+sisyphus read <target> --session <id>            # Print Claude conversation transcript for a target
+                                                 #   --tail N / --head N to slice; --summary for one-line-per-turn; --cycle N for a specific orchestrator cycle
+sisyphus session kill <session-id>               # Kill a session and all its agents
+sisyphus session resume <session-id> "instructions"  # Resume a completed/paused session
 sisyphus start "task"                            # Start a new orchestrated session
 sisyphus start "task" -c "background context"    # Start with additional context
 ```