enforcing-tdd

Enforce pre-code scope definition and RED-GREEN-REFACTOR TDD discipline.

Updated Aug 23, 2026
One-click install
npx skills add https://github.com/ArcadeAI/dexa --skill enforcing-tdd-arcadeai
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: enforcing-tdd
Source: https://github.com/ArcadeAI/dexa/tree/main/.claude/skills/safeword-enforcing-tdd
Command: npx skills add https://github.com/ArcadeAI/dexa --skill enforcing-tdd-arcadeai

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Ensures scope is defined before coding and enforces RED → GREEN → REFACTOR test discipline. Triggered by words like implement, add, build, create, fix, change, feature, bug.

Core Features & Use Cases

  • Scope Definition: Requires a task spec or feature spec before coding.
  • TDD Phases: RED (failing tests) → GREEN (passing tests) → REFACTOR (cleanup).
  • Gatekeeping: Prevents unscoped code and ensures test failures guide implementation.

Quick Start

When starting work, define scope via a spec, write a failing test, then implement to make tests pass, followed by refactor if needed.

Frequently Asked Questions about enforcing-tdd

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

FAQPage Schema
How do I implement test-driven development to prevent unscoped code?

Test-driven development enforces scope definition before coding by requiring a task spec and failing tests before implementation. The RED-GREEN-REFACTOR workflow—write failing tests, implement to pass them, then refactor—ensures scope artifacts and test failures guide development, preventing unscoped work across features, bug fixes, and refactors.

What's the difference between RED, GREEN, and REFACTOR phases in TDD?

RED writes failing tests that define expected behavior; GREEN implements code to make tests pass; REFACTOR cleans up without changing functionality. This cycle, preceded by TRIAGE phase planning, ensures tests drive implementation decisions and scope remains bounded throughout the feature lifecycle.

When should I use test-first development instead of writing tests after code?

Test-first development prevents scope creep and unguided implementation. Use it when starting features, bug fixes, enhancements, or refactors to enforce pre-code planning, catch design issues early through test requirements, and ensure implementation stays within defined boundaries rather than expanding scope mid-development.

What artifacts does TDD discipline require before I start coding?

TDD requires task specs or feature specs that define scope, test definitions that specify expected behavior, and planning documents that identify development level (L0/L1/L2). These artifacts must precede implementation to prevent unscoped work and establish the failing tests that guide the RED phase.

Can I apply test-driven development to bug fixes and refactors, or just new features?

Test-driven development applies equally to new features, bug fixes, enhancements, and refactors. Each triggers the same scope-definition and RED-GREEN-REFACTOR discipline: define scope via spec, write failing tests that reproduce the issue or specify the change, implement to pass tests, then refactor as needed.