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/ymm-oss/fsl/checkpointnpx skills add ymm-oss/fsl --skill checkpointgit clone --depth 1 https://github.com/ymm-oss/fslWhat 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.00027 | $0.00267 |
| Opus 5 | $0.00014 | $0.00133 |
| Sonnet 5 | $0.00005 | $0.00053 |
| Haiku 4.5 | $0.00003 | $0.00027 |
Grade A, and why
checkpoint 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 3d 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.
What it actually says
Checkpoint an FSL task
Use this skill at a meaningful boundary, before /compact, before /clear, and before handing work to another agent or person.
- Re-read
tasks/active.md,git status --short, and the relevant diff. - Verify changed files and observed command output instead of relying on conversation history.
- Preserve the goal, authority surface, current state, decisions, invariants, evidence, changed files, failed approaches, verification results, discovered follow-ups, remaining work, and one concrete next action.
- Remove narration, raw logs, superseded hypotheses, and machine-specific absolute paths.
- Do not claim a test or check passed unless its output was observed in this worktree.
- Reconcile every discovered soundness defect: it must be fixed in scope, linked to an existing or
newly created issue, or marked
authorization requiredwith an explicit user request. Do not mark the task complete while such a finding exists only in chat, review output, or agent memory.
The result must let a fresh Codex session continue safely without reconstructing the conversation.
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.
- 3d ago First seen · 22 lines · 27 tokens per session scan A a7b32af416d6
checkpoint is a skill published in the GitHub repository ymm-oss/fsl (21 stars, last pushed 5d ago), licensed Apache-2.0. It adds 27 tokens to every session and 267 once invoked, about $0.0001 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-30.
Other skills, from other repositories
propagate
Generate tests from Allium specifications. Use when the user wants to propagate tests, generate test files from a spec, write tests for a specification, create property-based tests, produce state machine tests, check test coverage against spec obligations, or understand what tests a specification requires.
allium
Give your AI agents something more useful than a prompt. Velocity through clarity.
elicit
Run a structured discovery session to build an Allium specification through conversation. Use when the user wants to create a new spec from scratch, elicit or gather requirements, capture domain behaviour, specify a feature or system, define what a system should do, or is describing functionality and needs help…
tend
Tend the Allium garden. Use when the user wants to write, edit, update, add to, improve, clarify, refine, restructure, fix or migrate Allium specs. Covers adding entities, rules, triggers, surfaces and contracts, fixing syntax or validation errors, renaming or refactoring within specs, migrating specs to a new…
weed
Weed the Allium garden. Find where Allium specifications and implementation code have diverged, and help resolve the divergences. Use when the user wants to check spec-code alignment, compare specs against implementation, audit for spec drift or violations, sync specs with code or code with specs, or verify whether…
witness
Independently witness that an Allium loop's convergence claim is true and was reached honestly. Use when the user wants to verify a loop's self-report, confirm tests really pass and no generated test was weakened, produce a convergence certificate or witness record, gate CI on a trustworthy signal, or check that an…