Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/liustack/vibemaster/snapshotnpx skills add liustack/vibemaster --skill snapshotgit clone --depth 1 https://github.com/liustack/vibemasterWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/liustack/vibemaster/snapshot)<a href="https://agentmods.dev/skills/liustack/vibemaster/snapshot"><img src="https://agentmods.dev/badge/skills/liustack/vibemaster/snapshot.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00154 | $0.01475 |
| Opus 5 | $0.00077 | $0.00737 |
| Sonnet 5 | $0.00031 | $0.00295 |
| Haiku 4.5 | $0.00015 | $0.00147 |
Grade A, and why
snapshot scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 4d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 56 lines — stays where its author put it; the contents beside it link to each section on GitHub.
snapshot: task-state snapshots
Iron rule: the reader is a new session that knows nothing. There's exactly one bar to clear: reading only this snapshot, they can carry on without re-asking, re-checking, or re-litigating decisions that are already settled. A memo written for yourself doesn't clear it.
Writing a snapshot (wrapping up)
Save it to the workspace draft directory at .issues/<YYYY-MM-DD-topic>/snapshot.md. If the task already has a directory, write into it. When the same task wraps up again later, update that same file (it's a living document, not a log). Before writing to disk, make sure the draft directory is ignored: if git check-ignore .issues fails, append .issues/ to .git/info/exclude (a local ignore, leaving the shared .gitignore untouched) and let the user know. In a non-git environment there's no commit risk, so write directly.
Where the handoff lands decides what must travel. .issues/ is machine-local (gitignored), and uncommitted changes exist only here, which is exactly right when the reader is this machine's next session. When the work moves to another machine or someone else's agent, a local snapshot hands over nothing: push the work to a WIP branch, carry the snapshot's content in something that travels with the repo (the commit message, the PR description, or a file the user chooses to commit), and say out loud which parts stay machine-local.
Five sections, ordered by what the new session needs, not by chronology:
- Goal and current state: one line on what the task is and how far along it is overall.
- Decisions already made (questions not to reopen): each one with its reasoning. The biggest waste in a new session is re-litigating something already settled: write the reasoning in full, this section never gets to summarize.
- Verified state: which files changed, and the actual results of tests and lint (pass or fail, and what command ran them). Anything unverified gets written as "unverified," never "should be fine."
- Next steps and blockers: an ordered to-do list, each item with enough context to act on. Blockers get their own list: questions waiting on the user's call stay exactly as open questions, don't decide for them.
- State pointers: branch, uncommitted changes, commands that need rerunning, key file paths, rollback point, and what has to be running for the work to continue (dev server, containers, required environment variables).
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 4d ago First seen · 56 lines · 154 tokens per session scan A 317fa3d4ebcc
snapshot is a skill published in the GitHub repository liustack/vibemaster (11 stars, last pushed 20d ago), licensed MIT. It adds 154 tokens to every session and 1,475 once invoked, about $0.0008 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
nunit-testing
Use when writing or modifying tests in NUnit's own test projects, or when making a behavioral change to production code that needs test coverage. Covers test structure, attribute choice, helper visibility, platform guards, and which test projects are real.
tdd
Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests.
nunit-api-design
Use when adding or modifying public API surface in NUnit — new or changed constraints, attributes, assertions, helpers, or any type/member visibility change. Covers the conventions NUnit maintainers enforce for types that ship to consumers of the framework.
agentic-testing
MANDATORY before creating, editing, or reviewing tests in agentic.nvim, and before behavior changes that require TDD. Covers mini.test workflow, red/green rules, commands, mark-count checks, and which test references to load.
test-first-bugs
Enforces a test-driven bug-fixing workflow. Use when a user reports a bug, failing code, an error, or asks to fix something.
tdd
Test-driven development (TDD) process used when writing code. Use whenever you are adding any new code, unless the user explicitly asks to skip TDD or the code is exploratory/spike.