@leing2021/super-pi 0.29.0 → 0.30.1

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@leing2021/super-pi",
-  "version": "0.29.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:** when a plan artifact exists, compare diff against it — report **missing** requirements, **scope creep** (unrequested behaviour), and **wrong implementation** (looks done but isn't). Also **trace back** to the user's original wording (brainstorm scope) to catch directional misunderstandings the plan itself encoded. Skip if no plan.
+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)
 
@@ -59,9 +59,9 @@ Code review is **technical evaluation**, not social performance:
 ## Workflow
 
 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 from branch or explicit target
+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
+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.

package/skills/references/pipeline-config.md

@@ -109,6 +109,10 @@ When a stage produces or updates handoff-lite, use this evidence-first structure
 ## Recently Accessed Files
 - files recently read or edited
 
+## Git Context
+- branch: <current branch or N/A>
+- base: <diff base ref, e.g. main / N/A>
+
 ## Artifacts
 - requirements: <path or N/A>
 - plan: <path or N/A>