sisyphi 1.0.5 → 1.0.7

package/dist/{paths-FYYSBD27.js → paths-NUUALUVP.js}

@@ -26,7 +26,7 @@ import {
   statePath,
   worktreeBaseDir,
   worktreeConfigPath
-} from "./chunk-YGBGKMTF.js";
+} from "./chunk-JXKUI4P6.js";
 export {
   contextDir,
   cycleLogPath,
@@ -55,4 +55,4 @@ export {
   worktreeBaseDir,
   worktreeConfigPath
 };
-//# sourceMappingURL=paths-FYYSBD27.js.map
+//# sourceMappingURL=paths-NUUALUVP.js.map

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

@@ -0,0 +1,19 @@
+#!/bin/bash
+# UserPromptSubmit hook: remind plan agent to delegate for large tasks.
+if [ -z "$SISYPHUS_SESSION_ID" ]; then exit 0; fi
+
+python3 -c "
+import json, sys
+print(json.dumps({'additionalContext': sys.stdin.read()}))
+" <<'HINT'
+<planning-reminder>
+For particularly large or multi-domain tasks, delegate sub-plans to specialist agents rather than planning everything solo:
+
+- Spawn parallel Plan agents, each focused on a specific domain or layer
+- Each sub-planner investigates deeply and saves their work to context/plan-{topic}-{slice}.md
+- Synthesize their outputs into one cohesive master plan: resolve file ownership conflicts, fill gaps between slices, stress-test cross-cutting edge cases
+- Then spawn review agents to critique the assembled plan before finalizing
+
+Default toward delegation when in doubt — a round-trip for synthesis is cheaper than a shallow plan that misses edge cases. The cost of spawning sub-planners is low; the cost of a surface-level plan across too many concerns is high.
+</planning-reminder>
+HINT

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

@@ -0,0 +1,22 @@
+#!/bin/bash
+# UserPromptSubmit hook: remind spec agent to iterate with the user.
+if [ -z "$SISYPHUS_SESSION_ID" ]; then exit 0; fi
+
+python3 -c "
+import json, sys
+print(json.dumps({'additionalContext': sys.stdin.read()}))
+" <<'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-planning.md

@@ -1,5 +1,9 @@
 # Planning Phase
 
+## Planning Phase Flow
+
+The natural sequence: **context → spec → roadmap refinement → detailed planning.** Context documents come first because they feed everything downstream — spec writers, planners, and implementers all benefit from not having to re-explore the codebase. After the spec is aligned, revisit the roadmap — that's when you actually understand scope well enough to flesh out phases honestly.
+
 ## Exploration
 
 Use explore agents to build understanding before making decisions. Each agent should save a focused context document to `.sisyphus/sessions/$SISYPHUS_SESSION_ID/context/` — these artifacts get passed to downstream agents so they don't have to re-explore the codebase themselves.
@@ -23,6 +27,10 @@ For significant features, spec refinement is iterative:
 
 Not every stage needs a standalone spec document — a well-defined stage might just be a detailed section in the implementation plan. Use judgment about how much formality each stage warrants.
 
+## Roadmap Refinement
+
+Once you have context docs and an aligned spec, revisit the roadmap. This is the first point where you understand real scope — adjust phase boundaries, add phases you didn't anticipate, reorder for dependencies. Keep future phases at outline level; just make sure the shape is honest.
+
 ## Delegating to the Plan Lead
 
 Spawn **one plan lead** per feature. Point it at **inputs** (spec, context docs, corrections) — not a pre-made structure. Don't pre-decide staging, ordering, or design decisions. The plan lead has `effort: max` reasoning and handles its own decomposition: it will assess scope, delegate sub-plans to specialist agents if the feature is large enough, run adversarial reviews on the result, and deliver a synthesized master plan.