Menu
Use after writing or modifying code to enforce the mandatory write → test → fix → repeat validation cycle.
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 | test-and-fix-loop |
| description | Use after writing or modifying code to enforce the mandatory write → test → fix → repeat validation cycle. |
| depends_on | ["demand-triage","repo-exploration"] |
| commonly_followed_by | ["error-recovery","observability"] |
| rules | ["rules/global/test-coverage-spec.md"] |
Use this skill to enforce iterative validation after every code change.
┌─────────────┐
│ Write code │
└──────┬──────┘
▼
┌─────────────┐
│ Run tests │ ← project test command (e.g., go test ./..., npm test, pytest)
└──────┬──────┘
▼
┌─────────────┐
│ Run lint │ ← project lint command (e.g., go vet, eslint, mypy)
└──────┬──────┘
▼
Pass? ──No──► Fix errors (minimal change) ──► Re-run from top
│
Yes
▼
┌─────────────┐
│ Done │
└─────────────┘
Adapt testing intensity based on the task scale from the demand-triage skill:
Before writing any test, classify each planned test case into exactly one category.
This step runs before the test-first guidance below. See rules/global/test-coverage-spec.md
for full definitions and conflict-resolution rules.
| Category | Primary assertion | Typical signal |
|---|---|---|
| MFT (Functional) | Correct output for valid input | Return value, side effect, state change |
| INV (Stability) | A property holds regardless of input or repetition | No crash, no state corruption, idempotent result |
| DIR (Decision Logic) | Correct decision at a branch point | Auth rejection, rate-limit, validation refusal, routing |
For each test case to write:
1. State the primary assertion in one sentence
2. Match to MFT / INV / DIR using the table above
- If unsure between INV and DIR: "Is the system enforcing a policy, or merely surviving?"
Policy enforcement → DIR. Survival → INV.
3. Label the test with its category before writing it
4. After all tests are written, list coverage per category
- Small tasks: one category is sufficient
- Medium tasks: at least two categories (MFT always; add INV or DIR as applicable)
- Large tasks: all three categories (waive one only with written justification)
5. For any absent category, state the reason in the structured preamble or as a
header comment block in the test file — not in the test name or silently omitted
Valid waiver: "INV absent — login is intentionally non-idempotent; repeated calls
create new sessions by design."
Invalid waiver: "INV: N/A" or leaving the category unlisted entirely
| Scenario | Category | Reason |
|---|---|---|
POST /users returns 201 with id on valid payload | MFT | Correct output for valid input |
POST /users with name: null does not panic | INV | Survival, not policy |
| Same payload sent twice does not create a duplicate | INV | Idempotency invariant |
Missing Authorization header returns 401 | DIR | Policy enforcement |
Expired token returns 403 | DIR | Auth boundary decision |
Payload over size limit returns 413 | DIR | Validation boundary decision |
When adding new behavior (not fixing a bug in existing code), consider writing test expectations before implementation:
For multi-step tasks, use an explicit verification plan before starting. This format transforms imperative instructions into verifiable goals:
1. [Step description] → verify: [concrete check]
2. [Step description] → verify: [concrete check]
3. [Step description] → verify: [concrete check]
Examples of strong vs. weak verification:
| Weak (vague) | Strong (verifiable) |
|---|---|
| "Add validation" | "Write tests for invalid inputs, then make them pass" |
| "Fix the bug" | "Write a test that reproduces it, then make it pass" |
| "Refactor X" | "Ensure tests pass before and after, diff shows no behavior change" |
| "Make it work" | "Endpoint returns 200 with expected JSON; integration test passes" |
Strong success criteria let the agent loop independently. Weak criteria require constant clarification.
This is a recommendation, not a mandate. Use test-first when:
Do not force test-first when:
Check in order:
Makefile or Taskfile.yml → look for test, lint, check targetspackage.json → scripts.test, scripts.lintpyproject.toml / setup.cfg → pytest configurationgo.mod → go test ./...Cargo.toml → cargo testpom.xml / build.gradle → mvn test / gradle testREADME.md, CONTRIBUTING.md, or the adoption guide) → validation or verification commandsIf no test command is identifiable, state that explicitly.
All conditions below must be verifiable from task artifacts:
not-run as pass — if no test command is found, the skip must be explicitly noted in the trace. It does not count as a passing validation.Use for general product implementation work that is not primarily backend architecture, pure integration wiring, or screenshot-driven design-to-code.
Use when the main deliverable is maintainable documentation such as repository rules, onboarding guides, runbooks, ADRs, or architecture notes.
Use on first entry to a new repository to run environment scanning and ask targeted boundary questions before implementation.
Use before committing to a design or plan to force assumption-surfacing. The agent challenges your design, questions edge cases, and flags gaps — you patch vague decisions. Prevents the failure mode where a design "feels explained" but contains hidden flaws that only appear during implementation.
Use to establish and maintain a shared domain glossary (UBIQUITOUS_LANGUAGE.md). Creates a single source of term definitions that all agents, prompts, and documents must use — preventing semantic drift and repeated re-explanation across sessions.
Use when encountering compile errors, test failures, runtime exceptions, or unexpected behavior during implementation.