tdd

Execute red-green-refactor cycles per vertical slice with public-interface tests.

1.0k|92|Updated May 22, 2026
One-click install
npx skills add https://github.com/open-gsd/gsd-pi --skill tdd-open-gsd
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: tdd
Source: https://github.com/open-gsd/gsd-pi/tree/main/src/resources/skills/tdd
Command: npx skills add https://github.com/open-gsd/gsd-pi --skill tdd-open-gsd

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Drives feature implementation by steering work through one red-green-refactor cycle per vertical slice, ensuring observable behavior is captured in tests before code is written.

Core Features & Use Cases

  • Vertical-slice driven testing: target single, end-to-end behaviors aligned with external contracts.
  • Public-interface-first: write tests that exercise the public API, not internal details, and expand only after green.
  • ** disciplined workflow**: never refactor while red; progress to green, then clean up with targeted refactoring.

Quick Start

Start by writing a single failing test that specifies an external contract, then implement only enough code to make it pass, and repeat for the next behavior.

Frequently Asked Questions about tdd

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

FAQPage Schema
How do I drive feature implementation using red-green-refactor cycles?

Red-green-refactor drives feature implementation by executing one cycle per vertical slice, capturing observable behavior in tests against public interfaces before writing the implementation code.

What is vertical-slice driven testing and how does it work?

Vertical-slice driven testing targets single, end-to-end behaviors aligned with external contracts. You write tests that exercise the public API, ensuring observable behavior is specified before internal implementation details are added.

Can I refactor code while tests are still failing?

Refactoring while red is strictly prohibited. You must progress to a green pass where all tests succeed, and only then clean up the code with targeted refactoring to ensure behavior remains pinned.

When do I need test-driven development for task plans and bug fixes?

Test-driven development is needed when observable contracts are defined and testable via public interfaces. It applies to task plans, bug fixes, and refactors to ensure behavior is pinned before changes are made.

How do I start writing tests for public interfaces first?

Start by writing a single failing test that specifies an external contract, then implement only enough code to make it pass, and repeat for the next behavior to expand the public interface after reaching green.

What are the limitations of applying test-driven development to refactoring?

Test-driven development for refactoring requires existing observable contracts testable via public interfaces. Without a green pass prior to refactoring, strict guardrails prevent ensuring behavior is pinned, limiting untested legacy code changes.