pi-dev 0.2.1 → 0.2.3

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "pi-dev",
-  "version": "0.2.1",
+  "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:
@@ -28,6 +29,30 @@ The point: **one request → one finished outcome**, with as few user interrupti
 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.
 7. **Status line per phase.** `[flow N/M] <phase-name> — <one-sentence what>`.
+8. **Issue-write rule (no exceptions).** Every issue body written from a `/do` flow — whether you invoke `/to-issues`, `/triage`, or call `gh issue create` / `gh issue edit` directly from a bash tool — MUST start with this disclaimer as the first non-blank line:
+
+   ```
+   > *This was generated by AI during triage.*
+   ```
+
+   This rule is global and binding regardless of which skill you think you are in. Before publishing any issue body:
+
+   - Build the body with `--body-file <path>` or a heredoc, never with inline `--body "..."` (heredocs make the disclaimer visible in the diff and the file is auditable).
+   - The first non-blank line of the body file must be the disclaimer literal above.
+   - Immediately after `gh issue create` / `gh issue edit` returns, run one self-check on the resulting body and halt the flow if it fails:
+
+     ```bash
+     gh issue view <num> --json body --jq '.body' | awk 'NF{print; exit}' | grep -q 'generated by AI' \
+       || { echo "AI disclaimer missing on issue #<num>"; exit 1; }
+     ```
+
+   **Anti-patterns** (delete and redo if you catch any in your own draft):
+
+   - `gh issue create --title "…" --body "..."` (inline body, no disclaimer check)
+   - First line of issue body being `## Goal`, `## Scope`, `## Problem Statement`, `**Parent epic:**`, or any heading other than the disclaimer.
+   - Skipping the post-create `gh issue view ... | grep generated by AI` self-check because "I included the disclaimer in the heredoc".
+
+   Skills `/to-issues` and `/triage` repeat this rule for the case where you do enter them. This Hard rule is the binding statement for the case where you do not.
 
 ## Process
 
@@ -127,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.
 
@@ -192,7 +219,7 @@ If you emitted anything that looks like a wrap-up ("All set!", "Done.", "Let me
 | `grill-with-docs` / `grill-lite`   | every open question answered, deferred with rationale, or escalated; relevant CONTEXT/ADR updates committed |
 | `to-prd`                           | PRD published to issue tracker with `needs-triage` (per `auto-create-issues`)           |
 | `to-issues`                        | all slices created on tracker; each is independently grabbable; labels applied per `auto-apply-labels` |
-| `triage`                           | issue carries exactly one state label; AI disclaimer present                            |
+| `triage`                           | issue carries exactly one state label; AI disclaimer present (verified via the Hard rule #8 self-check, not just inserted into the heredoc) |
 | `diagnose`                         | reproducible pass/fail loop exists AND root cause identified AND regression test exists |
 | `tdd`                              | new test red→green; project's check command clean; commit per `auto-commit-per-slice`    |
 | `improve-codebase-architecture`    | proposed deepening either applied or recorded as a follow-up issue                      |

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