sisyphi 1.1.25 → 1.1.27

package/dist/templates/orchestrator-completion.md

@@ -38,26 +38,26 @@ The user already knows what they asked for — don't recap the goal. Focus on wh
 
 Use tables, diagrams, and structured markdown freely — the deck below renders the file via `bodyPath`, so termrender directives are styled in the user's resolution view. Keep it tight but visually clear. If the session was straightforward, the summary should be short. Save the detail for when the user asks.
 
-## Ask for Sign-off via `sisyphus ask`
+## Ask for Sign-off via `sis ask`
 
-Submit a structured deck pointing at `completion-summary.md` via `bodyPath`. The CLI blocks until the user resolves the ask in their dashboard inbox, then prints the JSON response. **NEVER call `sisyphus session complete` until the user picks `approve`.**
+Submit a structured deck pointing at `completion-summary.md` via `bodyPath`. The CLI blocks until the user resolves the ask in their dashboard inbox, then prints the JSON response. **NEVER call `sis session complete` until the user picks `approve`.**
 
 Read the `humanloop` skill for option design and submission flow. The completion deck is the canonical four-branch sign-off — `approve` / `minor` / `moderate` / `major` — each routes to a different recovery (see "Handle Feedback" below). Use `bodyPath: "../completion-summary.md"` so the user reviews the rendered summary inside the deck.
 
 ```bash
-result=$(sisyphus ask "$deck")
+result=$(sis ask "$deck")
 choice=$(echo "$result" | jq -r '.responses[0].selectedOptionId')
 notes=$(echo "$result"  | jq -r '.responses[0].freetext // ""')
 ```
 
-Orchestrator blocks here — `sisyphus ask` waits internally; do not add any extra "wait for user" step. See `sisyphus ask -h` for CLI syntax.
+Orchestrator blocks here — `sis ask` waits internally; do not add any extra "wait for user" step. See `sis ask -h` for CLI syntax.
 
 ## Handle Feedback
 
 Branch on `$choice`:
 
 ### `approve` — finalize
-Call `sisyphus session complete` (see Finalizing below). `$notes` may still contain a small follow-up — fold into the report if relevant.
+Call `sis session complete` (see Finalizing below). `$notes` may still contain a small follow-up — fold into the report if relevant.
 
 ### `minor` — typo, rename, small fix, cosmetic tweak
 Fix it yourself directly using `$notes` as the spec. Then update `completion-summary.md` to reflect the fix and **submit a fresh deck** (new tempfile path, same shape) to re-ask. Multiple rounds of minor fixes are fine — stay in the loop.
@@ -72,7 +72,7 @@ These need agents. Use `$notes` to capture the items raised, then:
 3. Yield back to implementation (or planning if the fix requires design):
 
 ```bash
-sisyphus orch yield --mode implementation --prompt "User review surfaced issues to fix: $notes. See roadmap.md for details."
+sis orch yield --mode implementation --prompt "User review surfaced issues to fix: $notes. See roadmap.md for details."
 ```
 
 If a single deck round surfaces multiple moderate items, capture them all in `$notes` (the freetext field) — don't ask again in the same cycle to collect more.
@@ -85,7 +85,7 @@ These change the goal itself:
 3. Yield to discovery mode:
 
 ```bash
-sisyphus orch yield --mode discovery --prompt "User requested significant scope change: $notes. Goal and strategy updated — re-evaluate approach."
+sis orch yield --mode discovery --prompt "User requested significant scope change: $notes. Goal and strategy updated — re-evaluate approach."
 ```
 
 ## Context Management
@@ -93,7 +93,7 @@ sisyphus orch yield --mode discovery --prompt "User requested significant scope
 If the conversation runs long (many rounds of minor fixes, extended discussion), yield back to completion mode with a progress summary so you get fresh context:
 
 ```bash
-sisyphus orch yield --mode completion --prompt "User review in progress. Fixed: [list]. Still discussing: [list]. Awaiting final confirmation."
+sis orch yield --mode completion --prompt "User review in progress. Fixed: [list]. Still discussing: [list]. Awaiting final confirmation."
 ```
 
 ## Finalizing
@@ -101,7 +101,7 @@ sisyphus orch yield --mode completion --prompt "User review in progress. Fixed:
 Only after `$choice == "approve"` — call:
 
 ```bash
-sisyphus session complete --report "summary of what was accomplished"
+sis session complete --report "summary of what was accomplished"
 ```
 
 The report should be a concise summary suitable for session history. Reference the full completion report you presented if needed.
@@ -109,6 +109,6 @@ The report should be a concise summary suitable for session history. Reference t
 ## Completion CLI
 
 ```bash
-sisyphus session complete --report "summary of what was accomplished"  # finalize session (only after user confirms)
-sisyphus session continue "new instructions"                           # reactivate a completed session
+sis session complete --report "summary of what was accomplished"  # finalize session (only after user confirms)
+sis session continue "new instructions"                           # reactivate a completed session
 ```

package/dist/templates/orchestrator-discovery.md

@@ -41,7 +41,7 @@ cat > "$decomp_deck" <<'EOF'
   }]
 }
 EOF
-sisyphus ask "$decomp_deck"
+sis ask "$decomp_deck"
 ```
 
 If the user picks one, record the others in `goal.md` under a "Known follow-ups" section, then proceed with the chosen one through the rest of discovery.
@@ -116,7 +116,7 @@ cat > "$confirm_deck" <<'EOF'
   }]
 }
 EOF
-sisyphus ask "$confirm_deck"
+sis ask "$confirm_deck"
 ```
 
 **Branching:**
@@ -140,7 +140,7 @@ Pick the tier by **novelty of behavior**, not file count:
 - New subsystem / new protocol / cross-domain orchestration: **HIGH**
 - Novel concurrency / new security boundary / multi-system contract: **XHIGH**
 
-Apply the tier with `sisyphus session effort <low|medium|high|xhigh>` — this filters the strategy skill, mode templates, and agent prompts on subsequent cycles so you only see the guidance that applies. The user can override at any point.
+Apply the tier with `sis session effort <low|medium|high|xhigh>` — this filters the strategy skill, mode templates, and agent prompts on subsequent cycles so you only see the guidance that applies. The user can override at any point.
 
 If you change the tier mid-session because scope shifted, the next cycle's prompts adjust automatically; don't manually patch `strategy.md` to match — re-invoke the strategy skill.
 
@@ -171,13 +171,13 @@ After writing `goal.md` and `strategy.md`, initialize `roadmap.md`. Populate Cur
 Once `goal.md`, `strategy.md`, and `roadmap.md` are written and the goal is confirmed:
 
 ```bash
-sisyphus orch yield --mode planning --prompt "Discovery complete — goal.md, strategy.md, and roadmap.md initialized. Begin first stage."
+sis orch yield --mode planning --prompt "Discovery complete — goal.md, strategy.md, and roadmap.md initialized. Begin first stage."
 ```
 
 If you're still working on goal clarity (waiting for problem agent, re-entering after bifurcation, iterating with user), stay in discovery:
 
 ```bash
-sisyphus orch yield --mode discovery --prompt "Goal still being refined — [what's happening, what's next]."
+sis orch yield --mode discovery --prompt "Goal still being refined — [what's happening, what's next]."
 ```
 
 </transition>

package/dist/templates/orchestrator-impl.md

@@ -103,7 +103,7 @@ A clean report ("No concerns") is a valid and common outcome. When you get one,
 Aggregate reviewer findings. Spawn fix agents and **point them at the review report** — don't rewrite findings as line-by-line instructions. You triage (skip false positives, note architectural constraints) — they implement.
 
 ```bash
-sisyphus agent spawn --name "fix-review-issues" --agent-type sisyphus:implement \
+sis agent spawn --name "fix-review-issues" --agent-type sisyphus:implement \
   "Fix the issues in reports/agent-003-final.md. Skip item #5 (false positive). Run type-check after."
 ```
 
@@ -121,7 +121,7 @@ This is a deliberate choice, not an oversight. Re-reviewing has two failure mode
 If the fix agent's own report flags that it hit unexpected complexity or introduced something it wasn't comfortable with, address that specifically — read the code, decide, don't spawn another reviewer. If the single review pass surfaces findings that suggest an architectural problem rather than code-level issues, backtrack to planning instead of patching:
 
 ```bash
-sisyphus orch yield --mode planning --prompt "Review surfaced architectural issue: [summary]. Needs replan, not fixes."
+sis orch yield --mode planning --prompt "Review surfaced architectural issue: [summary]. Needs replan, not fixes."
 ```
 
 Real regressions from fix agents are caught by e2e validation (next step), not by a second review pass.
@@ -146,7 +146,7 @@ If the project lacks validation tooling, **create it** — a smoke-test script,
 **Phase-scoped plans:** if the current plan only covers one phase of a multi-phase feature (the plan-lead convention when `strategy.md` has multiple phases), yield back to planning after this phase's validation passes — not to validation mode. Plan files live under `context/{plan-lead-agent-id}/`; use the paths the plan lead reported when dispatching implement agents.
 
 ```bash
-sisyphus orch yield --mode planning --prompt "Phase N validated. Plan phase N+1 per strategy.md."
+sis orch yield --mode planning --prompt "Phase N validated. Plan phase N+1 per strategy.md."
 ```
 
 The next cycle's plan lead incorporates what you learned here before committing phase N+1 to paper.
@@ -154,7 +154,7 @@ The next cycle's plan lead incorporates what you learned here before committing
 When all implementation phases are complete (the final phase has been planned, implemented, and stage-validated), transition to validation mode for the comprehensive final pass:
 
 ```bash
-sisyphus orch yield --mode validation --prompt "All stages implemented — validate against context/e2e-recipe.md"
+sis orch yield --mode validation --prompt "All stages implemented — validate against context/e2e-recipe.md"
 ```
 
 Validation mode shifts the orchestrator's entire focus to proving the feature works. Stage-level validation during implementation catches issues early; the final validation pass proves the whole thing holds together.
@@ -166,7 +166,7 @@ Validation mode shifts the orchestrator's entire focus to proving the feature wo
 If the approach is wrong mid-implementation, don't keep pushing. Return to planning:
 
 ```bash
-sisyphus orch yield --mode planning --prompt "Discovered X mid-implementation — approach needs rework. See cycle log and roadmap.md."
+sis orch yield --mode planning --prompt "Discovered X mid-implementation — approach needs rework. See cycle log and roadmap.md."
 ```
 
 Concrete triggers:
@@ -183,9 +183,9 @@ Update roadmap.md to reflect you're back in an earlier phase. Log the discovery
 ## Implementation CLI
 
 ```bash
-sisyphus session task "revised goal"                      # update the session goal mid-flight
-sisyphus agent restart <agentId>                         # respawn a failed/killed agent in a new pane
-sisyphus session rollback <sessionId> <cycle>            # rewind state to a prior cycle boundary
+sis session task "revised goal"                      # update the session goal mid-flight
+sis agent restart <agentId>                         # respawn a failed/killed agent in a new pane
+sis session rollback <sessionId> <cycle>            # rewind state to a prior cycle boundary
 ```
 
 </impl-cli>

package/dist/templates/orchestrator-planning.md

@@ -113,7 +113,7 @@ plan phase 1 → implement phase 1 → validate phase 1 → plan phase 2 → imp
 After a phase's implementation passes e2e validation, yield back to planning mode for the next phase:
 
 ```bash
-sisyphus orch yield --mode planning --prompt "Phase N validated. Plan phase N+1 per strategy.md."
+sis orch yield --mode planning --prompt "Phase N validated. Plan phase N+1 per strategy.md."
 ```
 
 When spawning the phase-scoped plan lead, name in the prompt:
@@ -140,9 +140,9 @@ Signs you need phased development: multiple unfamiliar subsystems, the task span
 
 Before implementation begins, determine how to concretely verify the change works end-to-end. This is the single most common failure mode: agents report success but nothing actually works.
 
-If you cannot determine a concrete verification method, **ask the user via `sisyphus ask`**. Propose 2-4 candidate verification approaches as options (not an open-ended question). Do not proceed to implementation without a verification plan.
+If you cannot determine a concrete verification method, **ask the user via `sis ask`**. Propose 2-4 candidate verification approaches as options (not an open-ended question). Do not proceed to implementation without a verification plan.
 
-Before authoring the deck, **read the `humanloop` skill** for option-design guidance and submission flow. Ground options in this feature's actual surface (manual UI? integration test? log inspection? metric delta?) — not generic placeholders. `sisyphus ask -h` covers CLI syntax.
+Before authoring the deck, **read the `humanloop` skill** for option-design guidance and submission flow. Ground options in this feature's actual surface (manual UI? integration test? log inspection? metric delta?) — not generic placeholders. `sis ask -h` covers CLI syntax.
 
 Write the recipe to `context/e2e-recipe.md` with setup steps, exact commands or interactions to verify, and what success looks like. Make it executable, not aspirational. Implementation agents and validation agents both reference this file.
 
@@ -153,7 +153,7 @@ Write the recipe to `context/e2e-recipe.md` with setup steps, exact commands or
 ## Planning CLI
 
 ```bash
-sisyphus admin requirements --export --session-id <id>  # render requirements.json → requirements.md (no LLM tokens)
+sis admin requirements --export --session-id <id>  # render requirements.json → requirements.md (no LLM tokens)
 ```
 
 The requirements export renders a `requirements.json` to markdown without consuming LLM tokens.
@@ -165,7 +165,7 @@ The requirements export renders a `requirements.json` to markdown without consum
 When you have enough understanding, a reviewed plan, and a verification recipe — transition explicitly:
 
 ```bash
-sisyphus orch yield --mode implementation --prompt "Begin implementation — see roadmap.md and the plan file path the plan lead reported (under context/{plan-lead-agent-id}/)."
+sis orch yield --mode implementation --prompt "Begin implementation — see roadmap.md and the plan file path the plan lead reported (under context/{plan-lead-agent-id}/)."
 ```
 
 The `--mode implementation` flag loads implementation-phase guidance for the next cycle.
@@ -173,7 +173,7 @@ The `--mode implementation` flag loads implementation-phase guidance for the nex
 After implementation is complete, transition to validation mode to prove the feature works:
 
 ```bash
-sisyphus orch yield --mode validation --prompt "Implementation complete — validate against context/e2e-recipe.md"
+sis orch yield --mode validation --prompt "Implementation complete — validate against context/e2e-recipe.md"
 ```
 
 </transition>

package/dist/templates/orchestrator-plugin/commands/sisyphus/scratch.md

@@ -11,7 +11,7 @@ The user wants to spin up a standalone Claude Code session — outside sisyphus
 Run the following in bash:
 
 ```bash
-sisyphus admin scratch "$ARGUMENTS"
+sis admin scratch "$ARGUMENTS"
 ```
 
 This opens a new tmux window in the home session with `claude --dangerously-skip-permissions`. Do not track it, wait for it, or reference it in the roadmap. It's fire-and-forget.

package/dist/templates/orchestrator-plugin/commands/sisyphus/strategize.md

@@ -10,10 +10,10 @@ The user wants to redirect this session's strategy.
 
 ## Steps
 
-1. If the session is completed (`sisyphus status`), reactivate it with `sisyphus session continue`.
+1. If the session is completed (`sis status`), reactivate it with `sis session continue`.
 2. Invoke the **strategy skill** to annotate `strategy.md` with the pivot — what changed, new focus, which existing artifacts still apply. Don't rewrite the whole strategy.
 3. Yield to discovery mode:
    ```bash
-   sisyphus orch yield --mode discovery --prompt "<concise description of the new direction>"
+   sis orch yield --mode discovery --prompt "<concise description of the new direction>"
    ```
    This respawns a fresh orchestrator that will re-evaluate the goal, stages, and approach.

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

@@ -1,14 +1,14 @@
 ---
 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 invoke synchronously so the orchestrator's process blocks until the user answers.
+  Read before calling `sis 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 invoke synchronously so the orchestrator's process blocks until the user answers.
 ---
 
 # 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.
+`sis 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).
+This skill covers **what to put in a deck** and **how to invoke it**. Run `sis ask -h` for the CLI shape (file path, `--session`, the `poll` and `peek` subcommands).
 
 ## Reach for a deck when
 
@@ -25,19 +25,19 @@ This skill covers **what to put in a deck** and **how to invoke it**. Run `sisyp
 
 ## How to invoke
 
-**Run `sisyphus ask` in the foreground — let the Bash tool block.** The CLI waits internally for the user to resolve the deck (potentially 10+ minutes). Your pane stays alive in tmux for the duration; the daemon will not respawn you while a tool call is in flight. When the user answers, the bash returns stdout and you parse it inline.
+**Run `sis ask` in the foreground — let the Bash tool block.** The CLI waits internally for the user to resolve the deck (potentially 10+ minutes). Your pane stays alive in tmux for the duration; the daemon will not respawn you while a tool call is in flight. When the user answers, the bash returns stdout and you parse it inline.
 
 ```bash
-result=$(sisyphus ask "$deck")
+result=$(sis ask "$deck")
 choice=$(echo "$result" | jq -r '.responses[0].selectedOptionId')
 notes=$(echo "$result"  | jq -r '.responses[0].freetext // ""')
 ```
 
-**Do not `run_in_background` and yield** — yielding kills your pane and any backgrounded bash with it; the next cycle's fresh orchestrator can only peek the on-disk deck (`sisyphus ask peek`) and yield again, producing a polling loop. The daemon now refuses `sisyphus orch yield` while a deck owned by orchestrator is pending; the supported pattern is foreground.
+**Do not `run_in_background` and yield** — yielding kills your pane and any backgrounded bash with it; the next cycle's fresh orchestrator can only peek the on-disk deck (`sis ask peek`) and yield again, producing a polling loop. The daemon now refuses `sis orch yield` while a deck owned by orchestrator is pending; the supported pattern is foreground.
 
 Stdout on completion is one line of JSON: `{responses: [{id, selectedOptionId?, freetext?}, ...], completedAt}`. Branch on each response by its interaction `id`.
 
-If you respawn mid-wait and find a pending deck on disk (e.g. after a daemon restart that orphaned the prior bash), block on it with `sisyphus ask poll <askId>` to re-attach. `sisyphus ask peek <askId>` is non-blocking and reserved for respawn-recovery diagnostics. See `sisyphus ask -h`.
+If you respawn mid-wait and find a pending deck on disk (e.g. after a daemon restart that orphaned the prior bash), block on it with `sis ask poll <askId>` to re-attach. `sis ask peek <askId>` is non-blocking and reserved for respawn-recovery diagnostics. See `sis ask -h`.
 
 ## Designing interactions
 
@@ -137,7 +137,7 @@ cat > "$deck" <<'EOF'
   ]
 }
 EOF
-# Then invoke `sisyphus ask "$deck"` synchronously (foreground bash) — blocks until answered.
+# Then invoke `sis ask "$deck"` synchronously (foreground bash) — blocks until answered.
 # Each interaction returns its own selectedOptionId / freetext in output.responses[], indexed by id.
 ```
 
@@ -147,4 +147,4 @@ EOF
 - `kind` is an enum: `notify` | `validation` | `decision` | `context` | `error`. No other values accepted (see the table above for which to pick).
 - `bodyPath` points at a markdown file instead of inlining the body in JSON. The path is resolved **relative to the deck JSON's directory** and must stay inside it (no `..`, no symlinks out, no absolute paths pointing elsewhere). Practical pattern: write the deck JSON next to its body file — e.g. both inside `$SISYPHUS_SESSION_DIR/context/` — and use a basename like `"completion-summary.md"`. Mutually exclusive with `body`.
 - 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.
+- See `sis ask -h` for the full CLI surface.

package/dist/templates/orchestrator-plugin/skills/orchestration/CLAUDE.md

@@ -1 +1 @@
-- `sisyphus orch yield --mode discovery`, `--mode validation`, etc. must be explicit at mode-transition cycles. Omitting silently defaults to `implementation` mode, skipping guardrails the subsequent cycle expects.
+- `sis orch yield --mode discovery`, `--mode validation`, etc. must be explicit at mode-transition cycles. Omitting silently defaults to `implementation` mode, skipping guardrails the subsequent cycle expects.

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

@@ -22,7 +22,7 @@ How to structure sisyphus sessions for common task types. This skill helps the o
 
 ## Agent Types
 
-Available agent types are listed under **Available Agent Types** in your prompt. Use `--agent-type` with `sisyphus agent spawn`.
+Available agent types are listed under **Available Agent Types** in your prompt. Use `--agent-type` with `sis agent spawn`.
 
 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/skills/orchestration/strategy.md

@@ -52,7 +52,7 @@ When you're tempted to name a stage after a code area, that signals you're sketc
 
 ## Default Pipeline Shape
 
-The session's effort tier dictates the default pipeline. **Use this shape unless the problem explicitly demands more or less.** The user can change tiers via `sisyphus session effort <low|medium|high|xhigh>`.
+The session's effort tier dictates the default pipeline. **Use this shape unless the problem explicitly demands more or less.** The user can change tiers via `sis session effort <low|medium|high|xhigh>`.
 
 <!--EFFORT:LOW-->
 **Pipeline:** `plan → implement → validate`
@@ -72,7 +72,7 @@ Add `sisyphus:review-plan` only when the plan covers multi-domain integration. A
 `sisyphus:review-plan` runs after the plan is drafted. `sisyphus:spec` spawns whenever a feature adds user-visible behavior. `sisyphus:problem` spawns when the goal is nebulous. Append `+ test-spec` to the planning stage **only when the user's initial prompt or goal.md explicitly requested tests** (e.g. "with tests", "TDD", "include unit tests", "test coverage"); silence is a "no." When justified, `sisyphus:test-spec` spawns in parallel with the high-level plan at Cycle 2, not after implementation — post-implementation test-spec silently describes what the code does rather than what it should do.
 <!--/EFFORT-->
 
-**Re-evaluate the tier when scope shifts mid-session.** A MEDIUM feature that uncovers a new subsystem may have crossed into HIGH; a HIGH feature whose scope was narrowed may have dropped to MEDIUM. Re-run `sisyphus session effort` and re-invoke this skill rather than continuing under the old tier's pipeline.
+**Re-evaluate the tier when scope shifts mid-session.** A MEDIUM feature that uncovers a new subsystem may have crossed into HIGH; a HIGH feature whose scope was narrowed may have dropped to MEDIUM. Re-run `sis session effort` and re-invoke this skill rather than continuing under the old tier's pipeline.
 
 ## Choosing a Different Shape
 
@@ -146,8 +146,8 @@ When the work in flight reveals the strategy itself is off, escalate up this lad
 
 1. **Revise in place.** Stage detail evolved but the pipeline shape holds. Edit `strategy.md` and `roadmap.md`; continue.
 2. **`sisyphus:strategize`.** Approach is wrong but artifacts (specs, explorations, reports) still apply. Annotates the pivot into `strategy.md` and yields `--mode discovery` with a fresh orchestrator.
-3. **`sisyphus session clone <goal>`.** The session is actually two (or more) independent projects. Forks scope into a new top-level session; update `goal.md`/`roadmap.md` here to drop what was cloned.
-4. **`sisyphus session rollback <sessionId> <cycle>`.** A specific cycle introduced state to discard. Rewinds and pauses the session — cycles after the target are lost. Last resort; the others preserve history.
+3. **`sis session clone <goal>`.** The session is actually two (or more) independent projects. Forks scope into a new top-level session; update `goal.md`/`roadmap.md` here to drop what was cloned.
+4. **`sis session rollback <sessionId> <cycle>`.** A specific cycle introduced state to discard. Rewinds and pauses the session — cycles after the target are lost. Last resort; the others preserve history.
 
 When the user is the source of the change, update `goal.md` first — strategy revision is downstream of goal.
 

package/dist/templates/orchestrator-plugin/skills/orchestration/task-patterns.md

@@ -97,7 +97,7 @@ Note: critique and validation are embedded between implementation phases, not de
 - **Cycle 5**: Spawn `sisyphus:implement` for Phase 2. Phase 1 is types — low risk, doesn't need its own validation. Yield.
 - **Cycle 6**: Spawn `sisyphus:review` for critique of phases 1-2. This is the checkpoint before integration builds on top. Yield.
 - **Cycle 7**: Address critique findings + spawn `sisyphus:implement` for Phase 3. Yield.
-- **Cycle 8**: `sisyphus orch yield --mode validation` for e2e smoketest. Validation mode proves the feature works — operator for UI, evidence for every claim.
+- **Cycle 8**: `sis orch yield --mode validation` for e2e smoketest. Validation mode proves the feature works — operator for UI, evidence for every claim.
 - **Cycle 9**: Address validation failures (back to `--mode implementation`) or complete.
 
 ### Failure modes
@@ -153,7 +153,7 @@ Note: verification checkpoints are embedded in the stage outline, not deferred t
 - **Cycle 7**: Address critique findings. Spawn `sisyphus:implement` for stage 3. Yield.
 - **Cycle 8**: Spawn `sisyphus:implement` for stage 4. Spawn `sisyphus:review` to critique stage 3 in parallel. Yield.
 - **Cycle 9**: Spawn `sisyphus:validate` for stages 3-4 — core logic checkpoint before integration. Address stage 3 critique. Yield.
-- **Cycle 10+**: Implement integration stage. Final review. Then `sisyphus orch yield --mode validation` for comprehensive e2e proof.
+- **Cycle 10+**: Implement integration stage. Final review. Then `sis orch yield --mode validation` for comprehensive e2e proof.
 
 ### Failure modes
 - **Detail-plan agent can't produce quality output**: The stage is still too large. Break it into sub-stages in the outline and detail-plan each sub-stage individually.

package/dist/templates/orchestrator-plugin/skills/orchestration/workflow-examples.md

@@ -111,7 +111,7 @@ Follows Feature Build Large pattern:
   Cycle 5: critique stages 1-2 (foundation review before worker builds on it)
   Cycle 6: address critique + implement stage 3
   Cycle 7: implement stage 4 (integration + retry); validate stages 3-4
-  Cycle 8: sisyphus orch yield --mode validation — e2e: enqueue job, kill server, restart,
+  Cycle 8: sis orch yield --mode validation — e2e: enqueue job, kill server, restart,
     confirm job ran exactly once
   Cycle 9: final review agent; complete
 ```

package/dist/templates/orchestrator-validation.md

@@ -21,7 +21,7 @@ If the recipe doesn't exist or doesn't cover what was implemented:
 If you genuinely cannot determine how to verify the feature — transition back to planning:
 
 ```bash
-sisyphus orch yield --mode planning --prompt "Cannot determine verification method for [feature] — need to establish e2e recipe"
+sis orch yield --mode planning --prompt "Cannot determine verification method for [feature] — need to establish e2e recipe"
 ```
 
 ## The Operator Is Not Optional
@@ -76,7 +76,7 @@ If a report says "all checks pass" but the evidence is thin or missing — that'
 When validation surfaces real bugs:
 
 ```bash
-sisyphus orch yield --mode implementation --prompt "Validation failed — [specific failures]. See reports/agent-XXX-final.md for details."
+sis orch yield --mode implementation --prompt "Validation failed — [specific failures]. See reports/agent-XXX-final.md for details."
 ```
 
 Log what failed and why before yielding. The implementation cycle needs clear context on what to fix.
@@ -84,7 +84,7 @@ Log what failed and why before yielding. The implementation cycle needs clear co
 When validation reveals that the approach itself is flawed — not bugs, but architectural issues or fundamental misunderstandings:
 
 ```bash
-sisyphus orch yield --mode planning --prompt "Validation revealed [architectural issue] — approach needs rethinking. See cycle log."
+sis orch yield --mode planning --prompt "Validation revealed [architectural issue] — approach needs rethinking. See cycle log."
 ```
 
 **Do not attempt fixes in validation mode** beyond trivial issues (a missed import, a config typo). If the fix requires design decisions or touches multiple files, transition to implementation mode where the orchestrator has the right guidance for managing that work.
@@ -92,7 +92,7 @@ sisyphus orch yield --mode planning --prompt "Validation revealed [architectural
 ## Validation CLI
 
 ```bash
-sisyphus agent restart <agentId>                         # respawn a failed/killed validation agent
+sis agent restart <agentId>                         # respawn a failed/killed validation agent
 ```
 
 ## Transition to Completion
@@ -100,7 +100,7 @@ sisyphus agent restart <agentId>                         # respawn a failed/kill
 When all validation passes, yield to completion mode for user sign-off:
 
 ```bash
-sisyphus orch yield --mode completion --prompt "Validation passed — all recipe steps verified. Ready for user review."
+sis orch yield --mode completion --prompt "Validation passed — all recipe steps verified. Ready for user review."
 ```
 
 Only yield when every recipe step has been executed with evidence of success. If the recipe was updated during validation, re-validate against the updated version.

package/dist/templates/termrender-haiku-system.md

@@ -1,6 +1,6 @@
 # Role
 
-You generate dense, terminal-width termrender visuals for sisyphus ask questions.
+You generate dense, terminal-width termrender visuals for `sis ask` questions.
 Your output is exactly one `attach_visual` call with the final markdown.
 Read code or files via `read_file` if needed. Do not speculate about file contents.
 

package/dist/tui.js

@@ -3603,7 +3603,7 @@ function rawSend(request, timeoutMs = 1e4) {
     const timeout = setTimeout(() => {
       socket.destroy();
       reject(new Error(`Request timed out after ${(timeoutMs / 1e3).toFixed(0)}s. The daemon may be overloaded.
-  Check: sisyphus admin doctor
+  Check: sis admin doctor
   Logs: tail -20 ~/.sisyphus/daemon.log`));
     }, timeoutMs);
     socket.on("connect", () => {
@@ -4728,7 +4728,7 @@ function handleLeaderAction(action, state2, actions) {
         break;
       }
       try {
-        actions.openShellPopup(state2.cwd, `sisyphus session clone ${selectedSessionId}`);
+        actions.openShellPopup(state2.cwd, `sis session clone ${selectedSessionId}`);
       } catch {
         notify(state2, "Failed to open shell");
       }
@@ -4736,7 +4736,7 @@ function handleLeaderAction(action, state2, actions) {
     }
     case "history": {
       try {
-        actions.openShellPopup(state2.cwd, "sisyphus admin history");
+        actions.openShellPopup(state2.cwd, "sis admin history");
       } catch {
         notify(state2, "Failed to open shell");
       }
@@ -4744,7 +4744,7 @@ function handleLeaderAction(action, state2, actions) {
     }
     case "pick-session": {
       try {
-        actions.openShellPopup(state2.cwd, "sisyphus pick-session");
+        actions.openShellPopup(state2.cwd, "sis pick-session");
       } catch {
         notify(state2, "Failed to open shell");
       }
@@ -4752,7 +4752,7 @@ function handleLeaderAction(action, state2, actions) {
     }
     case "cycle-session": {
       try {
-        actions.openShellPopup(state2.cwd, "sisyphus cycle");
+        actions.openShellPopup(state2.cwd, "sis cycle");
       } catch {
         notify(state2, "Failed to open shell");
       }
@@ -4760,7 +4760,7 @@ function handleLeaderAction(action, state2, actions) {
     }
     case "reconnect": {
       try {
-        actions.openShellPopup(state2.cwd, "sisyphus session reconnect");
+        actions.openShellPopup(state2.cwd, "sis session reconnect");
       } catch {
         notify(state2, "Failed to open shell");
       }
@@ -4776,7 +4776,7 @@ function handleLeaderAction(action, state2, actions) {
     }
     case "show-status": {
       try {
-        actions.openShellPopup(state2.cwd, `sisyphus status${selectedSessionId ? ` ${selectedSessionId}` : ""}`);
+        actions.openShellPopup(state2.cwd, `sis status${selectedSessionId ? ` ${selectedSessionId}` : ""}`);
       } catch {
         notify(state2, "Failed to open status");
       }
@@ -5506,7 +5506,7 @@ function openCompanionPane(cwd2) {
   } catch {
     template = `You are a Sisyphus dashboard companion. Help the user manage multi-agent sessions.
 Project: ${cwd2}
-Run \`sisyphus list\` and \`sisyphus status\` to see current state.`;
+Run \`sis list\` and \`sis status\` to see current state.`;
   }
   const rendered = template.replace(/\{\{CWD\}\}/g, cwd2);
   const promptPath = join12(globalDir(), "dashboard-companion-prompt.md");