tdd-guidelines

Enforce a red-green test-driven workflow with failing tests before implementation.

Updated Feb 7, 2026
One-click install
npx skills add https://github.com/loagma/LoagmaPMS --skill tdd-guidelines
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: tdd-guidelines
Source: https://github.com/loagma/LoagmaPMS/tree/main/.claude/skills/tdd-guidelines
Command: npx skills add https://github.com/loagma/LoagmaPMS --skill tdd-guidelines

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

It enforces a strict, evidence-driven test-driven workflow that makes failing tests the starting point and treats passing results as downstream confirmation, preventing premature changes.

Core Features & Use Cases

  • Require writing failing tests before implementing the behavior.
  • Ensure the test suite captures regressions and guides incremental development.
  • Split unrelated changes and run targeted tests to maintain isolation.
  • Provide guidance for cross-boundary testing and plan-and-scratchpad workflows.

Quick Start

Plan your task with PLAN.md, write a failing test first, observe red, implement the minimal change, and verify green.

Frequently Asked Questions about tdd-guidelines

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

FAQPage Schema
How do I enforce test-driven development to prevent premature code changes?

You enforce test-driven development by starting with a failing test, observing the red state, implementing the minimal code change, and verifying the green state to ensure passing results act as downstream confirmation.

What is the red-green-refactor cycle and how does it guide incremental development?

The red-green-refactor cycle is a test-driven workflow where you write a failing test, make it pass with minimal code, then refactor. It guides incremental development by ensuring the test suite captures regressions at each stage.

How do I handle cross-boundary contract testing when data formats cross system boundaries?

Cross-boundary contract testing handles data formats crossing system boundaries by providing explicit testing guidance. You write isolated contract tests to verify data exchange stability during behavior changes.

How do I maintain test isolation when splitting unrelated changes in a test-driven workflow?

You maintain test isolation by splitting unrelated changes and running targeted tests. This test-driven workflow ensures each test validates a specific behavior, preventing cross-test dependencies and capturing regressions accurately.

Can I use a scratchpad and planning workflow for test-driven development tasks?

Yes, test-driven development supports plan-and-scratchpad workflows. You plan your task with a scratchpad, write a failing test first, implement the minimal change, and verify the passing result.

When should I not use a strict test-first workflow for behavior changes?

A strict test-first workflow is not suitable when automated testing is unavailable or tasks lack behavior changes. It requires verifiable evidence through automated tests, making it less applicable for purely structural changes without testable behavior.