Help us improve
Share bugs, ideas, or general feedback.
From stdd
Run the TDD red-green-refactor loop for a feature. One test at a time: write a test, make it pass, clean up, repeat. Invoke with /stdd:tdd <feature-name>.
npx claudepluginhub dominik-rehse/stdd --plugin stddHow this skill is triggered — by the user, by Claude, or both
Slash command
/stdd:tdd [feature-name][feature-name]The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Feature: $ARGUMENTS
Guides technical evaluation of code review feedback: read fully, restate for understanding, verify against codebase, respond with reasoning or pushback before implementing.
Share bugs, ideas, or general feedback.
Feature: $ARGUMENTS
Read docs/specs/$ARGUMENTS.md. If it does not exist, stop:
No spec found. Run
/stdd:spec $ARGUMENTSfirst.
Determine test file location (pick one, be consistent within the project):
src/$ARGUMENTS.test.<ext> (idiomatic for Bun, Vitest, Jest)tests/test_$ARGUMENTS.<ext> (idiomatic for pytest)Remember this path — it is <test-file> in the RED and GREEN commands below.
Write the feature name to .tdd-in-progress in the project root:
printf '%s\n' "$ARGUMENTS" > .tdd-in-progress
This tells the guard hook to allow matching writes to src/ during this session.
Before writing any test, do a short planning pass on the spec.
AC-N ID in spec
order with the test category it belongs to (happy path, edge, error,
security). The list defines what "done" means; do not silently drop items.State the plan and the coverage map, then confirm with the user before the first RED, unless you are running unattended.
Even though the spec lists several acceptance criteria, do not draft all the tests up front and then implement them. Tests written in bulk verify imagined behavior — they test the shape of things rather than what the code actually does, and they pass when behavior breaks because they were calibrated to a guess.
One acceptance criterion → one test → one minimal implementation → repeat. Each cycle responds to what the previous one taught you about the code.
Work through the spec's acceptance criteria one at a time. Do not write the next test until the current one is GREEN and clean.
Write a single test for the next acceptance criterion. Include the criterion's
AC-N ID in the test's name or docstring so the coverage audit can find it
mechanically:
def test_AC_1_parses_empty_input(): ... (Python
identifiers forbid hyphens, so use the underscore form).def test_parses_empty_input(): """AC-1: parses empty input."""test('AC-1: parses empty input', () => { ... })AAA structure:
Run: ./scripts/run-tests.sh <test-file>
The test must fail. If it passes, it is not testing anything real — fix it before continuing. Fail for the right reason (missing implementation, not a broken test).
Write the minimum code to make that single test pass. Do not anticipate future tests. No extra features, no speculative abstractions.
Run: ./scripts/run-tests.sh <test-file>
The test must pass.
Look at what you just wrote. Ask:
If yes, fix it. If no, move on. Refactor is about the code you just touched, nothing else. Never refactor while RED — get to GREEN first.
Run: ./scripts/run-tests.sh
Full suite — no arguments. This is where regressions are caught. All tests must still pass. If any fail, revert the refactor — it was wrong.
When the full suite is green, tick this criterion in docs/specs/$ARGUMENTS.md:
change its - [ ] to - [x]. The spec is the live progress record — a reviewer,
a later session, or /stdd:review reads it to see what is done.
Before starting the next cycle, confirm:
AC-N tag in its name or docstring.[x] in the spec (MARK step done).Move to the next acceptance criterion. Back to RED.
When every acceptance criterion has a passing test:
Remove the .tdd-in-progress marker file.
Run ./scripts/run-tests.sh one final time. Show the full output.
Sweep docs/ for stale references. Outside the just-edited spec and the
test files, grep for:
$ARGUMENTS) and the new module's file path.For every hit, decide update or leave and say why. Code-fenced examples
(JSON, snippets) are usually update — they are contracts a reader can
copy. This catches the failure mode the test loop cannot: the suite stays
green while prose elsewhere in docs/ rots.
Print the coverage audit — table plus Gaps section plus Coverage: N/M
line. Format is defined in "Coverage audit format" in the stdd rules.
If Gaps lists unchecked criteria, the implementation is not complete. Go back to RED for them before declaring done.