process-test-driven-development

Enforces red-green-refactor TDD discipline and audits scenario-based REDs for inherited coverage and telegraphing.

1|Updated Jun 23, 2026
One-click install
npx skills add https://github.com/bitranox/bitranox-skills --skill process-test-driven-development-bitranox
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: process-test-driven-development
Source: https://github.com/bitranox/bitranox-skills/tree/main/plugins/bitranox/skills/process-test-driven-development
Command: npx skills add https://github.com/bitranox/bitranox-skills --skill process-test-driven-development-bitranox

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) components.

What problem does it solve? Code written before tests produces tests that pass immediately and prove nothing, and prompt-based baseline scenarios can silently fail for the wrong reason when the agent already knows the lesson or the prompt gives away the answer. This Skill enforces a strict test-first workflow and ships a checker that detects both leaks before a baseline run is dispatched. ## Core Features & Use Cases - Red-Green-Refactor Discipline: Mandates writing one failing test, verifying it fails for the right reason, then writing minimal code to pass, with checklists and rationalization rebuttals. - Scenario RED Auditing: The bundled redcheck.py script checks a scenario prompt against the agent's inherited context (CLAUDE.md cascade, memory facts) for prior coverage and against telegraphing markers, with exit codes 0-3 for gating. - Testing Anti-Pattern Reference: A companion reference covers testing mock behavior, test-only production methods, incomplete mocks, and mocking without understanding dependencies. - Use Case: Before dispatching a subagent with a prompt meant to prove it takes the wrong action, run redcheck.py with --corpus-cascade on the dispatch directory to confirm the lesson is not already in its always-loaded context. ## Quick Start Ask the agent to implement a bug fix using test-driven development, writing and running a failing test before any production code.

Frequently Asked Questions about process-test-driven-development

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I practice test-driven development on a bug fix?▼

Write one failing test that reproduces the bug, run it and confirm it fails for the expected reason, then write the minimal code to make it pass. Keep all other tests green, refactor only after green, and never fix a bug without a failing test first.

Why must I watch the test fail before writing code?▼

A test that passes immediately proves nothing: it may test existing behavior, the wrong thing, or contain a typo. Watching it fail for the expected reason proves the test actually exercises the missing behavior.

How do I check if a baseline scenario prompt can actually fail?▼

Run redcheck.py with --scenario pointing at the prompt and --corpus-cascade pointing at the dispatch directory. It assembles the agent's inherited CLAUDE.md and memory context, reports inherited coverage or telegraphing, and exits 1 on a leak or 3 if the corpus was empty.

What does redcheck exit code 3 mean?▼

Exit 3 means unchecked: a corpus flag was given but zero documents were assembled, so the inherited-coverage check never ran. An empty corpus makes every scenario look clean, so the tool refuses to report a quiet pass.

When is it acceptable to skip TDD?▼

Only for throwaway prototypes, generated code, or configuration files, and only with the human partner's explicit approval. Exploratory code is allowed but must be deleted and rewritten test-first.

Why should I avoid asserting on mocked components in tests?▼

Asserting on a mock verifies the mock exists, not that the real component behaves correctly. Test real behavior with real dependencies where possible, mock only at the level of slow or external operations, and mirror complete API response structures.