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 agentmods add skills/anthony-chaudhary/dos-kernel/issue-worknpx skills add anthony-chaudhary/dos-kernel --skill issue-workgit 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/skills/anthony-chaudhary/dos-kernel/issue-work)<a href="https://agentmods.dev/skills/anthony-chaudhary/dos-kernel/issue-work"><img src="https://agentmods.dev/badge/skills/anthony-chaudhary/dos-kernel/issue-work.svg" alt="Measured on agentmods" 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 | $0.00075 | $0.02223 |
| Opus 5 | $0.00037 | $0.01111 |
| Sonnet 5 | $0.00015 | $0.00445 |
| Haiku 4.5 | $0.00007 | $0.00222 |
Grade A, and why
issue-work 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 4d 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 — 182 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Issue-work — complete the next most important issue, witnessed
The pick is an admission decision; the completion is a claim; only a witness closes it. Importance alone does not pick an issue — importance × feasibility does (an issue whose fix surface the SELF_MODIFY guard protects is not yours to take, however urgent). And "done" is never your narration: it is the issue's done-condition made TRUE, pinned by a test, landed in a commit whose subject
dos commit-auditwitnesses, withFixes #Nleft for git ancestry — not you — to close. Worked example: #12 → commit8e7f2f5(the reference run of every step below).
Layering. Dev tooling that operates ON the repo (the /release tier) —
it names a vendor (gh/GitHub), so it lives in .claude/skills/, never
src/dos/skills/. The closing half is issue-verify;
this skill is the completing half.
Public-repo note. Issue comments and labels are public documents — no
dev-machine paths, hostnames, or private-process prose. Leak-scan every
drafted body (python scripts/leak_scan.py --text-file <draft>) before
posting; if the scanner is absent, the hand rule is the floor.
Step 1: Triage from the deterministic floor (skip if given an issue number)
python scripts/backlog_triage.py --top 12 # the typed, ordered queue (docs/315)
The script types every open issue into a closed disposition set and orders
the offerable rows deterministically: priority tier → ready-label bias →
freshness (the kernel's cooldown + pick-priority folds over the lane-journal
OP_ATTEMPT history, unit id issue-N) → FIFO. The top row is the default
pick. The floor is deterministic-first, advisory-only (the JUDGE-rung
split): you may deviate, but state the one-line reason — the operator reads
it to audit the triage, not to re-do it.
What each disposition hands you:
READY (code)— implement it; the steps below.READY (execute-plan)— a design issue whosedocs/NNplan exists: ship the plan's next unshipped phase (dos verifyit first — never trust the plan's own status prose).NEEDS_PLAN (write-plan)— the unit of work IS thedocs/NNplan: write it, link it from the issue, and stop there (implementation is a later pick).COOLING/T1_GATED/OPERATOR_GATED— not yours; surface it, don't pick it.
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.
- 4d ago First seen · 182 lines · 75 tokens per session scan A 87f653498a2b
issue-work is a skill published in the GitHub repository anthony-chaudhary/dos-kernel (19 stars, last pushed 10d ago), licensed MIT. It adds 75 tokens to every session and 2,223 once invoked, about $0.0004 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
orch
AI agent orchestrator — manage teams of AI agents that work on your codebase in parallel. Use when the user wants to: run multiple agents, coordinate AI work, deploy agent teams, manage tasks/goals/agents, check orchestrator status, or mentions 'orch', 'orchestry', 'agents team', 'agent orchestration'.
release-feature-audit
Use when a new PuPu feature finishes implementation and needs its consistency audit before its ticket is marked done — "audit #123", "审计这个功能", "这个 feature 过一遍检查" — or when release-close-sprint roll-call finds a new feature that was never audited. Also covers standalone i18n checks ("漏翻了吗", "检查 i18n"), which used to be…
release-close-sprint
Use when the project owner wraps or closes a PuPu version/release — "关 0.1.10", "close the release", "版本收尾". Verifies a Size=Release parent issue and its direct sub-issues in GitHub Project, records close evidence there, and hands it to release certification.
release-draft-ticket
Use when the project owner dictates new PuPu work that should become a GitHub Project release sub-issue — during release-open-sprint or mid-release "开个票", "draft a ticket for X", "把这个记到 board 上". Opens a draft direction; the implementing agent may later refine the same issue.
release-open-sprint
Use when the project owner opens a new PuPu version/release — "开 0.1.11", "open the next release", "开新版本". Creates and scopes one Size=Release parent issue in PUPU Project; all version work is its direct sub-issues. Not for adding one item mid-release (release-draft-ticket) or closing a release (release-close-sprint).
wayfinder
Plan a huge chunk of work — more than one agent session can hold — as a shared map of decision tickets on your issue tracker, and resolve them one at a time until the way to the destination is clear.