@leing2021/super-pi 0.30.0 → 0.30.1

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@leing2021/super-pi",
-  "version": "0.30.0",
+  "version": "0.30.1",
   "private": false,
   "type": "module",
   "description": "Pi-native Compound Engineering package for iterative development workflows",

package/skills/04-review/SKILL.md

@@ -25,7 +25,7 @@ See [shared pipeline instructions](../references/pipeline-config.md) for model r
    - Extract keywords → `grep -rl "tags:.*keyword" docs/solutions/ ~/.pi/agent/docs/solutions/`
    - Read **frontmatter** only (first 15 lines) of matches → score by severity + tag relevance
    - Fully read top 3 candidates
-8. **Spec axis:** determine spec source in priority order — (a) plan artifact; (b) brainstorm artifact (trace back to original wording to catch directional misunderstandings the plan encoded); (c) issue references in commit messages (`git log <base>..HEAD --oneline`, scan for `#123` / `Closes #45` / `!67`) — identify the ref and ask the user whether to treat it as spec source, do **not** auto-fetch; (d) skip if none. Against the chosen spec, report **missing** requirements, **scope creep** (unrequested behaviour), and **wrong implementation** (looks done but isn't).
+8. **Spec axis:** determine spec source via [`references/spec-source-detection.md`](references/spec-source-detection.md) (plan → brainstorm → commit issue ref → skip). Against the chosen spec, report **missing** requirements, **scope creep** (unrequested behaviour), and **wrong implementation** (looks done but isn't).
 9. Produce structured findings using `references/findings-schema.md`
 10. **Autofixable findings:** apply and re-review (max 3 iterations)
 
@@ -61,7 +61,7 @@ Code review is **technical evaluation**, not social performance:
 1. **Load context**: consume latest handoff before any broad file reads — `context_handoff load` or read `.context/compound-engineering/handoffs/latest.md`. If found, use `activeFiles`, `artifacts.plan` as starting point. If not found, proceed normally. Read `CONTEXT.md` if it exists at root — see `../references/domain-language.md`.
 2. Determine diff scope — prefer `branch`/`base` from latest handoff if present; else from explicit target; else ask user
 3. Collect stats (files, insertions, deletions) → call `review_router`
-4. Read matching plan artifact. If absent, scan commit messages for issue refs (`git log <base>..HEAD --oneline`) and ask user whether to use as spec source — do not auto-fetch
+4. Read matching plan artifact; if absent, follow [`references/spec-source-detection.md`](references/spec-source-detection.md) to probe brainstorm and commit issue refs
 5. Run solution search
 6. Apply each reviewer persona from `review_router`
 7. Merge into structured findings

package/skills/04-review/references/spec-source-detection.md

@@ -0,0 +1,35 @@
+# Spec source detection
+
+The 04-review Spec axis needs an originating spec to compare the diff against. When the user invokes 04-review standalone (no brainstorm, no plan), the Spec axis would otherwise be inert. This reference defines the probe that finds a spec source in priority order.
+
+## Four-level probe
+
+Try each source in order; use the first that applies:
+
+1. **Plan artifact** (`docs/plans/`) — the default. Compare the diff against the plan's implementation units.
+2. **Brainstorm artifact** (`docs/brainstorms/`) — trace back to the user's original wording to catch directional misunderstandings the plan itself encoded. A plan can faithfully implement the wrong thing if the brainstorm scope was misread.
+3. **Issue references in commit messages** — scan `git log <base>..HEAD --oneline` for tokens like `#123`, `Closes #45`, `Fixes #67`, GitLab `!67`. When a ref is found, **identify it and ask the user** whether to treat the linked issue as the spec source. Do **not** auto-fetch (`gh issue view`, network calls). The decision to adopt a ref as spec stays with the user.
+4. **Skip** — if none of the above yield a spec, the Spec axis is skipped for this run.
+
+## Artifact-driven guard
+
+The probe deliberately uses only local operations:
+
+- `git log` for commit-message scanning — no network, no tracker API.
+- No `gh issue view`, no GitHub/Linear/Jira fetch. super-pi's source of truth is the artifact, not an external tracker.
+
+This is consistent with the four-filter evaluation in solution `2026-07-22-absorbing-external-skill-repos`: the artifact-driven filter rejects making an issue tracker a source of truth, but permits using a commit ref as an optional clue that a human promotes to spec.
+
+## Why issue refs and not auto-fetch
+
+- **Standalone-invocation coverage**: a team that tracks specs in GitHub issues can `/skill:04-review` a PR directly, without running 01-brainstorm. The commit-message ref is the only local signal that an issue exists.
+- **No new hard dependency**: `git log` is always available; `gh` may not be installed or authenticated. Auto-fetch would couple review to tracker availability.
+- **User stays in control**: a ref might be tangential (`#123` fixing an unrelated typo in the same commit). Asking before adopting prevents false specs from corrupting the Spec axis.
+
+## Output against the chosen spec
+
+Whichever source wins, the Spec axis reports three classes of finding against it:
+
+- **missing** — requirements the spec asked for that the diff does not deliver.
+- **scope creep** — behaviour in the diff the spec did not request.
+- **wrong implementation** — requirements that look implemented but where the implementation is incorrect.