update-snapshots
Skill2 starsChanged 39 days agoBSD-3-ClauseView on GitHub
Reviews and updates `insta` golden snapshots after changes to user-visible CLI surface (subcommands, flags, help text, error messages). Invoke whenever a change touches `src/cli/**`, `src/main.rs`, `#[derive(Parser)]`, or `#[arg(...)]` sites — *before* declaring the work done. Triggers on terms like "snapshot", "insta", "golden", "help_all", and "snap".
In this repository15 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- changelogSkill
- commit-twiddleSkill
- format-tableSkill
- releaseSkill
- update-adr-inventorySkill
- update-snapshotsSkill
- version-bumpSkill
- changelogSkill
- commit-twiddleSkill
- format-tableSkill
- releaseSkill
- update-adr-inventorySkill
- version-bumpSkill
The file
We split this skill into the rules it gives an agent
5 rules. About 0 are common, 2 are distinctive, and 3 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 36
If either produces output, run the steps below before declaring the work done.
- Distinctive: line 80
Investigate: when the diff contains anything you did *not* intend — for example:
- Very specific: line 88
Do not run --accept. Read the diff, identify the regression, fix the source, and re-run Step 1.
- Very specific: line 102
Never run cargo insta accept blindly.
- Very specific: line 107
If a .snap.new file is present in git status but not produced by your changes, re-run cargo test to regenerate, then investigate — it is …
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Update Snapshots
Review and accept (or reject) insta snapshot drift after changes that affect the
CLI surface. The most frequently affected golden file is
tests/snapshots/integration_test__help_all_output.snap,
generated by the help_all_golden test in
tests/integration_test.rs.
./scripts/build.sh runs cargo build, cargo fmt --check, cargo clippy, and
cargo test, so plain build-script success is not enough — snapshot drift will
surface in cargo test and CI will fail until the .snap file is updated to match
the new output.
When to invoke
Invoke this skill whenever the change touches any of:
src/cli/**— clap command/subcommand definitions, help textsrc/main.rs— top-level CLI wiring- Any
#[derive(Parser)],#[derive(Subcommand)],#[command(...)], or#[arg(...)]site - Error messages or other output covered by an
insta::assert_snapshot!call
A quick way to detect this against the working tree:
git diff --name-only HEAD -- src/cli src/main.rs
git diff HEAD -- src | grep -E '#\[(derive\(Parser|derive\(Subcommand|command|arg)'If either produces output, run the steps below before declaring the work done.
Step 1 — Run the snapshot tests
cargo insta test --test integration_test --review--review runs the tests and, if any snapshot has drifted, drops you into an
interactive review. From a non-interactive context, use:
cargo insta test --test integration_test --no-quiet…and then inspect the produced .snap.new files manually:
git status --porcelain tests/snapshots/
ls tests/snapshots/*.snap.new 2>/dev/nullStep 2 — Decide: accept or investigate
For each pending snapshot, diff it against the committed file:
diff -u tests/snapshots/<name>.snap tests/snapshots/<name>.snap.newThen choose:
Accept the new snapshot when the diff reflects an intended change — every added / removed / modified line corresponds to a CLI change you just made (new subcommand, renamed flag, edited help text, etc.). The fix is:
cargo insta accept --test integration_test…or equivalently
cargo insta test --test integration_test --accept. Stage the updated.snapfile alongside the source change in the same commit so the diff is reviewable end-to-end.Investigate when the diff contains anything you did not intend — for example:
- Lines disappear that you did not remove (a subcommand silently dropped from the help tree)
- Flag default values change unexpectedly
- Help text for an unrelated command shifts
- Ordering changes that suggest a regression in the help generator
Do not run
--accept. Read the diff, identify the regression, fix the source, and re-run Step 1.
Step 3 — Re-run the full test suite
cargo testA clean cargo test after acceptance confirms the snapshot is committed and the
broader suite is unaffected.
Notes
- Never run
cargo insta acceptblindly. Accepting drift you did not cause is how silent regressions ship. - Snapshots live next to the test that produced them under
tests/snapshots/. The naming convention is
<test_module>__<snapshot_name>.snap. - If a
.snap.newfile is present ingit statusbut not produced by your changes, re-runcargo testto regenerate, then investigate — it is likely a stale artefact from a previous failed run. - For background and motivation, see
docs/STYLE_GUIDE.md §STYLE-0010 (
testingtag).
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

