---
name: snapcode-pr
description: Write pull request descriptions that use Snapcode-rendered visuals — diff images of the key change, before/after screenshots, and test-evidence snippets. Requires the snapcode base skill for render mechanics.
---

# 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*.

## PR structure that works

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.

## Where each image goes

| Image | Location | Snapcode settings |
|---|---|---|
| Key-change diff | Right after the "what changed" paragraph | `--diff added:<lines>,removed:<lines>` on the new code, `--title <file>` so reviewers know which file they're seeing |
| Before/after pair | Under a "Before / After" heading for behavior changes | Two renders of the same lines, identical theme — only the code differs |
| Config/schema change | Next to the config explanation | `--title` the config filename; use `--highlight` on the changed keys |
| Error/log evidence | In "How to verify", when the PR fixes a bug | Render the before-failure output or the after-success output, plain theme |

## Rules

- **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.

## Workflow

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.