tdd-enforce

Enforces test-first discipline for production code changes.

4|Updated Sep 6, 2013
One-click install
npx skills add https://github.com/mway/dotfiles --skill tdd-enforce-mway
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: tdd-enforce
Source: https://github.com/mway/dotfiles/tree/main/home/dot_codex/skills/tdd-enforce
Command: npx skills add https://github.com/mway/dotfiles --skill tdd-enforce-mway

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This policy enforces strict test-first discipline when explicitly requested, ensuring no production code is added without a failing test and guiding teams toward safer, verifiable changes.

Core Features & Use Cases

  • Enforces the Red-Green-Refactor workflow and test-first rules.
  • Provides opt-in guidance to avoid unnecessary constraints while preserving safety for critical changes.
  • Includes anti-pattern guidance and a fallback to systematic debugging when expectations aren’t met.

Quick Start

Enable strict TDD for a change by writing a failing test first and then implementing the minimal code to pass it.

Frequently Asked Questions about tdd-enforce

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

FAQPage Schema
How do I enforce strict test-first discipline for changes in my codebase?

To enforce strict test-first discipline, you enable a policy that blocks production code from being added without a failing test, guiding your changes through a Red-Green-Refactor workflow. This ensures reliable test coverage and early failure signaling.

What is the Red-Green-Refactor workflow for software development?

The Red-Green-Refactor workflow is a test-first development process where you write a failing test first, implement minimal code to pass it, and then refactor. This Skill enforces that cycle to ensure safer, verifiable changes.

When should I apply strict TDD rules to my development process?

Apply strict TDD rules to changes where reliable test coverage and early failure signaling are critical, such as core logic updates or API surface changes. This ensures verifiable behavior and prevents untested production code.

How do I start strict TDD for API surface changes?

Start strict TDD for API surface changes by writing a failing test that defines the expected behavior, then implement the minimal production code to pass it. This enforces verifiable changes and early failure signaling.

What is the fallback approach when behavior is unclear during test-first development?

When behavior is unclear during test-first development, the fallback approach is systematic debugging. This ensures you understand expectations before proceeding, maintaining safety while avoiding anti-patterns in your workflow.

Can I opt out of unnecessary test-first constraints while preserving safety for critical changes?

Yes, this Skill provides opt-in guidance to avoid unnecessary constraints while preserving safety for critical changes. You can apply strict TDD rules selectively where reliable test coverage is most needed.