Getting it into your agent
There is no command for this one: it runs only inside a plugin, and the catalogue could not identify which plugin ships it. The source is linked below.
Wrote 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/dominikwozniak/dw-solo-skills/dw-grain)<a href="https://agentmods.dev/skills/dominikwozniak/dw-solo-skills/dw-grain"><img src="https://agentmods.dev/badge/skills/dominikwozniak/dw-solo-skills/dw-grain/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/dominikwozniak/dw-solo-skills/dw-grain"><img src="https://agentmods.dev/badge/skills/dominikwozniak/dw-solo-skills/dw-grain.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.00069 | $0.02067 |
| Opus 5 | $0.00034 | $0.01033 |
| Sonnet 5 | $0.00014 | $0.00413 |
| Haiku 4.5 | $0.00007 | $0.00207 |
Grade A, and why
dw-grain 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 5d 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 — 137 lines — stays where its author put it; the contents beside it link to each section on GitHub.
dw-grain — working code is not the same as code worth keeping
Everything else that runs over a finished change asks whether the code is right. Lint, the formatter, the type checker, the tests, the review pass: all of them pass code that never needed to be written. An agent building against a checklist reaches for a new helper faster than for the one already in the tree, because writing is cheaper than searching — and the result compiles, passes and reads fine.
Every category below has exactly one remedy: delete it, or call what is already there. That is structural rather than a stated preference. A category allowed to propose an abstraction would spend the pass inventing the thing the pass exists to find, and anything asked for improvements returns improvements. None of them can, so the table cannot grow the codebase.
What it reads and writes
Reads wide, judges narrow. As input: the whole of every file the change touched, not the hunks;
their neighbours in the same directory; the canonical home the project keeps for helpers of that kind;
and whatever the repo declares about itself — a root AGENTS.md or CLAUDE.md, the topic files its
router points at, a CONTEXT.md glossary, a decision record covering this code. As judgeable:
only what the change wrote. Every row has to be fixable by changing the new code, which is what keeps
a wide read from becoming a tour of the repo's older sins.
Scope comes from git, never from a change doc. Bare takes the merge-base against the default branch —
the ref bash "${CLAUDE_PLUGIN_ROOT}/scripts/base-ref.sh" prints — and reads the files
git diff --name-only <base>...HEAD names. The argument narrows or replaces that: a path takes that
subtree, a ref range takes that range, a PR number takes that PR's files. It reads no .ai/
artifact at all — no lane, no CHANGE.md, no goal — so it runs in a repo that has never seen this
loop, over a directory, or over a branch that merged months ago.
Phase one writes nothing. Phase two writes the deletions you named, as code commits, and no .ai/
artifact — a table you act on in the same session needs no file to rot between runs.
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.
- 5d ago Changed · +2 lines e7c3497643bc
- 8d ago Changed 6b34757ef836
- 12d ago First seen · 135 lines · 69 tokens per session scan A ddcb6f40e32c
dw-grain is a skill published in the GitHub repository dominikwozniak/dw-solo-skills (2 stars, last pushed today), licensed MIT. It adds 69 tokens to every session and 2,067 once invoked, about $0.0003 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-31.
Other skills, from other repositories
self-audit
Self-audit this skills repo against CLAUDE.md invariants, the artifact contract, and README/CLAUDE.md/docs sync via three parallel read-only subagents. Local meta-skill — independent of the /task: pipeline.
gate-check
Final quality gate before reporting task completion (Gate 3). Fills confidence assessment, runs supplementary verification for <95% items, completes self-check checklist. Writes PASS/FAIL result to subtask.md, then calls autoworker:dispatch for routing.
verifying-task-output
Use after a dispatched task returns, to verify the output before marking it done.
naming
Evaluate and improve names in code using naming as a design diagnostic. Use when the user asks to "name this", "rename", "review naming", "what should I call", struggles to name something, or when a code review surfaces vague or misleading names.
review
Framework for code review that captures context future maintainers need: concerns raised, alternatives rejected, risks accepted. Use for PRs, local changes, or architecture review when the decision matters more than the diff. Produces structured feedback with must-address issues, suggestions, and observations "for the…
vibe-check
Judgment linter for vibe-coded output: reads the energy of the code, not just correctness. Use when the user says "vibe check", "does this hold up", "sanity check this AI code", or after a fast generation session before committing.