<!-- GENERATED BY generate_skill_wrappers.py; DO NOT EDIT MANUALLY. -->

Generated Codex skill — do not edit manually

This complete skill and its bundled resources are generated from agent-plugins/skills/test-driven-development/SKILL.md. Manual changes in this directory will be overwritten the next time the generator runs. Edit the canonical skill instead.

Test-Driven Development

Use a focused red, green, refactor loop to guide a requested behavior change. Adapted from Addy Osmani's test-driven-development workflow; see the bundled license and repository third-party notice.

Route precisely

• Use when implementing a defined behavior or a diagnosed, reproducible bug where a useful automated test can run. If the cause is still unknown, use debugging-and-error-recovery to establish it first.
• Use prove-checks when the task is to establish whether an existing green check could detect a defect. Use code-review for a read-only diff review.
• For visual, operational, or otherwise hard-to-automate behavior, choose a proportionate executable check or observed manual verification and explain the limit; do not create a test that merely mirrors implementation.

Discover the local test contract

Read repository instructions, test locations, manifests, configuration, and CI commands. Identify the narrow runner for one case and the normal gate for the affected area. Preserve existing test style and working-tree changes. Do not assume a language, framework, or globally installed test command.

Choose a discriminating observation

Name the caller-visible boundary and the behavior one case will observe before writing the test. Use the existing contract and domain vocabulary; ask only when a missing decision changes the expected behavior. Do not require fresh approval for every test boundary already established by the task.

Prefer tests that survive an internal refactor. Mock external boundaries when useful without mocking away the behavior under test. Internal seams, interactions, call counts, and persistence observations can be legitimate when they express the contract being checked; they are not automatically defects or universally forbidden techniques.

Derive expected results independently from a specification, worked example, or known literal. A test that repeats the implementation's algorithm can repeat its bug. See references/test-observations.md for concrete controls. Work in vertical slices: one observed failure, one minimal implementation, then the next behavior; do not build a speculative batch of tests around an imagined design.

Selected observation and anti-tautology guidance adapts Matt Pocock's TDD skill, under the bundled LICENSE.mattpocock-skills. The local workflow retains refactoring and evidence requirements below.

Red, green, refactor

1. Define one behavior and an observable failure. Write or adapt the smallest test that would reject the missing behavior or original bug.
2. Run that exact test. Confirm the intended assertion fails on the old behavior; a setup error, compile failure unrelated to the behavior, skipped case, or zero selected cases is not red evidence.
3. Change only enough production code to satisfy the case. Re-run the focused test and inspect the result, including warnings and skips.
4. Refactor only if it improves clarity without changing behavior. Re-run the focused check after the refactor.
5. Add adjacent edge or failure cases when they distinguish a plausible regression. Run broader repository gates in proportion to the changed boundary and project policy; avoid automatic full-suite runs for a narrow change unless required.

Report

State the behavior, red assertion and observed result, production change, green result, any refactor, broader checks, and unverified paths. Never say a regression test was proven to catch the bug when its relevant negative control was not observed. Do not skip or weaken a failing check to obtain green.