snapcode-pr

A recipe skill for pull request descriptions that use Snapcode images well. It assumes the `snapcode` base skill is installed — that skill owns render mechanics; this one owns *what a good PR description looks like and where images belong in it*.

Reviewers decide in seconds whether a PR is safe. Give them, in order:

1. What + why — two or three sentences: what changed and the reason. No images here.
2. The change, visualized — for anything touching important logic, a Snapcode diff image of the key hunk. Reviewers grasp a colored diff faster than a wall of description.
3. How to verify — steps or screenshots proving it works (see test evidence below).
4. Risk + rollback — what could break, how to revert. Text only.

• Diffs for logic, not for everything. One or two diff images of the hunks that matter. A PR description with ten images is as unreadable as one with none.
• Link the full diff too. The image is a summary; always keep GitHub's file links for line-level review. Images never replace reviewable text.
• Keep hunks short. Use --lines to show the 5–20 lines around the change, with a line or two of context — not the whole file.
• Match the repo's tone. Default to github-dark; if the project README uses light visuals, match that instead.
• Store images in `.github/assets/` and reference with relative paths. Images committed with the PR survive branch deletion; paste-uploads sometimes rot.
• Regenerate after rebase. If the code changed after review feedback, re-render the diff image — a stale image is worse than none.

1. Identify the 1–2 hunks a reviewer must understand to approve.
2. Extract the changed region to a scratch file (or use the real file with --lines).
3. Render the diff (base skill): snapcode generate --file src/parser.ts --lines 40-58 --diff added:44-50,removed:41 --title parser.ts --out .github/assets/pr-123-diff.png
4. Write the description: what/why, the image(s) with a one-line caption each, verification steps, risk.