Menu
Use when adding or modifying non-trivial code - requires happy-path AND sad-path tests covering every return permutation, blocks declaring "done" if production code grew without matching test additions.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
| name | tests-or-not-done |
| description | Use when adding or modifying non-trivial code - requires happy-path AND sad-path tests covering every return permutation, blocks declaring "done" if production code grew without matching test additions. |
User's global CLAUDE.md, verbatim: "Every function worth testing should have both success and error cases. Ensure tests cover every return... for ex if a Rust function returns an Option ensure that both the Some and None cases are covered. ... Use table driven tests when possible."
This rule is in his global config and does not propagate reliably to Codex sessions. ~14 prior corrections of the form "Did you write tests to comprehensively cover this? With both success and error cases?"
You added or significantly modified a function, method, or pure transformation. Excludes:
For each function changed, identify:
Option<T> -> Some and None.
Result<T, E> -> Ok and each E variant worth distinguishing.
(T, error) (Go) -> both permutations. bool -> true and false branches.Before declaring done, run the tests and report the count by file. If the test count did not grow alongside the production diff, surface this explicitly and explain why (e.g., "this is a pure refactor with full existing coverage").
assert mock.called).If the change is genuinely untestable in isolation (e.g., a hardware
driver, a UI render verified separately by verify-ui-changes), say so
and propose the alternative verification.
Use when reviewing a completed implementation holistically - a finished branch, a completed plan step, or a diff before PR. Reviews every changed line against the implementation plan (if one exists) and high engineering standards across seven dimensions, verifies tests by deliberately breaking crucial code, and emits severity-classified findings with a PASS/FAIL verdict.
Use when performing a holistic code review of an implementation - routes to codex:rescue or falls back to a direct subagent, both running the house-style:holistic-review skill
ALWAYS use before any implementation work, review, or planning: designing, writing, editing, refactoring, debugging, reviewing, or generating source code, tests, scripts, config-as-code, or behavior-affecting files. This is a baseline engineering skill and should be invoked even when a more specific language, framework, testing, or database skill also applies.
Use when asked to write, draft, file, or open a GitHub issue - mandates exploring the relevant code to understand the whole problem space, reasoning any proposed solution, and structuring the issue with summary, what/why, references, nuances, open questions, and acceptance criteria. Adds professionalism and no-sensitive-info discipline for public repos.
Use when creating, editing, triaging, or cleaning up GitHub issues - a mechanical pass that verifies the title is accurate and current, labels/assignees/milestone are correct, and the body is valid, well-formed markdown, all via the gh CLI. Does not judge content quality.
Use when running Python, installing Python packages, creating virtualenvs, or executing Python CLI tools - mandates uv/uvx over direct python/pip/pipx/venv calls when uv is installed, and gives the drop-in command mappings