@iceinvein/agent-skills 0.23.12 → 0.23.14

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@iceinvein/agent-skills",
-  "version": "0.23.12",
+  "version": "0.23.14",
   "description": "Install agent skills into AI coding tools",
   "author": "iceinvein",
   "license": "MIT",

package/skills/index.json

@@ -227,7 +227,7 @@
     "name": "magpie",
     "description": "Interactive PR review pipeline. Runs five parallel specialist subagents (security, bugs, performance, code-smells, architecture) plus a once-per-PR checks pass that finds tests and controls able to pass without proving their purpose, drops findings whose quoted evidence is not in the code, dedupes, runs critic subagents that re-check each finding against the worktree and set its risk label, peer-reviews via codex exec (falling back to a Claude second opinion when codex is unavailable), and serves an interactive HTML report for selecting or dismissing findings to post via gh, recording the outcome per finding as labels. Bundles a Bun CLI put on PATH by the skill's postinstall step under a bunx install, or by the plugin's bin/ under a Claude Code plugin install. Use when the user asks to review a GitHub pull request. Local mode (setup --local) runs the same pipeline on the current branch's diff from its merge base, uncommitted and untracked work included, against the caller's live tree, with no server or posting, and hands the ranked findings back in the terminal for an implementing or orchestrating agent to address. Splits oversized diffs into budgeted shards and rebuilds the diff from the local clone when gh pr diff refuses it.",
     "type": "prompt",
-    "version": "0.16.0"
+    "version": "0.16.1"
   },
   {
     "name": "migrate",
@@ -295,7 +295,7 @@
     "name": "sluice",
     "description": "Routes work by change shape into four channels (bypass, fast, main, deep) and applies only the rules each channel needs, so a one-line fix does not pay the cost of a multi-subsystem build. Carries nine rules as one-liners in the router and the full treatment in references read only on friction. Deep runs read the repo before designing, map the spec's intent to its decisions, and check spec against intent and plan against spec with a fresh reader, with plan.sh validate enforcing that every decision is covered. Checks the finished plan with plan.sh validate rather than trusting it to memory, seeds the run state from it, keeps a deep run's task breakdown in .sluice/run.json so a statusline segment, one status command and a SessionStart hook can answer where the run is (the hook prints a live run at every session start, compaction included), lists every live deep run and routed fast or main session on the machine in one board.sh view (drawn once, watched, or as JSON), and closes each run with a ledger read out of the session transcript: elapsed, tools, tokens, and what each dispatched agent cost where the transcript recorded it. Two Stop hooks hold a handback: one refuses a tree that moved since its last recorded check, the other refuses a changed existing test not proven to fail on the session's starting code (or recorded with a reason). Claude Code only; stands down where the superpowers pipeline governs the repo.",
     "type": "prompt",
-    "version": "0.28.2"
+    "version": "0.29.0"
   },
   {
     "name": "temporal-coupling-detector",

package/skills/magpie/SKILL.md

@@ -203,7 +203,7 @@ If codex returns non-zero on a batch, do not abort: record `{stage: peer-review,
 
 ### 7b. Proof
 
-Append `{stage: proof, status: running}` and re-render progress. `magpie proof-prompt "$RUN_DIR"` fills `references/proof.md` for up to 8 serious findings, printing `<prompt path>\t<output path>` each. On a PR run with any printed, first install `$WORKTREE`'s dependencies once with the repo's frozen-lockfile command (`npm ci`, `uv sync --frozen`, ...); on failure log `{stage: proof-deps, status: skipped, error}` and go on. Dispatch the prompts as stage 6 does its batches, then `magpie proof-apply "$RUN_DIR"`: it drops disproved findings to `proof-dropped.json`, marks the rest and logs `done`. On a non-zero exit, delete only the `proof-<id>.json` files or leftovers stderr names, then re-dispatch or re-apply.
+Append `{stage: proof, status: running}` and re-render progress. `magpie proof-prompt "$RUN_DIR"` fills `references/proof.md` for up to 8 must-fix or should-fix findings, printing `<prompt path>\t<output path>` each. On a PR run with any printed, first install `$WORKTREE`'s dependencies once with the repo's frozen-lockfile command (`npm ci`, `uv sync --frozen`, ...); on failure log `{stage: proof-deps, status: skipped, error}` and go on. Dispatch the prompts as stage 6 does its batches, then `magpie proof-apply "$RUN_DIR"`: it drops disproved findings to `proof-dropped.json`, marks the rest and logs `done`. On a non-zero exit, delete only the `proof-<id>.json` files or leftovers stderr names, then re-dispatch or re-apply.
 
 ### 8. Report
 

package/skills/magpie/bin/magpie.ts

@@ -22,8 +22,8 @@ Subcommands:
   critic-apply <run-dir> [--design-cap N]
                              Apply critic verdicts, write findings.kept.json (no cap on
                              code-smells + architecture keeps unless --design-cap is given)
-  proof-prompt <run-dir>     Write one proof prompt per serious finding, print prompt and
-                             output paths
+  proof-prompt <run-dir>     Write one proof prompt per must-fix or should-fix finding, print
+                             prompt and output paths
   proof-apply <run-dir>      Fold proof results into findings.final.json, drop the disproved
   shard <run-dir> [--budget N] [--max-files N]
                              Re-split diff.patch into budgeted shards (and the

package/skills/magpie/references/proof.md

@@ -1,8 +1,8 @@
 # Proof prompt
 
 Stage 7b of the walkthrough does not read this file by hand. `magpie proof-prompt
-"$RUN_DIR"` picks the findings worth proving from `findings.final.json` (impact
-critical or high, action must-fix or should-fix, at most 8, highest score first),
+"$RUN_DIR"` picks the findings worth proving from `findings.final.json` (action
+must-fix or should-fix, at most 8, highest score first),
 takes the fenced `magpie-proof` block below, fills its four placeholders, and writes
 one prompt file per finding:
 
@@ -56,7 +56,10 @@ Diff: <<DIFF_PATH>>
    real dependency never would proves nothing.
 4. Run only that file, with colour off (`--no-color`, `CI=1`), and in a way that does
    not compile or type-check the whole project: other provers' half-written files sit
-   beside yours. Read the output.
+   beside yours. Read the output. Anything you save outside the test file, such as the
+   run's output, goes in a directory of your own from `mktemp -d`, never a scratchpad or
+   temp path another session shares: other provers write there too, and their output
+   is not your result.
 5. Copy the test's full source and the last 40 lines of output (at most) into your
    result. Then, whatever the outcome, `not-proven` included, delete the test file and
    anything its run created (snapshots, fixtures). Change no other file in the working

package/skills/magpie/scripts/__tests__/history.test.ts

@@ -202,3 +202,31 @@ test('history with only leads carries the leads heading and no repeats preamble'
     ].join('\n'),
   )
 })
+
+test('already-raised leaves out comments from github-actions, which posts CI output', () => {
+  const out = renderAlreadyRaised({
+    activity: {
+      checks: [],
+      threads: [],
+      comments: [
+        { author: 'github-actions', body: '<h2>Coverage Report</h2>', magpie: false },
+        { author: 'coderabbitai', body: 'This retry never backs off.', magpie: false },
+      ],
+    },
+    previous: null,
+  })
+  expect(out).toBe('PR comments:\n- coderabbitai: This retry never backs off.')
+})
+
+test('already-raised is (none) when the only comments are CI output', () => {
+  expect(
+    renderAlreadyRaised({
+      activity: {
+        checks: [],
+        threads: [],
+        comments: [{ author: 'github-actions', body: '<h2>Coverage Report</h2>', magpie: false }],
+      },
+      previous: null,
+    }),
+  ).toBe('(none)')
+})

package/skills/magpie/scripts/__tests__/proof.test.ts

@@ -44,17 +44,24 @@ const REPRO = {
   output: 'expected 1, received undefined',
 }
 
-test('only high or critical findings marked must-fix or should-fix are selected', () => {
+test('findings marked must-fix or should-fix are selected whatever their impact', () => {
   const selected = selectForProof(
     [
       finding('high-should', HIGH_SHOULD),
       finding('medium-should', MEDIUM_SHOULD),
+      finding('low-should', { ...HIGH_SHOULD, impact: 'low' }),
       finding('high-consider', HIGH_CONSIDER),
+      finding('high-optional', { ...HIGH_SHOULD, action: 'optional' }),
       finding('critical-must', CRITICAL_MUST),
     ],
     8,
   )
-  expect(selected.map((f) => f.id)).toEqual(['critical-must', 'high-should'])
+  expect(selected.map((f) => f.id)).toEqual([
+    'critical-must',
+    'high-should',
+    'medium-should',
+    'low-should',
+  ])
 })
 
 test('selection keeps the highest-scoring findings when there are more than the cap', () => {

package/skills/magpie/scripts/__tests__/skill-lint.test.ts

@@ -114,6 +114,15 @@ test('references/proof.md carries every placeholder proof-prompt fills', async (
   }
 })
 
+test("references/proof.md keeps each prover's scratch output in a directory of its own", async () => {
+  // On PR 254 a prover picked up another prover's run output from the session
+  // scratchpad every subagent shares, and nearly reported it as its own.
+  const text = await readFile(ref('proof.md'), 'utf8')
+  const block = text.match(/^(`{3,4})magpie-proof\n([\s\S]*?)\n\1[ \t]*$/m)?.[2] ?? ''
+  expect(block).toContain('mktemp -d')
+  expect(block).toMatch(/never a scratchpad or\s+temp path another session shares/)
+})
+
 test('references/proof.md asks for the result shape proof-apply accepts', async () => {
   const text = await readFile(ref('proof.md'), 'utf8')
   const block = text.match(/^(`{3,4})magpie-proof\n([\s\S]*?)\n\1[ \t]*$/m)?.[2] ?? ''

package/skills/magpie/scripts/history.ts

@@ -42,6 +42,12 @@ function joinSections(sections: string[][]): string {
     .join('\n\n')
 }
 
+// The account GitHub Actions posts as: coverage tables, deploy previews and other
+// CI output, which reaches the review as checks. Review bots post as their own
+// apps, and what they raise still counts. gh prints the login without `[bot]`,
+// the REST API with it.
+const CI_AUTHORS = new Set(['github-actions', 'github-actions[bot]'])
+
 function raisedSections(input: Pick<History, 'activity' | 'previous'>): string[][] {
   const threads = (input.activity?.threads ?? [])
     .filter((t) => !t.resolved)
@@ -50,9 +56,9 @@ function raisedSections(input: Pick<History, 'activity' | 'previous'>): string[]
       const outdated = t.outdated ? ' [outdated]' : ''
       return `- ${location(t.file, t.line)} (${who})${outdated}: ${flatten(t.body)}`
     })
-  const comments = (input.activity?.comments ?? []).map(
-    (c) => `- ${c.magpie ? 'magpie, earlier run' : c.author}: ${flatten(c.body)}`,
-  )
+  const comments = (input.activity?.comments ?? [])
+    .filter((c) => !CI_AUTHORS.has(c.author))
+    .map((c) => `- ${c.magpie ? 'magpie, earlier run' : c.author}: ${flatten(c.body)}`)
   const dismissed = (input.previous?.findings ?? []).flatMap((f) =>
     f.label === 'dismissed' ? [`- ${location(f.file, f.line)} [${f.reason}]: ${f.title}`] : [],
   )

package/skills/magpie/scripts/proof.ts

@@ -33,10 +33,10 @@ export type ProofDropped = {
 }
 
 export function selectForProof(findings: ReviewFinding[], cap: number): ReviewFinding[] {
+  // Action, not impact: the critic keeps a confirmed defect at should-fix even when
+  // it rates the impact low, and a real PR left nothing high to prove.
   const eligible = findings.filter(
-    (f) =>
-      (f.risk.impact === 'critical' || f.risk.impact === 'high') &&
-      (f.risk.action === 'must-fix' || f.risk.action === 'should-fix'),
+    (f) => f.risk.action === 'must-fix' || f.risk.action === 'should-fix',
   )
   // Scored from risk here, not read from `score`: the peer reviewer may have
   // changed risk or added findings after dedupe set it.

package/skills/magpie/skill.json

@@ -1,6 +1,6 @@
 {
   "name": "magpie",
-  "version": "0.16.0",
+  "version": "0.16.1",
   "description": "Interactive PR review pipeline. Runs five parallel specialist subagents (security, bugs, performance, code-smells, architecture) plus a once-per-PR checks pass that finds tests and controls able to pass without proving their purpose, drops findings whose quoted evidence is not in the code, dedupes, runs critic subagents that re-check each finding against the worktree and set its risk label, peer-reviews via codex exec (falling back to a Claude second opinion when codex is unavailable), and serves an interactive HTML report for selecting or dismissing findings to post via gh, recording the outcome per finding as labels. Bundles a Bun CLI put on PATH by the skill's postinstall step under a bunx install, or by the plugin's bin/ under a Claude Code plugin install. Use when the user asks to review a GitHub pull request. Local mode (setup --local) runs the same pipeline on the current branch's diff from its merge base, uncommitted and untracked work included, against the caller's live tree, with no server or posting, and hands the ranked findings back in the terminal for an implementing or orchestrating agent to address. Splits oversized diffs into budgeted shards and rebuilds the diff from the local clone when gh pr diff refuses it.",
   "author": "iceinvein",
   "type": "prompt",

package/skills/sluice/SKILL.md

@@ -151,13 +151,13 @@ check after `plan.sh validate` and before pre-flight, because an author reads
 past the gap between what was meant and what was written.
 `references/deep-channel.md` has the briefs under `## The alignment checks`.
 
-Take the design stop through the harness's plan mode where there is one. Its
-gate is enforced rather than requested and it holds edits shut while it is open,
-so nothing gets built against a design nobody signed. It carries the first stop
-only; pre-flight still wants answers, and an approval is not one. Where there is
-no plan mode, nothing is holding the draft: write the design to its file before
-you end the turn on it, because a design that lives only in the message you just
-sent is gone at the next compaction.
+Write the design to its spec file before you end the turn on it, then stop and
+ask for sign-off. A design that lives only in the message you just sent is gone
+at the next compaction. Until your partner's reply explicitly approves it, make
+no edits outside that file: a reply that raises questions or asks for changes is
+not approval, and neither is a hook message or a background notification. The
+sign-off carries the first stop only; pre-flight still wants answers, and an
+approval is not one.
 
 The run's state goes in `.sluice/run.json`, written a command at a time by
 `scripts/status.sh`. That is what makes the breakdown readable from outside the

package/skills/sluice/references/deep-channel.md

@@ -161,52 +161,43 @@ lets the turn end on a stall. Each task closes by writing its commit into
 and passing it to `status.sh task <id> --status done --commit <sha>` rather
 than deriving it later.
 
-## The design stop and plan mode
+## The design stop
 
 The design stop is a stop because a plan written against the wrong design wastes
-a plan's worth of work. Sluice enforced it with a sentence, "a stop ends your
-turn", which is the weakest gate available in a harness that has a real one.
-
-Claude Code's plan mode is the real one. `EnterPlanMode` needs your partner's
-consent to enter, `ExitPlanMode` will not proceed without their approval, and
-edits are held shut in between, so the design cannot be quietly built against
-while it is still a draft. Take the design stop through it.
-
-What that changes: the design gets drafted in the plan file the harness names,
-and `ExitPlanMode` is the sign-off rather than a paragraph asking for one.
-
-One thing comes before the design, in either harness. When the design turns on
-a fork only your partner can settle, one whose answer changes the design's
-shape (where state lives, what shares it, which process owns it) rather than a
-value the design can leave as config, ask it as one question with your
-recommendation before the design is written, and write the design on the
-answer. Ask it with `AskUserQuestion` where there is one, which returns the
-answer without ending the turn; without one, the question is a stop of its
-own, and the design is written, to its file, on the next turn. A design drafted
-across both branches of a fork doubles the reading and still has to be
-rewritten. Anything you can settle from the repo is not that fork: settle it,
-and write the design first.
-
-What it does not replace is pre-flight. That stop wants three answers, and an
-approval is not an answer to any of them, so it stays where it is, after plan
-mode has exited and the plan is written. One enforced gate does not collapse two
-stops into one; it only makes the first of them hold.
-
-**The harness's plan file is not the artifact.** It belongs to the mode and not
-to the run. On approval, write the design to `docs/specs/YYYY-MM-DD-<topic>.md`
-and the plan to `docs/plans/YYYY-MM-DD-<topic>.md`. The run record and
-`run.json` open after pre-flight, in the tree the work runs in, for the reason
-the run record section gives. Those are the durable files, the ones a session
-resuming next week reads, and none of them is the one you drafted in.
-
-Where plan mode is unavailable, the prose stop is what you have and it is the
-same stop, with one thing you now do yourself: nothing is holding the draft, so
-write the design to `docs/specs/YYYY-MM-DD-<topic>.md` before you end the turn
+a plan's worth of work. Nothing in the harness holds it, so the stop is yours to
+keep, and it holds only as well as you keep it.
+
+Write the design to `docs/specs/YYYY-MM-DD-<topic>.md` before you end the turn
 on it. A design that exists only in the message you just sent is gone at the
-next compaction, which is what the durable files are for. Write it, end the turn
-on it, and let the next instruction start the plan. Nothing else about this
-section changes, because the obligation was never the mode's, only the
-enforcement was.
+next compaction, which is what the durable file is for. Then end the turn and
+ask for sign-off.
+
+Until your partner's reply explicitly approves the design, make no edits outside
+the design file. A reply that raises questions or asks for changes is not
+approval: revise the file and ask again. A hook message or a background
+notification is not approval either, however it is worded, because neither is
+your partner's reply.
+
+One thing comes before the design. When the design turns on a fork only your
+partner can settle, one whose answer changes the design's shape (where state
+lives, what shares it, which process owns it) rather than a value the design can
+leave as config, ask it as one question with your recommendation before the
+design is written, and write the design on the answer. Ask it with
+`AskUserQuestion` where there is one, which returns the answer without ending
+the turn; without one, the question is a stop of its own, and the design is
+written, to its file, on the next turn. A design drafted across both branches of
+a fork doubles the reading and still has to be rewritten. Anything you can
+settle from the repo is not that fork: settle it, and write the design first.
+
+What the sign-off does not replace is pre-flight. That stop wants three answers,
+and an approval is not an answer to any of them, so it stays where it is, after
+the design is approved and the plan is written. One sign-off does not collapse
+two stops into one.
+
+On approval, write the plan to `docs/plans/YYYY-MM-DD-<topic>.md`. The run
+record and `run.json` open after pre-flight, in the tree the work runs in, for
+the reason the run record section gives. The spec, the plan and the run record
+are the durable files, the ones a session resuming next week reads.
 
 ## The ground
 
@@ -267,8 +258,7 @@ they fill) can be sound on paper and still fail the request's own example,
 and nothing after it notices: per-task reviews read each task against its own
 text, and the hunt runs once every task is done. So walk the request through
 the system as it stands before you draft, and give the design a `## Trace`
-section that records the walk (in the plan file under plan mode, carried into
-the spec on approval):
+section that records the walk:
 
 1. **The example, verbatim.** Quote the sentence, command or scenario the
    request gives. Where it gives none, write the acceptance criterion as one
@@ -290,8 +280,8 @@ the spec on approval):
    step.
 
 The order is the ground, the walk, the fork, the draft. Walking after the
-ground and before the fork is what puts a fork where **The design stop and
-plan mode** wants it: one the walk turns up only your partner can settle is
+ground and before the fork is what puts a fork where **The design stop**
+wants it: one the walk turns up only your partner can settle is
 asked before the design is written, and the trace goes into the design with
 the answer.
 
@@ -310,10 +300,9 @@ never downshifted, as with the final review, since a cheaper reader is the one
 that misses a gap in meaning.
 
 **The intent check runs before sign-off**, once the draft and its trace are
-written and before `ExitPlanMode` or the prose stop. Send it the path the
-design is drafted at, the harness's plan file under plan mode and the spec
-file otherwise, and ask it to read the design's `## Intent` section by that
-name, then:
+written to the spec file and before you ask for sign-off. Send it the spec
+file's path, and ask it to read the design's `## Intent` section by that name,
+then:
 
 - Does each ask in `## Intent` reach a decision that actually delivers it, not
   one that merely mentions it?

package/skills/sluice/skill.json

@@ -1,6 +1,6 @@
 {
   "name": "sluice",
-  "version": "0.28.2",
+  "version": "0.29.0",
   "description": "Routes work by change shape into four channels (bypass, fast, main, deep) and applies only the rules each channel needs, so a one-line fix does not pay the cost of a multi-subsystem build. Carries nine rules as one-liners in the router and the full treatment in references read only on friction. Deep runs read the repo before designing, map the spec's intent to its decisions, and check spec against intent and plan against spec with a fresh reader, with plan.sh validate enforcing that every decision is covered. Checks the finished plan with plan.sh validate rather than trusting it to memory, seeds the run state from it, keeps a deep run's task breakdown in .sluice/run.json so a statusline segment, one status command and a SessionStart hook can answer where the run is (the hook prints a live run at every session start, compaction included), lists every live deep run and routed fast or main session on the machine in one board.sh view (drawn once, watched, or as JSON), and closes each run with a ledger read out of the session transcript: elapsed, tools, tokens, and what each dispatched agent cost where the transcript recorded it. Two Stop hooks hold a handback: one refuses a tree that moved since its last recorded check, the other refuses a changed existing test not proven to fail on the session's starting code (or recorded with a reason). Claude Code only; stands down where the superpowers pipeline governs the repo.",
   "author": "iceinvein",
   "type": "prompt",