strict-tdd
Scannednpx machina-cli add skill a5c-ai/babysitter/strict-tdd --openclawstrict-tdd
You are strict-tdd -- the test-driven development enforcement skill for Pilot Shell.
Overview
This skill enforces strict RED->GREEN->REFACTOR discipline across all implementations. It provides the rules, patterns, and verification methods for TDD compliance.
The Three Laws of TDD (Pilot Shell Strict Mode)
- You may not write production code until you have a failing test
- You may not write more of a test than is sufficient to fail
- You may not write more production code than is sufficient to pass
TDD Cycle
RED Phase
- Write a test that captures exactly one acceptance criterion
- Run the test -- it MUST fail
- Verify it fails for the RIGHT reason (not a syntax error)
- Commit:
test: add failing test for [criterion]
GREEN Phase
- Write the MINIMUM code to make the test pass
- Run the test -- it MUST pass
- Verify only the target test turned green (no side effects)
- Commit:
feat: implement [criterion]
REFACTOR Phase
- Clean up code while keeping ALL tests green
- Remove duplication, improve naming, extract methods
- Run full test suite -- ALL tests MUST pass
- Commit:
refactor: clean up [area]
Compliance Scoring
| Score | Meaning |
|---|---|
| 90-100 | Exemplary TDD: all cycles followed correctly |
| 70-89 | Good TDD: minor deviations |
| 50-69 | Partial TDD: some implementation before tests |
| 0-49 | TDD violation: significant implementation without tests |
Verification Methods
- Git History Analysis: Test files must appear in commits before implementation files
- Coverage Analysis: New code must have >90% test coverage
- Commit Message Convention: RED/GREEN/REFACTOR phases identifiable in messages
Source
git clone https://github.com/a5c-ai/babysitter/blob/main/plugins/babysitter/skills/babysit/process/methodologies/pilot-shell/skills/strict-tdd/SKILL.mdView on GitHub Overview
strict-tdd enforces the RED->GREEN->REFACTOR discipline across Pilot Shell implementations. It codifies the three laws, the structured TDD cycle, and verification methods to ensure tests drive production code and keep commits atomic.
How This Skill Works
It defines three laws and a cycle with explicit commit messages for each phase, plus verification methods to confirm compliance. During the RED phase you write a failing test, in GREEN you implement the minimal code to pass, and in REFACTOR you clean up while keeping all tests green. Verification methods include Git history analysis, coverage checks (>90%), and adherence to the commit naming conventions.
When to Use It
- When adding a new feature in Pilot Shell and you want a failing test first
- When enforcing strict TDD in a team to prevent premature production code
- When auditing a PR for TDD compliance via commit messages and test coverage
- When performing a refactor and ensuring all tests remain green
- When training new contributors on disciplined TDD flows
Quick Start
- Step 1: Write a test that captures exactly one acceptance criterion and run it to confirm it fails
- Step 2: Implement the minimum production code to make the test pass and run tests
- Step 3: Refactor code, run the full test suite, and ensure all tests remain green
Best Practices
- Write only enough test to fail in the RED phase
- Commit per TDD cycle with precise prefixes: test:, feat:, refactor:
- Run the full test suite after refactor to ensure all tests pass
- Aim for >90% test coverage for new code
- Verify failures are due to the intended criterion, not syntax errors
Example Use Cases
- Adding a new CLI command in Pilot Shell with a failing test first
- Refactoring the command parser while keeping all tests green
- Introducing a new error handling path with a failing test, then implementing the fix
- Auditing a PR to ensure commits reflect RED/GREEN/REFACTOR phases
- Ensuring test coverage exceeds 90% on a module while progressing features
