Getting it into your agent
It runs from inside its repository, so the clone comes first — what it calls does not travel with the file alone.
git clone --depth 1 https://github.com/anthony-chaudhary/dos-kernelnpx agentmods add skills/anthony-chaudhary/dos-kernel/dos-self-improveWrote 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/anthony-chaudhary/dos-kernel/dos-self-improve)<a href="https://agentmods.dev/skills/anthony-chaudhary/dos-kernel/dos-self-improve"><img src="https://agentmods.dev/badge/skills/anthony-chaudhary/dos-kernel/dos-self-improve/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/anthony-chaudhary/dos-kernel/dos-self-improve"><img src="https://agentmods.dev/badge/skills/anthony-chaudhary/dos-kernel/dos-self-improve.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector warn
SkillSpector: 1 finding, up to high
These are SkillSpector’s own severities. On a checked sample its high-severity flags on skills were ~96% false positives — a documented command, a public API, a “never do X” rule — so we show them as a caution to read, not a verdict. Why →
- high Rogue Agent · line 86 Skill modifies its own code, configuration, or behavior at runtime. Self-modification enables an agent to escalate privileges, disable safety constraints, or install persistent backdoors.Fix: Prevent the skill from modifying its own code, SKILL.md, or configuration files. Treat skill files as read-only at runtime.
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.00056 | $0.03074 |
| Opus 5.5 | $0.00022 | $0.01230 |
| Sonnet 5.5 | $0.00011 | $0.00615 |
| Haiku 4.5 | $0.00006 | $0.00307 |
Grade A, and why
dos-self-improve 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 — 242 lines — stays where its author put it; the contents beside it link to each section on GitHub.
dos-self-improve — the loop where DOS adjudicates its own improvement
The first self-improving work loop for DOS. It proposes a change, checks it, measures it, and keeps it only if a witness the change's author did not write confirms it improved — the green suite on a clean worktree, the truth syscall, and a strictly-measured metric gain. Everything else is reverted. The keep decision is the kernel's
improveverdict, not the loop's opinion of its own work. A run of candidates nothing accepts trips a breaker that hands the judgment back to a human.
This is the dispatch loop (/dos-dispatch-loop) turned inward on a codebase's
own source, with the one rule no prior auto-improver enforced:
A self-improving loop's fatal failure mode is grading its own homework — the agent that wrote the change is the same one that says "yes, this is better," so it learns to narrate improvement instead of making it.
dos improvecloses that hole: the keep-bit is a pure function of facts the loop did not author, so the loop cannot keep a change by claiming it is better. The only path to KEEP is to actually move a metric the environment measures.
The recursive-self-improvement literature names verification as the gating constraint ("requiring verification regimes enabling labs to confirm"; "human judgment on which problems matter remains the bottleneck"). This loop is that verification regime, with the human kept in the loop by construction — the breaker escalates to a person exactly when the loop runs dry of witnessed improvements.
What the kernel decides vs. what you do
| Step | Who | What |
|---|---|---|
| Propose one scoped change | YOU (a subagent) | the capable, untrusted step — the only place intelligence enters the loop |
| Verify + measure | dos verbs |
run the suite, run the truth syscall, measure the metric — all on an isolated worktree |
| Keep / revert / escalate | dos improve |
the kernel's typed verdict over the env-authored facts — NOT your opinion |
| Merge / discard / escalate | YOU | carry out the kernel's verdict |
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 · 242 lines · 56 tokens per session scan A 4c2abf1a4989
dos-self-improve is a skill published in the GitHub repository anthony-chaudhary/dos-kernel (20 stars, last pushed 26d ago), licensed MIT. It adds 56 tokens to every session and 3,074 once invoked, about $0.0002 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-30.
Other skills, from other repositories
developing-openrig
Use when changing OpenRig's own source in a clone of the openrig repository: finding which package or file owns a behaviour, choosing which tests to run, testing a change without disturbing the OpenRig daemon your own session runs on, judging whether a diff touches a high-risk area, or preparing a pull request. Not…
ci-triage
Diagnose failing CI, build, release-gate, or test runs for Cool Workflow. Use when a GitHub Actions check, local npm test, npm run build, release gate, smoke test, or generated-manifest check fails and Codex must identify the first actionable failure with logs and verifier commands.
pr-review
Review Cool Workflow pull requests or branch diffs. Use when Codex must inspect code changes for bugs, regressions, FreeBSD/POLA violations, missing tests, generated artifact drift, release-contract risk, or CI implications, and return findings first with file/line citations.
fix
Diagnose and fix a bug in an isolated git worktree with reproduce-first, test-first methodology.
bug-fix
Systematic workflow for verifying bug fixes to ensure quality and prevent regres...
codew-release-qa-sweep
Use before claiming Codewhale release work is done: run the full gate sweep and list the manual QA targets.