tdd-procedure
Skill0 starsChanged 24 days agoMITView on GitHub
Test-Driven procedure — write tests that fail first, then make them pass. Bound by the test-writer (writes failing tests) and referenced by the implementer (makes them pass). Gives the pipeline an objective done-signal.
In this repository9 other files it gives its agents.
- engageSkill
- gate-runnerSkill
- preflightSkill
- pr-formatSkill
- provision-repoSkill
- reportingSkill
- review-rubricSkill
- state-protocolSkill
- ticket-updatesSkill
The file
We split this skill into the rules it gives an agent
3 rules. About 0 are common, 0 are distinctive, and 3 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈0
Distinctive · estimate
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 12
Read requirements.md and test-plan.md from $STATE.
- Very specific: line 22
Do not write production code.
- Very specific: line 27
Write the smallest change in $REPO that makes the failing tests pass.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
TDD procedure
The failing-tests-first step is a forcing function: an objective, machine-checkable definition of "done" that no one can fake. Gates run against the target repo — $REPO is the path of that repo's entry in state.json.repos[], and <label> its name. You are briefed with one repo per invocation; there is no single top-level repo path. See gate-runner.
For the test-writer (stage 3)
- Read
requirements.mdandtest-plan.mdfrom$STATE. - For each behavior the plan marks unit or integration, write a test in
$REPOthat encodes the expected behavior of the not-yet-written change. - Confirm they fail for the right reason:
Three outcomes, and they are not interchangeable:${CLAUDE_PLUGIN_ROOT}/bin/gate-tests.sh <TICKET> --repo "$REPO" --label "<label>" --expect-failpass— ran and failed as expected. This is the red state you want; continue.fail— the suite passed when it should have failed, or no test file was added or changed, so nothing new is being exercised. Fix the tests.blocked— the gate couldn't run at all. Do not touch the tests and do not loop — stop and escalate (see gate-runner).
- Do not write production code. Behaviors marked manual get a checklist line in
test-plan.md, not an automated test. - Behaviors marked none get no new automated test and no checklist line beyond the planner's noted reason. If a repo's plan has zero new unit/integration rows, the red-first authoring step is a no-op for that repo — but the existing test suite is still run and must be green at the implement/fix/commit gates. "No new tests" is not "no tests run." The tests gate is recorded
passwhenever a suite exists and passes, andskippedonly when the gate script recognises no stack to run at all. When no new failing test was authored, the done-signal is green existing suite + green build + CLEAN review — never a skipped or red suite.
For the implementer (stage 4)
- Write the smallest change in
$REPOthat makes the failing tests pass. - Verify (normal mode):
${CLAUDE_PLUGIN_ROOT}/bin/gate-tests.sh <TICKET> --repo "$REPO" --label "<label>" ${CLAUDE_PLUGIN_ROOT}/bin/gate-build.sh <TICKET> --repo "$REPO" --label "<label>" - Both must be
passbefore handing off. If either fails, fix and re-run — never hand off a red gate.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

