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 jamestexas/agents --skill claim-ledgergit clone --depth 1 https://github.com/jamestexas/agentsWrote 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/jamestexas/agents/claim-ledger)<a href="https://agentmods.dev/skills/jamestexas/agents/claim-ledger"><img src="https://agentmods.dev/badge/skills/jamestexas/agents/claim-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/jamestexas/agents/claim-ledger"><img src="https://agentmods.dev/badge/skills/jamestexas/agents/claim-ledger.svg" alt="Reviewed on agentmods" width="80" 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.1 | $0.00136 | $0.03753 |
| Opus 5.5 | $0.00054 | $0.01501 |
| Sonnet 5.5 | $0.00027 | $0.00751 |
| Haiku 4.5 | $0.00014 | $0.00375 |
Grade A, and why
claim-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 1mo 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 — 309 lines — stays where its author put it; the contents beside it link to each section on GitHub.
claim-ledger — every PR claim, tagged with the evidence you actually hold
The spine, one question:
For each behavior this PR claims, what is the strongest evidence I hold that it is true — and would I publish that evidence class next to the claim?
When you wrote code by hand, verification happened in your head while typing. When an agent writes it, that step has no home: the agent produces, you read, and the first real execution happens in a peer's head during review. That is why they find bugs you didn't. This skill gives verification a home before the PR opens, and — the part that matters more — tells you afterward which kind of miss each review comment was.
self-audit asks "is this diff clean?" test-fidelity asks "do these tests
constrain the code?" This skill asks "what did I actually verify, and what
did I merely believe?" It does not replace either; it wraps them.
Evidence classes
| Tag | Means | Requires |
|---|---|---|
RAN |
Executed against real code, observed the outcome | Command, exit code, output captured under commands/ |
READ |
Traced without executing | file:line citations, or a fresh-context adversarial verdict on this claim |
ASSUMED |
Not verified | Reason from the closed set below + one line naming the blocker |
UNLISTED |
(reconcile only) A reviewer found a claim you never enumerated | — |
ASSUMED reasons (closed set):
harness— could not execute: needs creds / a cluster / 40 minutes / is flaky. Name the exact blocker.context— do not know what a consumer or sibling package assumes. Name the consumer.budget— chose not to. Say so plainly.
Iron rules
- Correlated evidence does not upgrade. A test written in the same
session as the code it tests shares that session's misunderstanding. It is
READuntil it passestest-fidelity's spine question. Green is notRAN. - Every claim carries exactly one tag. Rows start as
ASSUMEDand are upgraded by evidence. An untagged claim is a lie of omission; the ledger is complete or it is not a ledger. - Reasons are a closed set. Free-text reasons do not aggregate, and
aggregation across PRs is the entire point of
reconcile. - The residue ships. The
ASSUMEDblock goes into the PR description verbatim. Discomfort about publishing a row is the signal to go discharge it — never to delete it. buildwithoutreconcileis a checklist.reconcileis what turns it into measurement. Skipping it is how you end up guessing "harness vs. skill" for another quarter.- Durable directory, never session tmp.
~/claim-ledgers/<org>-<repo>/<branch>/withledger.md,residue.md,commands/. Session scratch gets garbage-collected mid-run; that failure is already on the books incounterfactual-audit.
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.
- 1mo ago First seen · 309 lines · 136 tokens per session scan A fef93320a2ef
claim-ledger is a skill published in the GitHub repository jamestexas/agents (2 stars, last pushed today), licensed Apache-2.0. It adds 136 tokens to every session and 3,753 once invoked, about $0.0005 per session on Opus 5.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-09-05.
Other skills, from other repositories
guardian
Gatekeeping Git/PR by classifying change essence and recommending granularity, naming, and strategy; the ship recipe also executes PR delivery (create, CI watch, merge, cleanup) with Ask First on merge. Use when PR preparation, commit strategy, or gated PR delivery is needed.
spec-finish
Post-implementation completion workflow for Spec-backed Plans. Use after spec-implement completes to validate, review, create stacked commits, and open a PR via code-pull-request. Triggers only with an active Spec-backed Plan after spec-implement completes, including when the user says "finish", "done", or "complete"…
address-pr-feedback
Unified PR feedback workflow - collect, triage, and fix review comments in a single command.
spec-loop
Run an approved Spec-backed Plan (design.md and plan.json both present) unattended to a draft PR: implement and review each batch with fresh subagents, commit, then finish with one whole-branch review. Use when the user says "run it to the end" or "implement everything and open a PR".
address-pr-comments
Standard workflow to address pull request review comments in Cecil. Use when responding to review feedback, fixing requested changes, or preparing a clear reviewer reply with reproduction, fix, tests, and response.
PR Review
Manage pull request workflow.