tdd-workflow

Enforce RED/GREEN test states with 80%+ coverage and git checkpoints.

Updated May 4, 2026
One-click install
npx skills add https://github.com/panamini/pi-tooling --skill tdd-workflow-panamini
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: tdd-workflow
Source: https://github.com/panamini/pi-tooling/tree/main/skills/tdd-workflow
Command: npx skills add https://github.com/panamini/pi-tooling --skill tdd-workflow-panamini

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

It prevents bugs and regressions by forcing new changes to be validated through tests before production code is modified.

Core Features & Use Cases

  • TDD Red/Green gating: Ensures you confirm a failing test state before writing implementation, then verify the same test turns passing.
  • Coverage enforcement: Requires 80%+ coverage across unit, integration, and E2E tests, including edge/error scenarios.
  • Practical git checkpoints: Creates evidence-based commits after RED, GREEN, and (optionally) refactors to keep the development trail auditable.

Quick Start

Activate tdd-workflow when you are implementing a new feature or fixing a bug so you write a failing test first, make it pass, and then verify coverage.

Frequently Asked Questions about tdd-workflow

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

FAQPage Schema
How do I enforce test-driven development coverage for new features and bug fixes?

Test-driven development coverage is enforced by establishing a failing test state before implementation and confirming a green result afterward. This workflow requires 80%+ coverage across unit, integration, and E2E tests, including edge-case validation.

What is the RED/GREEN gating process in TDD and how does it prevent false positives?

RED/GREEN gating requires confirming a test fails before writing implementation code, then verifying the same test passes. It specifies acceptance criteria to avoid false positives from setup or compilation-only failures, ensuring functional validation.

How do I create evidence-based git checkpoints during a TDD workflow?

Evidence-based git checkpoints are created by committing code after the RED phase, the GREEN phase, and optionally after refactoring. This keeps the development trail auditable and validates that test-driven development changes follow coverage requirements.

Does this TDD workflow support Playwright E2E testing and integration tests?

Yes, the TDD workflow applies to feature work, bug fixes, and refactors that require unit, integration, and Playwright E2E coverage. It enforces minimum 80%+ coverage requirements across all these test types with clear edge-case validation.

When should I not use a strict 80% test coverage requirement for refactoring?

A strict 80% test coverage requirement applies to feature work, bug fixes, and refactors requiring unit, integration, and E2E tests. You should avoid it for trivial changes that do not modify production logic or lack clear edge-case validation scenarios.