wf-tdd-cycle

Guides red/green/refactor test-driven development with branch-coverage audits and vacuity checks.

Updated May 9, 2026
One-click install
npx skills add https://github.com/23min/aiwf --skill wf-tdd-cycle-23min
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: wf-tdd-cycle
Source: https://github.com/23min/aiwf/tree/main/internal/skills/embedded-rituals/plugins/wf-rituals/skills/wf-tdd-cycle
Command: npx skills add https://github.com/23min/aiwf --skill wf-tdd-cycle-23min

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? When implementing a single acceptance criterion or feature unit, tests written after the code become verification rather than specification, and coverage numbers alone cannot prove assertions actually catch bugs. This Skill enforces a disciplined test-first cycle so each unit of behavior change gets a failing test before implementation, a minimal green pass, a refactor, and evidence that every branch is genuinely exercised. ## Core Features & Use Cases - Red/Green/Refactor cycle: Write a failing test first, implement the minimum code to pass, then refactor while staying green, with optional aiwf phase promotion (aiwf promote M-NNNN/AC-<N> --phase red|green|refactor|done) for projects tracking TDD phases. - Red-first diff-shape gate: When a project declares test-path globs, the red-phase promotion mechanically refuses if implementation files are dirty before the test, enforcing test-first ordering. - Hard-rule branch-coverage audit: Walk every reachable conditional branch in the diff and confirm an explicit test exercises each side, including defensive and error-handling paths. - Required vacuity check: Invoke wf-vacuity after the audit to verify covered assertions can actually fail, using mutation testing tools where available. - Use Case: While implementing one acceptance criterion of an in-progress milestone, run this cycle to produce the failing test, minimal implementation, and coverage evidence before the milestone ritual marks the criterion met. ## Quick Start Ask the AI to run the wf-tdd-cycle for the acceptance criterion you are about to implement, starting with a failing test before any implementation code.

Frequently Asked Questions about wf-tdd-cycle

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

FAQPage Schema
How do I run a red/green/refactor TDD cycle for one acceptance criterion?▼

Write a failing test describing the expected behavior first, then write the minimum code to make it pass, then refactor while keeping tests green. If the project uses aiwf with tdd: required, promote the AC phase with `aiwf promote M-NNNN/AC-<N> --phase red`, then green, then done.

What is a branch-coverage audit in test-driven development?▼

It is a manual walk of every reachable conditional branch in the changed code—if/else, switch, catch, ternaries, early returns—confirming an explicit test exercises each side. Defensive paths like guards and malformed-input handlers also require tests or a documented unreachability reason.

Why does the red phase promotion fail with aiwf test-path globs configured?▼

The red-first diff-shape gate refuses `--phase red` when any non-test implementation file is dirty, because that means code was written before the test. Write the failing test first and promote immediately; for new symbols, promote while the test still fails to compile, then add the minimal stub.

What is a vacuity check and when should it run?▼

A vacuity check verifies that covered assertions can actually fail and catch bugs, since branch coverage only proves lines ran. It runs right after the branch-coverage audit, preferably via a mechanical mutation tool like Stryker, mutmut, or PIT, scoped to the unit just built.

When should I not use a TDD cycle workflow?▼

Skip it for pure configuration changes or dependency bumps that touch no logic. The cycle is designed for units of behavior change—a single acceptance criterion or focused feature—where a test should exist before the code.