rlm-tdd

Automate deterministic RED-GREEN-REFACTOR TDD cycles for RLM Phase 3 implementations.

67|2|Updated Feb 7, 2026
One-click install
npx skills add https://github.com/doubleuuser/rlm-workflow --skill rlm-tdd
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: rlm-tdd
Source: https://github.com/doubleuuser/rlm-workflow/tree/main/skills/rlm-tdd
Command: npx skills add https://github.com/doubleuuser/rlm-workflow --skill rlm-tdd

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Test-Driven Development is mandatory for all RLM implementation work. This skill ensures test-first discipline is followed rigorously. The Iron Law: no production code without a failing test first.

Core Features & Use Cases

  • Enforces the RED-GREEN-REFACTOR cycle for Phase 3 implementations.
  • Records Phase 3 artifacts and maintains strict gate checks for traceability.
  • Supports deterministic, resumable workflow with explicit approvals.

Quick Start

Draft a failing test for the intended change, then implement the minimal production code to satisfy it.

Frequently Asked Questions about rlm-tdd

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

FAQPage Schema
How do I enforce strict test-driven development for feature additions and refactoring?

Enforce strict test-driven development by automating deterministic RED-GREEN-REFACTOR cycles that require a failing test before implementing minimal production code for feature additions, bug fixes, and refactors.

What is the TDD RED-GREEN-REFACTOR cycle and how does it apply to implementation workflows?

The RED-GREEN-REFACTOR cycle is a test-first development process where you draft a failing test, implement minimal code to satisfy it, and then refactor. This workflow applies it rigorously to ensure no production code exists without a failing test first.

How do I maintain traceability and gate checks during a test-driven development workflow?

Maintain traceability during test-driven development by recording phase artifacts and enforcing strict gate checks. The workflow generates documentation artifacts like STATE.md and DECISIONS.md to ensure deterministic, resumable progress with explicit approvals.

Can I use this TDD workflow for bug fixes and refactoring within an existing implementation phase?

Yes, you can apply this TDD workflow to bug fixes and refactors within implementation phases. It enforces the same test-first discipline and phase gate checks for all changes, ensuring rigorous traceability across all code modifications.

Why do my tests need to fail before writing production code in this workflow?

Tests must fail before writing production code because this workflow enforces an Iron Law of test-first discipline. Automating this rigorous check ensures that all production code is strictly validated by a failing test initially, satisfying phase gate requirements.

What are the limitations of automating test-first discipline for implementation workflows?

The workflow is limited to deterministic TDD cycles and requires explicit approvals to resume. It is specifically tailored for RLM Phase 3 implementation work, meaning it enforces strict phase gates and artifact generation rather than ad-hoc testing.