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 skills add Plazmodium/odin-workflow --skill unit-tests-eval-sddgit clone --depth 1 https://github.com/Plazmodium/odin-workflowWrote 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/plazmodium/odin-workflow/unit-tests-eval-sdd)<a href="https://agentmods.dev/skills/plazmodium/odin-workflow/unit-tests-eval-sdd"><img src="https://agentmods.dev/badge/skills/plazmodium/odin-workflow/unit-tests-eval-sdd.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.1 | $0.00034 | $0.00552 |
| Opus 5 | $0.00017 | $0.00276 |
| Sonnet 5 | $0.00007 | $0.00110 |
| Haiku 4.5 | $0.00003 | $0.00055 |
Grade A, and why
unit-tests-eval-sdd 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 6d 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 — 74 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Unit Test Evaluation Protocol
Use this skill during Reviewer when the feature includes new or changed tests.
Reviewer Goal
Do not only ask whether tests exist. Judge whether the tests are strong enough to trust the implementation.
Required Review Flow
- Verify test files exist for changed production code.
- Verify tests pass with the repo-native test command.
- Verify lint/type expectations relevant to tests still pass.
- Inspect the changed source and the corresponding tests.
- Evaluate test quality across these dimensions:
- coverage quality
- assertion specificity
- Arrange / Act / Assert structure
- mock hygiene
- naming quality
- async correctness
- fixture/data quality
- Decide whether the test suite is acceptable, acceptable with recommendations, or needs Builder rework.
Automatic Rework Triggers
Send the feature back to Builder when any of these are true:
- changed production code has no meaningful unit tests
- tests are failing
- coverage is below the project hard gate
- assertions are mostly vague or vacuous
- tests rely on implementation details instead of behavior
- mocks bleed between tests or mock the unit under test
- async behavior is unawaited, flaky, or only partially covered
Reviewer Output Expectations
- Cite concrete evidence: file paths, line numbers, and command output.
- Separate blocking issues from non-blocking recommendations.
- If test quality is insufficient, record
needs_reworkand send the workflow back to Builder. - If tests are acceptable, still capture recommendations for the next iteration.
Minimal Scoring Rubric
PASS: tests are trustworthy and compliantPASS_WITH_RECOMMENDATIONS: acceptable now, but improvements are still warrantedNEEDS_REWORK: Builder must fix tests before integrationESCALATE: test evidence reveals a deeper production bug or ambiguous requirement
Reviewer Checklist
- Test files present for changed code
- Tests pass
- Coverage meets hard gate
- Assertions are specific
- Mock cleanup is correct
- Async paths are handled correctly
- Result is either approved or routed back to Builder with precise feedback
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.
- 6d ago First seen · 74 lines · 34 tokens per session scan A 5dec4156d8d2
unit-tests-eval-sdd is a skill published in the GitHub repository Plazmodium/odin-workflow (0 stars, last pushed 3mo ago), licensed MIT. It adds 34 tokens to every session and 552 once invoked, about $0.0002 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-09-01.
Other skills, from other repositories
api-testing
Testing patterns for MCP tool/resource handlers using createMockContext and Vitest. Covers mock context options, handler testing, McpError assertions, format testing, Vitest config setup, and test isolation conventions.
api-testing
Testing patterns for MCP tool/resource handlers using createMockContext and Vitest. Covers mock context options, handler testing, McpError assertions, format testing, Vitest config setup, and test isolation conventions.
api-testing
Testing patterns for MCP tool/resource handlers using createMockContext and Vitest. Covers mock context options, handler testing, McpError assertions, format testing, Vitest config setup, and test isolation conventions.
api-testing
Testing patterns for MCP tool/resource handlers using createMockContext and Vitest. Covers mock context options, handler testing, McpError assertions, format testing, Vitest config setup, and test isolation conventions.
api-testing
Testing patterns for MCP tool/resource handlers using createMockContext and Vitest. Covers mock context options, handler testing, McpError assertions, format testing, Vitest config setup, and test isolation conventions.
add-test
Scaffold a test file for an existing tool, resource, or service. Use when the user asks to add tests, improve coverage, or when a definition exists without a matching test file.