crisperit-skillsBLOCK

From the repository's own README, as read at the audited commit. Badges and raw HTML are left out.

/code-walkthrough                          # working tree plus staged changes
/code-walkthrough this branch              # main...HEAD
/code-walkthrough 123                      # that PR
/code-walkthrough HEAD~3..HEAD
/code-walkthrough explain the auth flow    # code as it stands, no change needed

The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.

---
name: code-walkthrough
description: Use when the user wants a change or an area of code shown to them rather than searched: "visual diff", "visualize diff", "visualise diff", "visualize-diff", "visualize this PR", "visualise this branch", "visual recap", "review my changes visually", "show me what changed", "turn this PR into a review page", "graph the symbol changes in this PR", "review this with me", "walk me through this change", "walk me through this PR", "explain the auth flow", "explain how billing works", "how does X work", "walk me through the auth flow", "help me understand this codebase", "help me understand src/parser/", or /code-walkthrough, or "set up code-walkthrough"; both the -ize and -ise spellings mean this skill. Turn a git diff, commit range, branch, GitHub PR, or an unchanged area of code into a self-contained local HTML walkthrough page: model-drawn pictures, annotated diff walkthrough, per-line comments to hand back to the agent or post to the PR. Reviews or explains code that already exists, unlike a planning skill (plans work that does not exist yet) and unlike a code-review skill (hunts defects rather than recapping or visualizing).
---

# Code Walkthrough

The diff target is what the user named when invoking this skill (in Claude Code: `$ARGUMENTS`).
Style rule for all prose: apply the no-ai-slop skill if available, otherwise plain sentences, no
dashes, no filler, no hedging.

## 1. Resolve the target

The target arrives as prose as often as a ref, so read the words:

| What the user said | Target |
|---|---|
| nothing | working tree plus staged changes, snapshotted as a second ref so it diffs as `git diff HEAD <snap>`, see below |
| "this PR", "my PR", "the PR", "this pull request" | the current branch's PR, see below |
| `123`, `#123`, a PR URL | that PR |
| "this branch", "my branch", "what this branch adds" | `<base>...HEAD` three-dot |
| `HEAD~3..HEAD`, `main...HEAD` | as given |
| "explain X", "how does X work", "walk me through the auth flow", "help me understand this codebase" | X as it stands, diffed against the empty baseline, see below |
| a bare path or directory, with no change described | ambiguous, see below |

"Explain X" and "walk me through the auth flow" name an area, not a ref: nothing downstream turns
prose into files on its own, so resolve it yourself first, see "Turning prose into a file list"
below. A bare path is genuinely ambiguous: it can mean "diff filtered to this path" (there is a
real change and the user is narrowing it) or "explain this path as it stands" (there is no change,
and the user wants it read cold). Tell the two apart from context: a branch ahead of its base,
staged changes, or the words "diff" or "changes" mean the first; a clean checkout of the base
branch, or "explain", "how does", "understand", "walk me through" attached to the path, mean the
second. When neither signal is there, ask the user in one line rather than guessing; guessing wrong
here means redoing the whole walkthrough.

### Turning prose into a file list

Nothing downstream reads prose, so "the auth flow" has to become paths before `references/static.md`'s step 2 can start.
Keep it cheap: grep and glob the repo for the terms the ask names, skim the hits enough to tell
signal from noise, and propose the file list back to the user in one line, for example "That looks
like `src/auth/*.go` and `middleware/session.go`, 6 files. Use those?", before spending any
subagent budget on it. Do not write a new script for this: it is a grep-and-confirm pass, not a
search feature.

### Explain mode: diff against an empty baseline

"Explain X as it stands" names no second ref, so build one: an orphan commit wrapping the empty
tree. Every line in the named path then comes back as an addition and the machinery below runs
unchanged, one code path rather than two. That choice also sets the page's mode, `<explain>` in
`references/static.md`'s step 3. Explain mode has no size ceiling of its own either, so it
negotiates scope with the user before spending.

Read `references/explain-mode.md` now, before `references/static.md`'s step 2 writes anything: the baseline commands, the
three size bands that decide whether to proceed, mention the cost, or stop and offer cuts, and
what `--explain` changes downstream.

### Working tree target: a snapshot commit as the second ref

"nothing" names no second ref either: the working tree and the index are not commits. Give it
one with a snapshot, so `<head>` is the snapshot and `<base>` is `HEAD`, and every step
downstream that needs two refs runs instead of skipping.

```bash
idx=$(mktemp); cp "$(git rev-parse --git-path index)" "$idx"
GIT_INDEX_FILE=$idx git add -A --ignore-errors 2>/dev/null
snap=$(git commit-tree "$(GIT_INDEX_FILE=$idx git write-tree)" -p HEAD -m "code-walkthrough snapshot")
rm "$idx"
```

`--ignore-errors` matters in a sandbox, where a mounted dotfile can show up as an untracked
unsupported file type and would otherwise abort the add; the trailing `2>/dev/null` quiets that
same case but also hides a genuine staging failure, so if a snapshot ever looks incomplete, rerun
the `add` without the redirect to see why. The real index, working tree and every ref are
untouched: `snap` is a commit object nothing points at, so it never shows up in `git log` or `git
branch`. It sits as a loose object until a later `git gc` prunes it, not cleaned up the moment
this session ends. `references/static.md`'s step 2 then builds `raw.diff` and numstat from
`git diff HEAD <snap>` rather than plain `git diff HEAD`, which also picks up untracked files that plain `git diff HEAD`
misses. The page's title and output slug still say "working", not the snapshot's sha; only
`<base>`/`<head>` downstream change.

Links still skip themselves for this target too: `snap` is never pushed, so `head_pushed` comes
back false the same way it does for any other unpushed head.

### "This PR", and three-dot over two-dot

"This PR" resolves through the current 

BLOCKgrade D · trust 66/100 Do not install this without reading the findings. The audit found something that could harm you or your machine.

What the source does

Filesystem

declared (5 observation(s))

Network

declared (9 observation(s))

Shell

declared (4 observation(s))

Dependencies

pinned

Secrets in source

none-found

Findings (18)

}),!0),this.lastIndex=0}exec(e){this.matcherRe.lastIndex=this.lastIndex

this.rules.push([e,n]),"begin"===n.type&&this.count++}exec(e){

module = importlib.import_module(f"tree_sitter_{lang}")

module = importlib.import_module(module_name)

with urllib.request.urlopen(f"http://127.0.0.1:{port}/health", timeout=1) as resp:

f"http://127.0.0.1:{info['port']}{path}", data=data, method="POST",

if origin not in (f"http://127.0.0.1:{daemon.port}", f"http://localhost:{daemon.port}"):

self.base_url = f"http://127.0.0.1:{self._server.server_port}/v1"

for bad in ("../../etc/passwd", "/etc/passwd", "walkthrough/../../server.json"):

status, body = _rpc(daemon, "walkthrough_get", {"id": "../../etc/passwd", "key": KEY})

cw_testlib.write_config(home, {"p": {"base_url": "http://127.0.0.1:1", "model": "m"}},

docs/demo/walkthrough.gif

skills/code-walkthrough/assets/mermaid.min.js

The page can also offer Full access, where a thread edits files in a shared worktree. It is off by

default and gated by trust config: see "Full access" in `references/live.md`.

access may be offered (`trust.repos` also lets a repo clone without asking), see "Full access" and "Repos without a

[Full access](#full-access)) drop `propose_task` and add `reload_walkthrough`. `CLAUDE.md` and user

## Full access

Gates applied: no_behavioural_pass.