pi-dev 0.1.4 → 0.1.5

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "pi-dev",
-  "version": "0.1.4",
+  "version": "0.1.5",
   "description": "An autonomous engineering skill framework for the pi runtime — built on Matt Pocock's skills.",
   "type": "module",
   "bin": {

package/skills/do/SKILL.md

@@ -14,10 +14,16 @@ The point: **one request → one finished outcome**, with as few user interrupti
 1. **Migration gate (strict).** If `docs/agents/preferences.md` does not contain the `<!-- migrated: ... -->` marker, **stop** and invoke `/migrate`. Do not run any engineering work on un-migrated repos. The user makes the migration decision; the skill executes it. No partial-migration shortcuts.
 2. **Read preferences (3 layers).** Merge global (`~/.pi/agent/preferences.md`) → project (`docs/agents/preferences.md`) → package (`packages/<pkg>/preferences.md` if a single package is targeted). If global is missing, warn once and use built-in defaults from `/taste`.
 3. **Treat preferences as decisions.** Any choice the merged prefs answer is **decided**. Do not re-ask.
-4. **Keep going.** When something would normally cause a halt (ambiguous classification, scope creep beyond `change-budget`, missing follow-up), **expand and surface in the final summary** instead of stopping mid-flow. Halt only when:
+4. **Keep going. Never hand the flow back between phases.** When something would normally cause a halt (ambiguous classification, scope creep beyond `change-budget`, missing follow-up), **expand and surface in the final summary** instead of stopping mid-flow. Specifically:
+   - Do **not** ask the user "shall I proceed to the next phase?", "want me to continue?", "should I do X next?", or any equivalent. The chain is decided in Step 3 and runs to completion.
+   - Do **not** end your turn between phases. A phase's terminal predicate passing is the cue to immediately print the next phase's status line and start it, in the same turn.
+   - Confirmation-shaped questions are only legal via the **Ambiguity protocol** (one decision the prefs genuinely cannot answer) or the **Failure protocol** (terminal predicate failed twice).
+
+   Halt only when:
    - migration gate fails, OR
    - GitHub gate fails (when GitHub is the tracker), OR
    - a phase's terminal predicate fails twice and the failure cannot be characterised, OR
+   - the Ambiguity protocol fires (preferences truly silent on a one-shot decision), OR
    - user interrupts.
 5. **No handoff files.** State of work lives in three places only: **code (git), issue tracker, merged preferences**. Do not create `.scratch/flow/`, `docs/handoff/`, or any session-log file. Phase outputs are remembered in-context; persistent decisions are committed to code or filed as issues.
 6. **Side-effect gates respect prefs literally.** `auto-create-issues`, `auto-apply-labels`, `auto-commit-per-slice`, `auto-pr` follow merged prefs without reinterpretation.
@@ -99,15 +105,31 @@ If measured scope exceeds `change-budget` (e.g. `module` budget vs `cross-packag
 
 ### Step 4 — Execute the chain
 
-For each phase:
+Before running any phase, **print the planned chain once** so the user can see the runway:
+
+```
+[flow plan] intent=<x> scope=<y> chain: phase1 → phase2 → … → phaseM
+```
+
+Then for each phase:
 
-1. Print status line.
+1. Print status line `[flow N/M] <phase> — <one-sentence what>`.
 2. Run the phase. Use merged prefs to make every taste decision the phase exposes.
 3. Check the terminal predicate. If fail, retry once with explicit diagnosis. If fail again, halt with reason.
-4. Continue.
+4. **Transition without asking.** The instant the terminal predicate passes, print the *next* phase's status line on the very next line and start executing it, in the same turn. No "next, I'll do X" preamble. No "shall I continue?". No turn end.
 
 **No handoff writes.** Pass state in-context only.
 
+**Anti-patterns to detect in your own output before sending** (if you catch any of these mid-draft while phases remain, delete and replace with the next phase's status line):
+
+- "Want me to proceed with <next phase>?"
+- "Shall I continue to <next phase>?"
+- "Ready to move on to <next phase>?"
+- "Let me know if you want me to <next phase>."
+- Ending the turn after a phase summary when N < M.
+
+The only place a wrap-up belongs is **Step 7 — Final summary**, after the last phase has met its terminal predicate.
+
 ### Step 5 — Live verification
 
 Driven by **two separate prefs keys**:
@@ -139,15 +161,29 @@ If a side-effect was skipped because prefs said so, list it in the final summary
 
 ### Step 7 — Final summary
 
-One screen:
+Reached only after the **last** phase in the chain has met its terminal predicate (or the Failure protocol fired). One screen:
 
-- intent / scope / chain executed
+- intent / scope / chain executed (all N/M status lines accounted for)
 - diffs (files touched)
 - side effects done (issue URLs, commit SHAs, branch name, PR URL)
 - side effects deferred (with reason and the exact command to do them)
 - expansions (scope went beyond budget, ambiguous decisions made with rationale)
 - prefs refresh hint if stale
 
+The summary's **last line** must be one of these two terminators, so the user can tell at a glance whether the flow is done:
+
+```
+chain complete — no further action.
+```
+
+or
+
+```
+follow-up: <one-line description> — run `<exact command>`.
+```
+
+If you emitted anything that looks like a wrap-up ("All set!", "Done.", "Let me know if...") without one of those two terminators, you ended early. Reopen the chain at the missed phase.
+
 ## Phase contracts (terminal predicates)
 
 | phase                              | done when…                                                                              |