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/yuri-semenenko/ai-engineering-workspace/testing-checklistnpx skills add yuri-semenenko/ai-engineering-workspace --skill testing-checklistgit clone --depth 1 https://github.com/yuri-semenenko/ai-engineering-workspaceWrote 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/yuri-semenenko/ai-engineering-workspace/testing-checklist)<a href="https://agentmods.dev/skills/yuri-semenenko/ai-engineering-workspace/testing-checklist"><img src="https://agentmods.dev/badge/skills/yuri-semenenko/ai-engineering-workspace/testing-checklist.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.00133 | $0.01551 |
| Opus 5 | $0.00067 | $0.00776 |
| Sonnet 5 | $0.00027 | $0.00310 |
| Haiku 4.5 | $0.00013 | $0.00155 |
Grade A, and why
testing-checklist 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 — 82 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Testing Checklist
A pragmatic checklist for writing and reviewing tests. Read the relevant section for the change at hand rather than the whole file. Tests are the executable spec — optimize them for reading, not for coverage numbers.
Rationalizations (read first)
| Rationalization | Rebuttal |
|---|---|
| "I'll add tests later." | Later is the load-bearing word — it rarely arrives. The test is part of the change, not a follow-up. |
| "Tests pass, ship it." | Passing tests are evidence, not proof. They only cover what they assert — check what they don't cover. |
| "This code is too simple to break." | Simple code with branch logic breaks at the boundaries. Test the boundaries, skip the trivial middle. |
| "Coverage is at N%, we're good." | Coverage measures execution, not assertion. A test with no meaningful assert inflates N and catches nothing. |
| "The bug is fixed, no test needed." | A fix without a regression test is a bug on a return ticket. Red first, then green. |
| "I'll write the code first, then add tests." | Test-after validates the code you happened to write, not the behavior you wanted. Red first keeps the test honest. |
| "I'll DRY up these tests with helpers." | Test code is spec, not production code. DAMP wins: some duplication beats indirection the reader must unfold. |
What to test (in priority order)
- Branch logic — every non-trivial
if/switch/early-return path, especially error paths. - Boundaries — empty input, one item, max size, null/undefined, zero, negative, off-by-one edges.
- Contracts — what callers rely on: return shapes, thrown error types, emitted events, side effects.
- Error handling — the failure path is production code too; assert what happens when the dependency fails.
- Regressions — every fixed bug gets a test that fails without the fix (write it first, watch it fail).
What NOT to test
- Implementation details — private helpers, internal state, call order that a refactor may change. Test through the public surface.
- The framework — React rendering, ORM query building, library internals. Assume they work; test your logic.
- Trivial pass-throughs — getters, re-exports, config objects with no logic.
- Exact copies of the implementation — a test that mirrors the code's algorithm proves nothing; assert on known input → expected output instead.
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 · 82 lines · 133 tokens per session scan A 145dbcb57549
testing-checklist is a skill published in the GitHub repository yuri-semenenko/ai-engineering-workspace (1 stars, last pushed 5d ago), licensed MIT. It adds 133 tokens to every session and 1,551 once invoked, about $0.0007 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
hotfix
Fixes an observed defect with reproducible evidence in one call: writes a short trace doc before touching code, implements the fix, and backs it with a regression test written before the fix. Production incidents are the motivating case, not a gate. When blocked, it halts by name and saves the doc for a later call to…
phoenix-test
Drive development and bug-fixing with tests where the test IS the objective phoenixsense gate. Write a failing test before the code, reproduce a bug with a test before fixing it, and let phoenixsense decide pass/fail — never "looks right". Use when implementing logic, fixing a bug, changing behavior, or when the user…
unit-testing
Implement or extend production behavior test-first, or diagnose focused unit-test quality and flakiness, using red-green-refactor, ZOMBIES, Tidy First?, FIRST microtests, and Save Your Game checkpoints. Use for TDD, microtests, test-first bug fixes, flaky tests, and refactoring within an active green cycle. Do not use…
kotlin-testing
Kotlin testing patterns with Kotest, MockK, coroutine testing, property-based testing, and Kover coverage. Follows TDD methodology with idiomatic Kotlin practices.
rust-testing
Rust testing patterns including unit tests, integration tests, async testing, property-based testing, mocking, and coverage. Follows TDD methodology.
cpp-testing
Use only when writing/updating/fixing C++ tests, configuring GoogleTest/CTest, diagnosing failing or flaky tests, or adding coverage/sanitizers.