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/dzhng/duet-agent/code-reviewnpx skills add dzhng/duet-agent --skill code-reviewgit clone --depth 1 https://github.com/dzhng/duet-agentWhat 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.00039 | $0.04532 |
| Opus 5 | $0.00019 | $0.02266 |
| Sonnet 5 | $0.00008 | $0.00906 |
| Haiku 4.5 | $0.00004 | $0.00453 |
Grade A, and why
code-review 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 3d 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.
This is a copy
88% identical to code-review — 10 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.
How it starts
The opening of the file, as written. The whole thing — 193 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Code Review
Review the diff or specified files against these principles.
1. Names must reflect current reality
- Variable and function names should describe what they ARE, not what they used to be.
- If the underlying mechanism changed (e.g. FUSE → NFS), all related names must update.
- Ask: would a new reader be confused by this name?
2. No stale references
- After refactoring, grep for references to the old approach — dead detection logic, abandoned feature flags, comments mentioning removed code.
- If something was tried and reverted, remove ALL traces. The codebase should look like the current approach was always the plan.
3. Simplify detection and guard logic
- A gate like "can this feature run" should check the ONE thing that actually matters.
- Don't chain fallback detections (binary exists OR source exists OR toolchain exists) when one check covers it.
4. Comments document WHY, not WHAT HAPPENED
- Keep: non-obvious technical discoveries, platform quirks, "if you remove this, X breaks because Y."
- Good:
// com.apple.provenance causes SIGKILL when spawned as child process - Good:
// umount while server is alive panics the macOS NFS client - Good:
// NFS client uses cookie verifier to decide if cached readdir is valid
- Good:
- Remove: narrative of what was tried, what was abandoned, what was renamed.
- Bad:
// We changed this from cp to cat to work around the provenance issue - Bad:
// Wrapper added because FUSE-T was zero-padding (see commit abc123) - Bad:
// Previously this was called fuseAvailable but we renamed it
- Bad:
- Remove: comments that just restate what the code does without adding reasoning.
- Often no comment is needed at all.
5. Separate install-time from runtime
- Install scripts set up prerequisites (toolchains, system deps).
- Runtime commands handle compilation, caching, binary management.
- Don't mix these. If the install script is compiling binaries that the runtime also compiles, one of them is wrong.
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.
- 3d ago First seen · 193 lines · 39 tokens per session scan A e5cd19430dba
code-review is a skill published in the GitHub repository dzhng/duet-agent (42 stars, last pushed 4d ago), licensed Apache-2.0. It adds 39 tokens to every session and 4,532 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. It is 88% identical to code-review, differing in 10 lines, and is treated as a copy.
Other skills, from other repositories
harness-creator
Build, audit, and improve harnesses that make AI coding agents reliable: AGENTS.md/CLAUDE.md instruction files, feature/state tracking, verification gates, scope boundaries, session handoff, memory persistence, context budgets, tool-permission safety, and multi-agent coordination. Use this whenever a coding agent is…
evaluator-write-qa
Internal Auto-Harness evaluator skill for sprint QA and QA report writing. Use only inside the Evaluator subagent during qa mode.
evaluator-review-contract-parallel
Internal Auto-Harness evaluator skill for parallel sprint contract review before implementation. Use only inside the Evaluator subagent during review mode.
evaluator-write-final-parallel
Internal Auto-Harness evaluator skill for parallel final QA report aggregation. Use only inside the Evaluator subagent during evaluatorfinalparallel.
evaluator-write-qa-parallel
Internal Auto-Harness evaluator skill for parallel sprint QA and QA report writing. Use only inside the Evaluator subagent during evaluatorqaparallel.
evaluator-write-retest-parallel
Internal Auto-Harness evaluator skill for parallel sprint retest and retest report writing. Use only inside the Evaluator subagent during evaluatorretestparallel.