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 pyyush/goal --skill overclaimgit clone --depth 1 https://github.com/pyyush/goalWrote 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/pyyush/goal/overclaim)<a href="https://agentmods.dev/skills/pyyush/goal/overclaim"><img src="https://agentmods.dev/badge/skills/pyyush/goal/overclaim/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/pyyush/goal/overclaim"><img src="https://agentmods.dev/badge/skills/pyyush/goal/overclaim.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.00129 | $0.01873 |
| Opus 5.5 | $0.00052 | $0.00749 |
| Sonnet 5.5 | $0.00026 | $0.00375 |
| Haiku 4.5 | $0.00013 | $0.00187 |
Grade A, and why
overclaim 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 2mo 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 — 156 lines — stays where its author put it; the contents beside it link to each section on GitHub.
overclaim — claim only what the evidence supports
Purpose
Autonomous and long-running work fails in a specific way: the model produces a plausible artifact and then describes it as more finished than it is. A refactor "is done" when one path is untested. Tests "pass" when they were never run this turn. A migration "matches the original" when only a proxy was checked.
overclaim is the discipline that stops this. It does not slow real work down —
it converts a vague success sentence into a claim ledger where every
assertion carries an explicit, honest support level. It is the gate the /goal
dispatcher relies on before it will ever record status: achieved.
The rule it enforces, in one line:
You may only call something done if you verified it done — this turn, against real evidence. Everything else gets labeled, not rounded up.
When this skill runs
Run it before any of these:
- writing
status: achievedto a goal record (or callingmcp__goal__update_goal); - calling
mcp__goal__report_progress; - sending the user a sentence that asserts a verifiable outcome — "done", "fixed", "implemented", "passing", "green", "works", "complete", "matches", "reproduced", "ready".
If you are about to type such a sentence and you did not run the check that proves it in the current turn, stop and run this skill.
The five support levels
Every claim you are about to make gets exactly one label.
| level | meaning | may it count toward "achieved"? |
|---|---|---|
| confirmed | You verified it this turn against direct evidence — ran the command and saw the result, read the file and saw the content, observed the test pass. | yes |
| partial | The main thing is done but a named sub-requirement is unverified, approximated, or out of scope. | no |
| proxy-only | You have only indirect evidence — a related test passes, a large diff exists, the code "looks right". This is not proof. | no |
| unverified | You implemented or changed something but never checked the result. | no |
| blocked | It cannot be verified with the materials available. You must say what is missing. | no |
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.
- 2mo ago First seen · 156 lines · 129 tokens per session scan A a1b645d30a5f
overclaim is a skill published in the GitHub repository pyyush/goal (1 stars, last pushed 5mo ago), licensed MIT. It adds 129 tokens to every session and 1,873 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-08-31.
Other skills, from other repositories
fable-voice
Use when about to write your final reply, a summary, PR description, commit message, or any user-facing conclusion — enforces Fable's outcome-first, prose-first communication contract.
fable-fanout
Use when a task involves 2+ independent units of work (files, modules, questions) or any broad codebase sweep — enforces Fable's delegation-first parallel orchestration.
fable-turn-check
Use before ending any turn that involved multi-step work — Fable's end-of-turn gate catches promised-but-undone work, buried findings, and unverified claims.
confidence-gate
When you're about to claim success ("fixed", "done", "works", "passing tests") at the end of a turn, verify the claim is backed by actual evidence in this session. presence's Stop hook will flag a success claim that has no recent test/build pass behind it. Be aware of this gate and either run the verification, or…
baton-setup
One-time setup and health check for fable-baton. Use when the user asks to set up, configure, verify, or troubleshoot fable-baton - sets the default model to "best" (Fable 5 with Opus fallback) in /.claude/settings.json and verifies the plugin is fully installed.
are-you-done
A completion checker for coding work that asks for evidence before allowing an assistant to say a task is finished.