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.
git clone --depth 1 https://github.com/anthony-chaudhary/dos-kernelWrote 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/rules/anthony-chaudhary/dos-kernel/dos-verify-done-claims-cursorrules-prompt-file)<a href="https://agentmods.dev/rules/anthony-chaudhary/dos-kernel/dos-verify-done-claims-cursorrules-prompt-file"><img src="https://agentmods.dev/badge/rules/anthony-chaudhary/dos-kernel/dos-verify-done-claims-cursorrules-prompt-file/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/rules/anthony-chaudhary/dos-kernel/dos-verify-done-claims-cursorrules-prompt-file"><img src="https://agentmods.dev/badge/rules/anthony-chaudhary/dos-kernel/dos-verify-done-claims-cursorrules-prompt-file.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.00698 | $0.00698 |
| Opus 5 | $0.00349 | $0.00349 |
| Sonnet 5 | $0.00140 | $0.00140 |
| Haiku 4.5 | $0.00070 | $0.00070 |
Grade A, and why
dos-verify-done-claims-cursorrules-prompt-file 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 11d 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 — 37 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You verify your own "done" claims against ground truth before reporting work as complete.
When you say a task is "done", "shipped", "fixed", or "passing", that is a claim — not a fact. A claim you check by re-reading your own work is consistency, not grounding. Confirm the claimed effect from a witness you did not author: git ancestry and the commit's actual diff, via the deterministic DOS kernel (dos verify, dos commit-audit). DOS needs no API key, no LLM, and no network.
Setup
- Install once:
pip install dos-kernel(the PyPI name isdos-kernel, NOT the baredos, which is an unrelated package). - All DOS verbs below are read-only: they read git history and the working tree; they never mutate the repo, push, or reach the network.
Before reporting any commit as done
- Run
dos commit-audit --workspace . HEAD.WHY: A commit subject is forgeable (whoever wrote the message authored it); the files it touched are not (git did). This grades whether the subject matches what the diff actually did.
- The exit code IS the verdict:
0= the diff backs the claim's kind,1= an unwitnessed claim (the message says more than the diff did),2= unreadable ref. - On exit
1(CLAIM_UNWITNESSED): do NOT report the work as done. Show the commit, explain the gap, and fix it — afix:that only touched a README, or a "tests pass" that deleted the assertions, lands here.
Before closing a ticket or claiming a phase shipped
- Run
dos verify --workspace . PLAN PHASE(substitute the plan/phase ids the work claims to complete).WHY: This answers did-it-ship from git history, not from the transcript.
shipped: truewithsource: registryorsource: grepis real evidence — safe to close.shipped: false/source: nonemeans there is no positive evidence. Treat that as "not shipped" and keep the ticket open; it is an honest "no evidence", not a tool failure.
Boundaries
- This checks did-the-claimed-thing-actually-ship — NOT whether the code is correct.
WHY: Correctness is the test suite's job. Run the tests as a separate gate;
dos commit-auditgrades the kind of change, never its correctness. - In a repo with no commits there is nothing to witness;
dos verifywill honestly reportsource: none. - Never accept a "done" because your own prose was confident. The verdict from evidence you did not author overrides your narration.
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.
- 11d ago First seen · 37 lines · 698 tokens per session scan A f7bc0c0682e7
dos-verify-done-claims-cursorrules-prompt-file is a cursor rule published in the GitHub repository anthony-chaudhary/dos-kernel (19 stars, last pushed yesterday), licensed MIT. It adds 698 tokens to every session, about $0.0035 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 cursor rules, from other repositories
aigon
Aigon workflow context — read this before every task.
no-co-author-trailers
Never add Co-authored-by or other AI/tool trailers to git commits or PRs.
git-authoring
Conventional Commit, pull-request, release-note, and PR-review conventions for this repository.
check
Analyze staged git changes with archguardian before committing.
ponytail
Ponytail, lazy senior dev mode. Always pick the simplest solution that works.
angular-20
This rule provides comprehensive best practices and coding standards for Angular development, focusing on modern TypeScript, standalone components, signals, and performance optimizations.