walk-commits — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited walk-commits (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
Walk the person about to merge a branch through it commit by commit, so they actually understand what they are shipping. The output is reviewer comprehension and a sign-off decision, not a defect list. For each commit you narrate the author's intent (not a restatement of the diff), anchor the single riskiest line, surface the choices that look odd on purpose, name what is absent by design, and flag anything needing the merger's explicit sign-off — then let them step to the next commit.
This skill exists because the highest-leverage finding in Cohen's peer-review dataset is author preparation: an annotated change walked through by a prepared narrator correlates with near-zero defect variance. The pipeline produces that annotation nowhere else. /pre-merge finds defects across the whole diff; /verify runs the app; /execute Step 5 checks acceptance criteria. None of them narrate the change commit-by-commit for the human who clicks merge.
This is a side-route skill. It does not block merge and is never auto-invoked.
It reconnects to the main pipeline at the /pre-merge → merge boundary: run it when you want comprehension before approving, then proceed to merge (and /compound if a durable lesson emerged). /pre-merge Phase 4 recommends it (without invoking it) when the person merging did not author the diff or hasn't internalized it; /execute Step 5/6 names it as an option before /pre-merge from the author side.
Use /walk-commits when:
Do not use /walk-commits:
/pre-merge's adversarial, dimension-based review./verify./execute Step 5's checklist./pre-merge --pr <n> reviewer-mode.The line that keeps this distinct from /pre-merge: comprehension and sign-off, not defect-finding. If you catch yourself enumerating bugs across files, you are running the wrong skill.
Cohen and Rigby both cap effective review at roughly 100–300 LOC and 30–60 minutes — past that, fatigue degrades comprehension and the walkthrough becomes the rubber-stamp it was meant to prevent. Spinellis supplies the epistemic reason: minimal comprehension — read selectively, with a goal, and stop when you understand enough to sign off, not when you have read every line. The walkthrough reads selectively per commit toward a goal; it never marches line-by-line through 800 lines.
If the diff is oversize (well past ~300 LOC of meaningful change, or many commits), do not power through in one sitting. Recommend chunking the walkthrough across sittings — by logical group of commits, or by subsystem — and say so explicitly before starting. A tired walkthrough is worse than no walkthrough.
Resolve the commit range to walk — the commits on this branch not yet on the base branch:
BASE_BRANCH=$(git symbolic-ref refs/remotes/origin/HEAD --short 2>/dev/null | sed 's@^origin/@@')
[ -z "$BASE_BRANCH" ] && for c in main master prod trunk; do git rev-parse --verify "$c" >/dev/null 2>&1 && BASE_BRANCH=$c && break; done
git log --oneline --no-merges "$BASE_BRANCH..HEAD"
git diff --stat "$BASE_BRANCH..HEAD"Do not hardcode main — detect the base (this repo itself uses prod). If the range is empty or the base can't be resolved, ask the user which range to walk.
Then present an overview before the first commit (Spinellis: overview first). It is short and does two jobs:
Naming the mode picks how each commit gets read. State which one this branch is and why.
Loop over the commits in order. For the current commit, read it with git show <hash> and produce the per-commit card below. Keep it tight — no padding, no diff restatement.
Derive intent with Spinellis's five-strategy function understanding, cheapest-first — stop at the first source that suffices:
Read the body only when the name and call sites fail to explain the change. This makes "intent" a disciplined derivation, not a paraphrase of the hunk.
Pick the single riskiest line with Spinellis's surface-signal scan — a catalog for where to point:
for deviation (<=, non-zero start) → likely off-by-one[lower, upper) half-open-range misreadcatch with no commentstatic / over-broad visibilityFALLTHROUGH omission in a switchanyAnchor it as file:line so the user can click straight to it. Detecting the replaced-symbol case: when a commit shows a large deletion of a symbol and a large addition elsewhere, check whether they are the same logical unit (rename detection, git log --follow, or matching call sites) before treating them as independent edits — then carry the finding through the existing Riskiest-line / Looks-odd-on-purpose / Absent-by-design card lines (no new card line needed).
Surface intentional-looking-odd choices with Spinellis's deviation = signal: any departure from a canonical form demands an explicit "why." Either the author intended it (and the walkthrough states the reason) or it is a bug. The deleted enabled=true filter that turns out to be the point of the change lives here — it looks like an omission but is the intent.
Name things absent by design by classifying each apparent omission (Spinellis): justified (deliberate, explained), careless (a real gap), or malicious (hidden). Forcing the classification stops the merger from glossing over a missing test, a skipped error path, or an unhandled state.
Decide sign-off items against the documentation trust hierarchy (Spinellis): tests and assertions outrank revision logs, which outrank comments, which outrank prose. Verify stated intent against the added test — the most executable evidence — not the commit message. A commit whose claimed behavior has no test backing it is a 🟡 at best.
Mark each commit 🟢 / 🟡 / 🔴:
#### Per-commit card
### <short-hash> — <commit subject> 🟢|🟡|🔴
**Files:** <the files this commit touches>
**Intent:** <why this change exists, derived cheapest-first — not a diff restatement>
**Riskiest line:** `path/to/file.ts:NN` — <what to watch and why it is the riskiest>
**Looks odd on purpose:** <deliberate deviations and the reason — or "none">
**Absent by design:** <omissions, each classified justified / careless / malicious — or "none">
**Sign-off:** <what the merger must confirm; cite the test that backs the intent, or note its absence>Omit a line when it genuinely has nothing (e.g. "Looks odd on purpose:" on a boring commit) — empty scaffolding is padding.
#### Optional: render the commit as a line-anchored callout
The card above is chat text by default, and for most commits that is the right altitude. But when a commit's riskiest line or deliberate oddity is hard to grasp out of context — a subtle change inside a long hunk, a multi-file commit whose pieces only make sense together — render that single commit as a focused, line-anchored callout using the shared `references/visual-rendering-core.md` rendering core (the same core /visual-recap authors against). The card's fields map straight onto the core's blocks: the riskiest line and looks-odd-on-purpose entries become callouts anchored to the real after-side lines of git show <hash>, and the sign-off becomes a signoff-<short-hash> unit.
This is an enhancement, not a new default — keep it optional and keep the stepper:
git show, never retyped; you write only the note. Visual emphasis must not exceed the real change (the core's Lie Factor ≤ 1 rule).recap-feedback v1 block (keyed by the stable signoff-<short-hash> / c-<file-slug>-L<line> ids) and pasted back — instead of, or alongside, the AskUserQuestion answer. Promote anything durable to a GitHub PR review comment..context/ or mktemp path and deleted when the walkthrough ends — per the core's transient-artifact rule. What persists is the 🟢/🟡/🔴 sign-off, not the file.The AskUserQuestion stepper below remains the spine of the walkthrough; the callout is a per-commit zoom you opt into, not a replacement for it.
After each commit's card, advance the walkthrough with a single AskUserQuestion (one question per turn — never a menu of separate questions). Offer:
"use server" boundary with a next build").When a commit is opaque, do not deep-recurse line by line. Take Spinellis's breadth-first escape and use execution as a reading tool: read the test as the spec, try another call site, or escalate to a next build / /verify. PR-level example: a migrated "use server" action with a new injectable db param was confirmed by a build, not by staring at the diff. Naming this as a legitimate reading move keeps comprehension moving instead of stalling.
After the final commit, offer a wrap-up via AskUserQuestion:
If any commit is still 🔴, say plainly that the branch is not yet understood well enough to sign off, and name what is unresolved. The skill's job is honest comprehension, not a green light.
/pre-merge does that and emits advisory findings./verify does that./execute Step 5./pre-merge already covered, fold it back into /pre-merge as an optional phase./pre-merge → merge boundary. Run it before approving; proceed to merge once commits are understood, then /compound if a durable lesson emerged./walk-commits does not invoke anything.~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.