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/oprogramadorreal/optimus-claude/unit-testnpx skills add oprogramadorreal/optimus-claude --skill unit-testgit clone --depth 1 https://github.com/oprogramadorreal/optimus-claudeWrote 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/oprogramadorreal/optimus-claude/unit-test)<a href="https://agentmods.dev/skills/oprogramadorreal/optimus-claude/unit-test"><img src="https://agentmods.dev/badge/skills/oprogramadorreal/optimus-claude/unit-test.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.00082 | $0.02123 |
| Opus 5 | $0.00041 | $0.01061 |
| Sonnet 5 | $0.00016 | $0.00425 |
| Haiku 4.5 | $0.00008 | $0.00212 |
Grade A, and why
unit-test 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 — 110 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Unit Test Coverage Improvement
Improve unit test coverage for existing code. An optional path argument scopes the run.
Step 1: Pre-flight
Inline harness mode detection
If your invocation prompt body contains HARNESS_MODE_INLINE, you are a single cycle (unit-test phase) inside the /optimus:deep coverage orchestrator. Read $CLAUDE_PLUGIN_ROOT/references/coverage-harness-mode.md and follow its "Unit-Test Phase Execution" section — that section governs which of the steps below run and how this run ends.
Prerequisites and project docs
If the current directory has no .git/ directory, read $CLAUDE_PLUGIN_ROOT/skills/init/references/multi-repo-detection.md and apply it. In a multi-repo workspace, run Steps 1–5 independently inside each repo that has .claude/CLAUDE.md and report results per repo; if no repo is initialized, suggest running /optimus:init first from the workspace root.
Check that .claude/CLAUDE.md exists. If it doesn't, stop and recommend running /optimus:init first — the project needs baseline context before test generation can be effective.
Load .claude/CLAUDE.md, .claude/docs/coding-guidelines.md, and testing.md where present; if testing.md is missing, derive testing conventions from existing test files. In a monorepo (read $CLAUDE_PLUGIN_ROOT/skills/init/references/project-detection.md if the structure is unclear), process each subproject independently and load that subproject's own docs/testing.md / docs/ files — never another subproject's; shared guidelines come from root .claude/docs/.
Step 2: Discovery & Coverage Analysis (agent-assisted)
$CLAUDE_PLUGIN_ROOT/skills/unit-test/agents/test-infrastructure-analyzer.md defines what this step has to produce. On a small or path-scoped project — roughly under 100 source files — run it yourself: surveying test files, framework, runner command and coverage tooling, then running the suite and coverage, is a handful of tool calls, and doing it inline keeps the file list you are about to write tests against in context.
What ships with it
2 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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 First seen · 110 lines · 82 tokens per session scan A 386ecd198fbd
unit-test is a skill published in the GitHub repository oprogramadorreal/optimus-claude (73 stars, last pushed 2d ago), licensed MIT. It adds 82 tokens to every session and 2,123 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
test-gen
Generate and verify tests — happy path, edge cases, error paths — using the project's own framework and patterns.
check-and-test
Run lint checks (ruff for Python, Biome for TS/JS), type checks (pyright for Python, tsc for TS/JS), and the standard pytest tiers (unit + e2e + tests skipped during pre-commit). Investigates failures to determine if they are application bugs or test issues, and fixes application bugs rather than weakening tests. Does…
brooks-test
Test quality review drawing on twelve classic engineering books — with primary focus on xUnit Test Patterns, The Art of Unit Testing, How Google Tests Software, and Working Effectively with Legacy Code — that diagnoses structural problems in an existing test suite: brittleness, mock abuse, coverage illusions, slow…
testing-r-packages
Best practices for writing R package tests using testthat version 3+. Use when writing, organizing, or improving tests for R packages. Covers test structure, expectations, fixtures, snapshots, mocking, and modern testthat 3 patterns including self-sufficient tests, proper cleanup with withr, and snapshot testing.
r-package-development
R package development with devtools, testthat, and roxygen2. Use when the user is working on an R package, running tests, writing documentation, or building package infrastructure.
cloudflare-workers-testing
Comprehensive testing guide for Cloudflare Workers using Vitest and @cloudflare/vitest-pool-workers. Use for test setup, binding mocks (D1/KV/R2/DO), integration tests, or encountering test failures, mock errors, coverage issues.