test-driven-development

The test-driven-development skill is a core methodology component for software agents that mandates the Red-Green-Refactor cycle. It is designed for developers who prioritize software quality, maintainability, and architectural integrity. By enforcing that no production code is written without a corresponding failing test, this skill eliminates the risk of testing existing behavior or writing code that does not satisfy requirements. It acts as a guardrail against common pitfalls like rationalization, over-engineering, and ad-hoc manual verification.

• Enforces the Iron Law: No production code is permitted without a failing test first; any code written prematurely must be deleted.

• Guides the agent through the complete Red-Green-Refactor cycle: start by writing a minimal failing test, verify the test failure, implement the simplest code that passes the test, and finalize with refactoring.

• Promotes YAGNI (You Aren't Gonna Need It) by preventing the addition of features or 'improvements' beyond what the current test validates.

• Reduces technical debt by creating a comprehensive, automated test suite that doubles as living documentation.

• Integrates with standard CLI testing frameworks (e.g., npm test) to verify state transitions during development.

• Target Audience: Professional software engineers, devops practitioners, and technical agents working on production-grade systems.

• Use Cases: Implementing new features, applying bug fixes, performing refactoring, and managing behavior changes in complex codebases.

• Inputs: A specific feature requirement or bug report; technical context of the current project structure.

• Outputs: A suite of clear, minimal tests that document intent and guarantee correct behavior, followed by clean, production-ready code.

• Practical constraints: Does not apply to throwaway prototypes, generated code, or configuration files, where TDD may provide diminishing returns.

• Key advice: If you didn't watch the test fail, you don't know if it tests the right thing. Always ensure failures are for the right reasons, not due to typos or misconfigured environments.