pi-dev 0.2.3 → 0.2.4

package/package.json

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

package/skills/do/SKILL.md

@@ -39,18 +39,23 @@ The point: **one request → one finished outcome**, with as few user interrupti
 
    - 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:
+   - Immediately after **every** `gh issue create` / `gh issue edit` returns, the **very next tool call** must be this self-check on the resulting body. Not "sometime later", not "once at the end of the batch":
 
      ```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; }
      ```
 
+   - **If the self-check fails, the immediately following tool call MUST be a corrective `gh issue edit <num> --body-file <fixed>` that prepends the disclaimer literal, followed by a re-run of the self-check.** Do not create the next slice, do not call any other tool, and do not summarise progress until a self-check on that issue returns success. A failed self-check that is not followed by an edit-then-recheck pair is itself a Hard-rule #8 violation — equivalent to never having run the check.
+   - The `awk 'NF{print; exit}'` form is mandatory: it selects the first **non-blank** line, which is what the rule actually constrains. `head -1` is not equivalent and will pass false positives on bodies with a leading blank line.
+
    **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.
+   - First line of issue body being `## Goal`, `## Scope`, `## Problem Statement`, `## Context`, `**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".
+   - Running the self-check, seeing it fail, and *continuing to the next slice anyway* — "I'll fix the disclaimers in a batch at the end" is the failure mode that this rule is named after. Fix the one issue you just created, then move on.
+   - Batching N `gh issue create` calls in a row and then a single self-check at the end. The self-check is per-issue, and it gates the next `create`.
 
    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.
 

package/skills/improve-skill-flow/SKILL.md

@@ -84,7 +84,27 @@ Each line is one of these record types:
 | `session` | session header — has `cwd`, `timestamp`, `version`, `id` |
 | `model_change` | provider / modelId switch |
 | `thinking_level_change` | reasoning effort knob |
-| `message` | a user or assistant turn |
+| `message` | a user / assistant / toolResult turn |
+
+**Record shape for `message` (do not skim this — it has bitten parsers before):**
+
+```jsonc
+{
+  "type": "message",
+  "id": "...",
+  "parentId": "...",
+  "timestamp": "2026-05-11T16:46:49.795Z",
+  "message": {                       // ← NESTED. role/content are HERE, not at top level.
+    "role": "user" | "assistant" | "toolResult",
+    "content": [ ...blocks ],
+    "timestamp": "...",
+    // assistant-only extras: api, provider, model, usage, stopReason, responseId
+    // toolResult-only extras: toolCallId, toolName, isError
+  }
+}
+```
+
+A correct read path is `rec["message"]["role"]` and `rec["message"]["content"]`. Reading `rec["role"]` / `rec["content"]` returns `None` for every record and silently produces a zero-row signal table — if your first pass shows all counters at 0, this is almost certainly why.
 
 `message.content` is a **list of blocks**, each block has a `type`:
 
@@ -95,8 +115,19 @@ Each line is one of these record types:
 | `toolCall` | `{id, name, arguments}` | **pi uses this** — NOT Anthropic SDK's `tool_use` |
 | `toolResult` | `{id, output}` | **pi uses this** — NOT `tool_result` |
 
+Roles in practice: `user`, `assistant`, and **`toolResult`** (yes, role and block type share the name; a `toolResult`-role message contains one or more `text` blocks holding the tool output). Treat `toolResult`-role messages as siblings of the originating `toolCall` — do not double-count them as user/assistant turns.
+
 Tool names are **lower-case** (`bash`, `read`, `edit`, `write`, `glob`, `grep`, etc.). Build any parser around `toolCall` / `toolResult` first, then fall back to Anthropic-shaped blocks for robustness.
 
+**Parser pre-flight (mandatory before Step 2 aggregates).** After you write the one-shot Python parser, run it on the newest 1–2 `.jsonl` files and assert the following are non-zero for any session that obviously had work done:
+
+```python
+assert tool_count, "toolCall extraction returned 0 — check rec['message']['content'], not rec['content']"
+assert user_msg_total or skill_inject_count, "no user messages parsed — same nested-message bug"
+```
+
+If either assertion would fail, fix the parser before producing the signal table. A zero-row table is never a finding — it is a parser bug.
+
 **Critical detail:** the pi runtime injects each skill's `SKILL.md` content into the conversation as a `<skill name="..." location="...">…</skill>` block embedded inside a **user-role** message (system-side injection, but the role is user). This is how you tell the classifier loaded a skill. Count these to see what `/do` actually picked.
 
 Timestamps on `message` records are ISO strings; some other record types use int millis. Handle both.

package/skills/to-issues/SKILL.md

@@ -55,7 +55,7 @@ For each approved slice, publish a new issue to the issue tracker. Use the issue
 
 Publish issues in dependency order (blockers first) so you can reference real issue identifiers in the "Blocked by" field.
 
-**Every issue body MUST start with the AI disclaimer** (same wording as `/triage`). This is a hard requirement — no exceptions, including auto-generated slices. After writing the body, grep your own draft for the disclaimer string; if missing, do not publish.
+**Every issue body MUST start with the AI disclaimer** (same wording as `/triage`). This is a hard requirement — no exceptions, including auto-generated slices. After writing the body, grep your own draft for the disclaimer string; if missing, do not publish. This duplicates `/do` Hard rule #8 — the per-issue self-check below is part of the contract, not an optional verification step.
 
 <issue-template>
 > *This was generated by AI during triage.*
@@ -99,11 +99,15 @@ gh issue create \
 EOF
 ```
 
-After creation, immediately verify the disclaimer landed:
+After **each** `gh issue create` returns, the **very next tool call** must verify the disclaimer landed on that specific issue, before creating the next slice:
 
 ```bash
-gh issue view <n> --json body --jq '.body' | head -1 | grep -q 'generated by AI' \
-  || echo "FAIL: disclaimer missing on #<n>"
+gh issue view <n> --json body --jq '.body' | awk 'NF{print; exit}' | grep -q 'generated by AI' \
+  || { echo "FAIL: disclaimer missing on #<n>"; exit 1; }
 ```
 
+Use `awk 'NF{print; exit}'` (first non-blank line), not `head -1` — a leading blank line will pass `head -1` and hide a missing disclaimer.
+
+**If the self-check fails**, the next tool call MUST be `gh issue edit <n> --body-file <fixed>` to prepend the disclaimer, followed by a re-run of the self-check. Do not proceed to the next slice until the self-check on the current issue passes. Batching all the creates first and then running checks at the end is a Hard-rule #8 violation — the check gates the *next* create.
+
 Do NOT close or modify any parent issue.