/ripwire-change-check

name: ripwire-change-check
description: >
  Merge-SAFETY of an existing diff — yours before you push, or a PR you review: blast radius, tests to
  run, a broken contract (--edit-check=SYM), branch conflicts and landing order, unmerged work
  stranded on old branches, which ref defines it. Code QUALITY → quality-bar. Even a one-line leaf fix
  runs --edit-check.
allowed-tools: Bash, Read

Change check with ripwire

> Routing: > • Estimating a change you have NOT written yet (feasibility/plan/sizing) → **ripwire-before-you-build**. > • Did the code ITSELF get better or worse? (complexity/dup/dead delta) → **ripwire-quality-bar** — run it > FIRST; this is the chain **"did the code get worse" → "is it safe to merge".** > • Risk on an unfamiliar subsystem you did NOT write (not tied to a diff) → **ripwire-fresh-eyes**. > • Writing a test for EXISTING untested code (not vetting a diff) → **ripwire-write-tests**. > • Not sure which skill? → **ripwire-router**.

`<dir>` = repo root. Run from the repo with your working changes staged/unstaged, or check out the PR branch first. This works on a real diff — `--situ`, `--map-diff`, and `--pr-context` read `git diff` automatically.

The one-shot bundle — `--pr-context[=BASEREF]`

The flagship verb for this moment: a single no-LLM review-evidence bundle for the whole diff (working tree, or vs `BASEREF`). Per changed file: defined symbols, their callers, transitive blast radius, affected tests, co-change partners not in the diff, and owners — everything steps 1–5 assemble by hand, in one call:

ripwire <dir> --pr-context --legend=compact                # working-tree diff
ripwire <dir> --pr-context=main --legend=compact           # vs a base branch/ref

<pr-context base="working-tree" files="N"><file p="…" symbols="K">
  <impact dependents="…" files="…"/><tests count="…"/>
  <changed-symbols count="K"><s t="fn" n="…" p="…:L" callers="…"/> …

Use this first for the evidence dump; steps 1–5 below are the same ground as a narrated, one-pass walkthrough.

**Scope guard:** Do not turn a focused fix into a full merge audit merely because a diff now exists. Invoke this skill when the user is actually at the submit/review/merge-safety moment, or when the edit changes a contract or has unclear reach. But "obvious leaf-level fix with no signature/API change" is a claim, not a given — run `--edit-check=SYM` (the fast per-symbol sibling of step 8, ~ms warm) to confirm it before trusting it; a `status="contract-change"` result means the fix was not as leaf-level as it looked, and the full audit below is now warranted. Only a genuinely `"unchanged"` result plus the focused test plus `git diff --check` is enough to stop there, unless repository instructions require a broader gate. Never run `--pr-context` and then repeat its component steps without a specific unanswered question.

**The header is stamped `at="<sha>[+dirty]"`** — the commit the evidence was measured at (`--pr-context`, `--test-gate`, `--quality-delta` and `--map-diff` all carry it). Quote it whenever you paste findings into a PR comment or hand them to someone else: a review bundle outlives the HEAD it was taken from. A `+dirty` suffix means the numbers came from an **uncommitted** working tree — nobody else can reproduce them from that sha, so re-run after you commit before treating them as review evidence. Note `--situ`, `--cochange` and `--owners` carry **no** stamp — record the sha yourself if you quote them.

On a large diff the bundle can be huge — cap it with `--max-tokens=N` (e.g. `ripwire <dir> --pr-context --legend=compact --max-tokens=8000`): every changed file stays present with its structural counts (blast radius / tests / callers), the deep detail trims deepest-first, and `truncated=`/`est_tokens=` on the header report the fit. To feed an EXTERNAL reranker instead of reviewing directly, `--query="…" --format=candidates` (or `--for=…`) emits a flat `<cand r= s= n= id= k= p= l=>` top-K — identity + score + signature only, capped by `--top-k`.

1. **Situational awareness on the diff** — `ripwire <dir> --situ` (Reads `git diff` against HEAD; or `--situ=fileA.cpp,fileB.h` to name the changed set explicitly.) One pass, plain text:

• changed file count + the symbols they contain
• **transitive blast radius** — everything that reaches the changed symbols
• **tests to run** (`--affected` under the hood) — empty = no test cover for the changed code, **flag it**.

Each named test carries `run="<cmd>"` when a runner is derivable (a test-dir script whose stem matches the harness, or whose text names it), so the obligation is pasteable; **no `run=` means not derivable — never treat its absence as "there is no runner"**. Narrow the question to ONE function with `--affected=SYM` (or `--affected=file:NAME` when a path shares the name) instead of widening it to the whole file, and invert it with `--exercises=test/<harness>` to see what a given test actually covers. On a corpus where few harnesses have a runner, `--affected` serves the runner-less rows GROUPED: `<g hops="2" n="17" p="a,b,c" run_unknown="1"/>` is ONE row standing for 17 test files at the same hop distance (`p=` lists them comma-separated, a `,` inside a path written `&#44;`), with the not-derivable disclosure stated once for the group. Rows that DO have a `run=` stay single `<t>` rows. The obligation is unchanged — every path is still listed verbatim, and a row carries `run=` or `run_unknown="1"`, never neither.

• **co-change partners NOT in the diff** — files that historically move together (should they be in this

change too? — the Shotgun Surgery check: one change that has to land in many places, and did not)

2. **Hotspot risk** — `ripwire <dir> --hotspots --legend=compact` `<hotspots>` ranked by `score = churn × ccx`. Does any changed file appear in the top-10? A change that touches a high-score file deserves extra scrutiny; one