Tdd

Skill aizech/bernhard-zechmann-skills/skills/engineering/tdd

Modular AI agent skills used across engineering, writing, and research workflows. Model‑agnostic, composable, and production‑tested. Includes engineering, productivity, personal, and experimental skill packs.

Install

npx -y skills add aizech/bernhard-zechmann-skills --skill tdd

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Test-driven development with red-green-refactor. Use when the user wants to build features or fix bugs test-first, or mentions unit, integration, or red-green-refactor tests.

The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

1.9 KB, as published. Nobody here has run it

Test-Driven Development

Build features and fix bugs one vertical slice at a time, using tests as the feedback loop.

Core principle

Tests verify behavior through public interfaces, not implementation details. If you refactor and the test breaks without behavior changing, the test was wrong.

Anti-pattern: horizontal slices

Do not write all tests first, then all implementation. Write one test, make it pass, then repeat.

Wrong:  RED test1, test2, test3 -> GREEN impl1, impl2, impl3
Right:  RED test1 -> GREEN impl1 -> RED test2 -> GREEN impl2 -> ...

Workflow

1. Plan

Confirm the interface changes with the user.
Confirm which behaviors to test. You cannot test everything.
List behaviors as observable outcomes, not implementation steps.
Get user approval before writing code.

2. Tracer bullet

Write one test for one behavior. Watch it fail. Write the minimal code to make it pass.

3. Incremental loop

For each remaining behavior:

Write the next test.
Make it pass with minimal code.
Do not anticipate future tests.

4. Refactor

After all tests pass:

Extract duplication.
Deepen modules: small interface, deep implementation.
Run tests after each refactor step.

Never refactor while RED.

Checklist per cycle

Test describes behavior, not implementation.
Test uses the public interface.
Test would survive an internal refactor.
Code is minimal for this test.
No speculative features added.

Rules

Write tests before implementation for new behavior.
Use type hints and clear names.
Keep functions small and single-purpose.
Fail fast with clear error messages.

Gives 3 of the 12 instructions most tdd skills give

Counted across 439 of the 443 authors here whose files we hold, read 2026-08-06

write minimal code to pass the testhere, and in 302 of 439, across 218 files
write a failing test firstin 176 of 439, across 112 files
refactor code only after tests passin 171 of 439, across 101 files
watch the test fail before writing codein 142 of 439, across 93 files
test one behavior per testhere, and in 106 of 439, across 44 files
refactor code while keeping tests greenin 99 of 439, across 86 files
delete code written before testsin 98 of 439, across 54 files
run tests after each refactor stephere, and in 85 of 439, across 54 files
Use real code instead of mocks unless unavoidablein 64 of 439, across 21 files
confirm the test fails for the right reasonin 64 of 439, across 60 files
reproduce bugs with a test before fixingin 53 of 439, across 36 files
write tests before implementationin 48 of 439, across 39 files

Said here and by no other author read

list behaviors as observable outcomes
use type hints and clear names

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once.