pi-dev 0.2.2 → 0.2.3

package/package.json

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

package/skills/do/SKILL.md

@@ -17,6 +17,7 @@ The point: **one request → one finished outcome**, with as few user interrupti
 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.
+   - Do **not** end the turn on a `follow-up: <next slice> — run /do <intent>` line while phases in the planned chain are unfinished. A `follow-up:` line is the **Step 7 final-summary terminator**, not a between-phase handoff. If the chain has more phases, the next thing in the same turn is the next phase's status line, not a `follow-up:` line. Issuing `follow-up: ... run /do ...` mid-chain is a hand-back; delete it and start the next phase instead.
    - 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:
@@ -151,6 +152,8 @@ Then for each 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.
+- Ending the turn with `follow-up: <next planned phase> — run /do …` when N < M. The `follow-up:` line is reserved for *post-chain* deferred work (push, manual ops live, prefs refresh). Using it to describe the *next planned phase of this chain* is a disguised hand-back — start the phase instead.
+- Treating a short user nudge ("진행해", "다음", "계속", "ㄱㄱ", "go", "이어서") as a new request. If the planned chain has unfinished phases, those nudges are noise — re-enter the chain at the next phase, do not re-classify and re-inject `/do`.
 
 The only place a wrap-up belongs is **Step 7 — Final summary**, after the last phase has met its terminal predicate.
 

package/skills/migrate/SKILL.md

@@ -221,6 +221,14 @@ In order:
      >> docs/agents/preferences.md
    ```
    The marker literal must read `<!-- migrated: YYYY-MM-DD by \`/migrate\` -->`. Do not paste a future or rounded date — `/do`'s 90-day staleness check relies on this being accurate.
+
+   **Self-check (mandatory, halts the migration if it fails).** Immediately after the `printf` above, verify the marker date equals today's UTC date:
+   ```bash
+   marker=$(grep -oE 'migrated: [0-9]{4}-[0-9]{2}-[0-9]{2}' docs/agents/preferences.md | tail -1 | awk '{print $2}')
+   today=$(date -u +%Y-%m-%d)
+   [ "$marker" = "$today" ] || { echo "marker $marker != today $today — re-run the printf with date -u, do not hand-type"; exit 1; }
+   ```
+   Skipping this check because "I already used `$(date -u …)`" is the anti-pattern — the hugn audit on 2026-05-11 found a marker of `2026-05-08` against a real preferences.md creation commit of `2026-05-11` despite the rule above.
 7. **Print summary**: counts of preserved / translated / archived / written, plus any FYI items needing manual review.
 
 ### 6. Idempotency