tdd-workflow

Enforces test-driven development with RED-GREEN-refactor cycles and 80% coverage gates.

1|Updated Aug 31, 2026
One-click install
npx skills add https://github.com/gagandeepgill/puzzle-game --skill tdd-workflow-gagandeepgill
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: tdd-workflow
Source: https://github.com/gagandeepgill/puzzle-game/tree/main/.claude/skills/tdd-workflow
Command: npx skills add https://github.com/gagandeepgill/puzzle-game --skill tdd-workflow-gagandeepgill

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Code changes made without tests lack proof of correctness, and ad-hoc testing often skips the failing-test-first discipline that makes TDD meaningful. This Skill enforces a structured RED-GREEN-refactor workflow with verifiable evidence at every stage, so features, bug fixes, and refactors ship with real test coverage instead of assumed correctness. ## Core Features & Use Cases - Mandatory RED-GREEN Gates: Requires a failing test to be compiled, executed, and verified before any production code is written, then re-runs the same target to confirm GREEN. - Test Runner Detection: Resolves the correct package manager and test runner (npm, pnpm, yarn, Bun native bun:test, Jest, Vitest) instead of assuming npm test. - Plan File Handoff: Accepts a *.plan.md implementation plan as untrusted input, sanitizes embedded commands, and converts planned behaviors into testable guarantees. - Git Checkpoint Commits: Creates per-stage commits (test, fix, refactor) on the active branch so RED/GREEN evidence survives review and squash merges. - Evidence Report: Produces a human-readable TDD report mapping each plan task to its test target, validation command, and RED/GREEN results. - Use Case: When fixing a bug in a search API, the Skill first writes a failing reproducer test, commits it as RED evidence, implements the minimal fix, confirms the test passes, then refactors and records 80%+ coverage. ## Quick Start Use the tdd-workflow skill to implement this feature from my plan file, writing failing tests first and committing evidence at each stage.

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 in an AI coding workflow?▼

Use a TDD workflow that mandates a RED gate: the failing test must compile, execute, and fail for the intended reason before any production code is written. After the fix, the same test target is re-run to confirm GREEN, with Git checkpoint commits preserving evidence at each stage.

How to write tests before code with Jest, Vitest, or Bun?▼

First detect the actual runner from package.json scripts and test imports, since bun test (native runner) differs from bun run test (package script). Then write the failing test, run it to confirm RED, implement minimal code, and re-run to confirm GREEN.

What test coverage percentage should a project require?▼

This workflow requires a minimum of 80% coverage across branches, functions, lines, and statements, combining unit, integration, and E2E tests. Coverage thresholds can be configured in Jest config or bunfig.toml depending on the runner.

Can I use a plan markdown file as input for TDD implementation?▼

Yes, a *.plan.md file can be passed as the starting point, but it is treated as untrusted data. Embedded commands are sanitized and require approval, and planned behaviors are converted into testable guarantees mapped to RED and GREEN evidence.

Why does my test not count as a valid RED state?▼

A test only counts as RED if it was compiled and executed and failed due to the intended bug or missing implementation. Failures from syntax errors, broken setup, or missing dependencies do not qualify, and a test that was written but never run is not RED.

When should I not use strict TDD checkpoints?▼

The RED-first gate applies to all production code changes, but checkpoint commits can be squashed after the workflow completes if the RED/GREEN summary is preserved in the PR body or evidence report. Evidence-only commits are optional when test and fix commits clearly map to RED and GREEN.