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-check)<a href="https://agentmods.dev/skills/dominikwozniak/dw-solo-skills/dw-check"><img src="https://agentmods.dev/badge/skills/dominikwozniak/dw-solo-skills/dw-check/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-check"><img src="https://agentmods.dev/badge/skills/dominikwozniak/dw-solo-skills/dw-check.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.00080 | $0.00906 |
| Opus 5 | $0.00040 | $0.00453 |
| Sonnet 5 | $0.00016 | $0.00181 |
| Haiku 4.5 | $0.00008 | $0.00091 |
Grade A, and why
dw-check 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 today.
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 — 70 lines — stays where its author put it; the contents beside it link to each section on GitHub.
dw-check — a fast look, then fixes
The review step, repeatable mid-build. Run it while the diff is small.
What it reads
The diff against the default branch — the ref bash "${CLAUDE_PLUGIN_ROOT}/scripts/base-ref.sh" prints — plus
the branch's CHANGE.md goal, so findings are judged against what the change is trying to do, not
against taste. The argument is read two ways: the single word codex adds the outside pass without
asking first, and anything else narrows the focus to a path or a topic. It writes no .ai/
artifact — approved fixes land as code commits.
Workflow
1. Establish the diff
git diff <base>...HEAD plus git log --oneline <base>..HEAD, narrowed by the focus when given.
2. Read the diff yourself — two axes, judged separately, never merged into one score
Every run, whatever else follows, and with this skill's own prose in the main thread — never
/code-review, /simplify or /security-review, never a subagent, never an effort level. The
filter below is what bounds it.
- Correct? — does the diff do what the goal says: edge cases, error paths, the empty input.
- Does it fit? — compared against the neighbouring code, not best practice in the abstract.
Every finding points at a real file:line you opened — if you can't ground it, don't report it.
"No findings on either axis" is a normal, useful answer; say it plainly and stop. Then filter, and
name what you dismissed, one line each:
- All nits means the diff is probably fine — lead with that conclusion, nits after it.
- "I would have done it differently" is not a finding until it names a concrete problem with this.
- More than five things to act on means the filter is too loose — except correctness and security, which earn more scrutiny before dismissal, not less.
3. Present, wait — and offer the outside pass in the same breath
List the findings with a severity-ordered recommendation and stop — nothing is fixed and nothing
is delegated without approval. Above the triviality floor — more than 2 files or 50-plus lines from
git diff --shortstat — that same stop carries one more line: codex:rescue can re-read this,
worth it? Below the floor, don't ask. codex in the argument skips the ask, and no plugin installed
drops it; neither costs a line of explanation, because the verdict is already in.
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.
- today Changed · +1 lines 3c8c886d973d
- 5d ago Changed · -1 lines · +13 tokens per session 8927667eaf80
- 8d ago Changed c19cdaeed06a
- 12d ago First seen · 70 lines · 67 tokens per session scan A bc280ad75f4c
dw-check is a skill published in the GitHub repository dominikwozniak/dw-solo-skills (2 stars, last pushed today), licensed MIT. It adds 80 tokens to every session and 906 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-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.