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 skills add svy04/ballast --skill decision-ledgergit clone --depth 1 https://github.com/svy04/ballastWrote 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/svy04/ballast/decision-ledger)<a href="https://agentmods.dev/skills/svy04/ballast/decision-ledger"><img src="https://agentmods.dev/badge/skills/svy04/ballast/decision-ledger/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/svy04/ballast/decision-ledger"><img src="https://agentmods.dev/badge/skills/svy04/ballast/decision-ledger.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector pass
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.1 | $0.00048 | $0.01371 |
| Opus 5 | $0.00024 | $0.00685 |
| Sonnet 5 | $0.00010 | $0.00274 |
| Haiku 4.5 | $0.00005 | $0.00137 |
Grade A, and why
decision-ledger 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 9d 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 — 52 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Decision ledger
One file holds every confirmed decision: memory/DECISIONS.md (run brain-init if it doesn't exist yet). The ledger is append-only — nothing is ever edited or deleted. Changed minds are recorded as new entries that supersede old ones.
Entry format
## D-021 · <short title> — <YYYY-MM-DD> (<source: who confirmed, in what context>)
<What was decided, in the decider's own terms. Include the reason if one was given.>
Rules
- Append-only. Never rewrite, reorder, or remove an existing entry. The ledger is trustworthy precisely because it cannot be quietly rewritten.
- User-confirmed only. Record what the user actually decided, not what you proposed. If your proposal was adopted, say so:
(AI-proposed, user-confirmed). Never promote your own suggestion to a decision — and never promote your reading of a non-answer (see Provisional readings below). - Supersede, don't edit. When a decision changes: write a new entry stating what changed and
supersedes D-xxx, then add exactly one line to the old entry:→ superseded by D-yyy (YYYY-MM-DD). That backlink is the only permitted touch to an old entry. - Record in-session. The moment a decision is confirmed, write it — not at the end of the conversation. Topic changes destroy unwritten decisions.
- Sequential ids.
D-001, D-002, …Never reuse a number, even after supersede. - Surface conflicts. If a new decision contradicts a standing entry and the user hasn't acknowledged that, point it out before recording — then record whichever the user confirms, with the supersede link.
- No compression tool rewrites this file. Tools that shrink memory files for token savings (caveman-compress and the like) drop the load-bearing words first — negations, numbers, who-confirmed, supersede links — and the loss is silent. The ledger shrinks only by hand, with the original kept beside it and a part-by-part comparison before the short version is accepted. The
memory-compress-guardrule in the example catalog says this to the model on the prompt where it matters. - A supersede ends with a sweep. The old decision's wording usually lives in more places than the ledger — docs, copy, configs, skill files. Search the project for it, fix each surface or register the stragglers in
memory/OPEN-QUESTIONS.md, then add one sweep line to the new entry:sweep: <what was fixed> (YYYY-MM-DD), appending→ Q-xxfor anything left open. Like the supersede backlink, that one line is a permitted touch to an already-written entry — until it's there, the dead decision keeps working: the ledger says B while the README still says A.
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.
- 9d ago First seen · 52 lines · 48 tokens per session scan A e083d9bf1203
decision-ledger is a skill published in the GitHub repository svy04/ballast (71 stars, last pushed 15d ago), licensed MIT. It adds 48 tokens to every session and 1,371 once invoked, about $0.0002 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
alive:save
The human wants to checkpoint. Or: the stash has grown heavy — 5+ items, 30+ minutes, a natural pause in the work. The squirrel doesn't decide when to save. It surfaces the need and lets the human pull the trigger. Runs the full save protocol: confirms stash, writes log, updates state, generates projections…
alive:capture-context
Use when external content arrives in the session — emails, transcripts, screenshots, documents, files, or in-session research worth keeping. Also use when there's nothing obvious to capture — the skill checks 03Inbox/ for unrouted files and enters inbox scan mode. Stores raw content, routes to bundles, extracts tasks…
alive:session-history
Revive sessions (quick or heavy), browse, and search — 'what happened recently?', 'find the session where we discussed X', 'revive yesterday's session'. For single-session recall and multi-session browsing. If the human needs to merge multiple sessions into one working context or detect conflicts between parallel…
alive:load-context
The human mentions a walnut to work on, asks about a specific venture/experiment/project, or wants to check status — not just explicit 'load X'. Load the brief pack (3 files), resolve the people involved, check the active bundle — then surface one observation and ask what to work on. Context loads in tiers: walnut and…
alive:mine-for-context
Deep context extraction from source material. Creates reference bundles, builds extraction plans, tracks what's been extracted, and discovers new targets — people, subjects, patterns, connections. The archaeologist that turns raw sources into structured knowledge. Can be invoked by alive:session-history for targeted…
alive:my-context-graph
Render an interactive map of your world. Generates the world index from all walnut and bundle frontmatter, then produces a force-directed graph showing connections between walnuts, people, bundles, and tags. Opens in the browser.