pi-gauntlet 6.0.0 → 6.1.0

package/skills/subagent-driven-development/code-quality-reviewer-prompt.md

@@ -41,16 +41,18 @@ TRAJECTORY: STAGNANT (repeat of: <finding>)
 
 Pick the first label that applies, in this order:
 
-1. STAGNANT: a previous finding survives materially unchanged - name it.
+1. STAGNANT: a previous Critical or Moderate finding survives materially unchanged - name it.
    (e.g. the same unchecked error path flagged last round is still unchecked)
-2. DIVERGING: <n_now> >= <n_prev>, or the fix introduced any new finding.
+2. DIVERGING: <n_now> >= <n_prev>, or the fix introduced a new Critical or Moderate finding.
    (e.g. 3 findings fixed but the fix broke an import: DIVERGING, not CONVERGING)
-3. CONVERGING: otherwise - the count fell, nothing new appeared, and every
-   surviving finding was materially improved.
-
-<n_prev>/<n_now> are finding counts; <X> is the highest remaining severity.
-For this line the severity set is exactly Critical/Moderate/Minor, regardless
-of the vocabulary used elsewhere in your report.
+3. CONVERGING: otherwise - the Critical/Moderate count fell, no new Critical or
+   Moderate appeared, and every surviving Critical or Moderate was materially improved.
+
+<n_prev>/<n_now> count Critical and Moderate findings only; Minors - ride-along
+Minors declined or unchanged, and `(outside fix delta)` downgrades alike - never
+move the `TRAJECTORY:` line. <X> is the highest remaining severity. For this line the severity set is
+exactly Critical/Moderate/Minor, regardless of the vocabulary used elsewhere in
+your report.
 
 The orchestrator dispatches one extra fix only when this line says CONVERGING
 without "max severity Critical" - be accurate, not generous.

package/skills/verification-before-completion/reference/conformance-check.md

@@ -443,6 +443,8 @@ finish gate's revert option needs them all:
 auto-applied fix commits: <Gn: SHA>, <Gm: SHA>, ... (revertable)
 ```
 
+Then the trailing `whole-diff minors:` section - read `whole-diff-minors.md` now (same directory); it is present in every block, a `CONFORMS` handoff too.
+
 ## Concern-scoped fix projection
 
 When the finish gate selects `fix-now` on some concerns of a gap, the fix loop

package/skills/verification-before-completion/reference/whole-diff-minors.md

@@ -0,0 +1,31 @@
+# Whole-diff minors section
+
+The trailing section of every `## Closure / conformance` block
+(conformance-check.md "Closure / conformance"); the spec contract is D3 of the
+change that introduced it.
+
+Then, in every block (a `CONFORMS` handoff too), the whole-diff review's Minor
+findings - the source is the final `SHIP` whole-diff report (SDD "After All
+Tasks Complete" step 2; a `FIX_FIRST` whole-diff review's re-review `SHIP`
+report when one ran):
+
+```text
+whole-diff minors: none
+```
+
+```text
+whole-diff minors:
+[Minor] F3: [shrink] path.ts:30 - ...
+[Minor] F7: [yagni] other.ts:12 - ...
+```
+
+Use one persona finding line per Minor, verbatim (`Fn` is the selector), or
+`whole-diff minors: not recorded` when no whole-diff review ran in this flow.
+This section is not a concern card: the sentinel `N`, the card count, and the
+freshness rule ignore it. After a `fix minors` round
+(`finishing-a-development-branch` Step 4) the regenerated block carries the
+prior list minus the selected `Fn` lines plus one line
+`whole-diff minors fix: <full SHA>`, so the spent round survives pruning and
+resume. On any other re-audit that regenerates the block without the source
+report, copy the prior block's `whole-diff minors:` section minus lines selected
+by `fix minors`.

package/skills/writing-plans/SKILL.md

@@ -17,13 +17,14 @@ DRY. YAGNI. TDD. Frequent commits.
 
 Before drafting the plan, check `phase_tracker({ action: "status" })`. If `plan` is already `in_progress` (a flow restored by `/skill:gauntlet-resume` arrives this way), do **not** call `start` again - a repeat `start` on the in_progress phase resets its guard ledger. Otherwise call `phase_tracker({ action: "start", phase: "plan" })`.
 
-**Input:** an approved spec in `<project>/doc/specs/<filename>.md` — produced by `/skill:brainstorming` in this session, or restored from another session by `/skill:gauntlet-resume`. Those two are the only entry points.
+**Input:** an approved spec in a resolved spec dir from `gauntlet_setting({ key: "flowGuards" })` - produced by `/skill:brainstorming` in this session, or restored from another session by `/skill:gauntlet-resume`. Those two are the only entry points.
 
-**Save plans to:** the sibling `doc/plans/` directory next to the spec. The plan filename matches the spec filename exactly — same date, same ticket ID (if any), same topic slug, no `-design` suffix. The plan path is absolute under the worktree (`<abs worktree path>/doc/plans/<filename>.md`, the path reported by `using-git-worktrees`), and `plan_check({ planPath })` receives that absolute path - the tool roots its checks at the plan's own checkout, not at the session cwd.
+**Save plans to:** the sibling `plans/` directory next to the spec's resolved dir (`doc/specs` -> `doc/plans`, `docs/specs` -> `docs/plans`). The plan filename matches the spec filename exactly - same date, same ticket ID (if any), same topic slug, no `-design` suffix. Use the absolute plan path under the worktree (`<abs worktree path>/<sibling plans dir>/<filename>.md`, using the path reported by `using-git-worktrees`), and `plan_check({ planPath })` receives that absolute path - the tool roots its checks at the plan's own checkout, not at the session cwd.
 
 | Spec path | Plan path |
 |---|---|
 | `doc/specs/2025-05-26-foo.md` | `doc/plans/2025-05-26-foo.md` |
+| `docs/specs/2025-05-26-foo.md` | `docs/plans/2025-05-26-foo.md` |
 | `doc/specs/2025-05-26-PROJ-1234-foo.md` | `doc/plans/2025-05-26-PROJ-1234-foo.md` |
 | `<service>/doc/specs/<name>.md` | `<service>/doc/plans/<name>.md` |
 
@@ -32,7 +33,7 @@ If no spec exists, send the work back to `/skill:brainstorming`. Do not invent a
 ## Boundaries
 
 - Read code and docs: yes
-- Write the plan to the sibling `doc/plans/` of the spec: yes
+- Write the plan to the sibling `plans/` dir of the spec: yes
 - Edit or create any other files: no
 - Write implementation code: never inside this skill. After Self-Review + `phase_tracker` complete, auto-invoke `/skill:subagent-driven-development` to execute.
 - Land the plan on `main`: no — the plan commit goes on the worktree branch (same branch as the spec)