hyper-tdd

Enforce a failing-first test-driven workflow for code changes.

3|Updated May 10, 2026
One-click install
npx skills add https://github.com/zeikar/hyperclaude --skill hyper-tdd
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: hyper-tdd
Source: https://github.com/zeikar/hyperclaude/tree/main/skills/hyper-tdd
Command: npx skills add https://github.com/zeikar/hyperclaude --skill hyper-tdd

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

hyper-tdd helps you prevent broken behavior from slipping into production by forcing a failing test before you write the production code that will satisfy it.

Core Features & Use Cases

  • Failing-first discipline: Write the behavior-focused test first, run it, and confirm the failure is for the right reason.
  • Minimum code to pass: Implement only what the current failing test requires, avoiding scope creep.
  • Behavioral commits: Make one behavior-focused change per commit, then refactor only when the tests still pass.

Use case: You’re about to change business logic (or fix a bug) and want confidence that the new behavior is real, not accidental—start from a test that demonstrates the missing behavior.

Quick Start

When you’re about to change behavior-bearing code, invoke the skill as /hyperclaude:hyper-tdd and follow the failing-first loop until the test passes and the behavior is covered.

Frequently Asked Questions about hyper-tdd

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

FAQPage Schema
How do I use test-driven development to fix bugs without introducing new behavior issues?

Use a failing-first test-driven workflow by writing a behavior-named failing test, verifying the failure source is correct, implementing the minimum code to pass, and iterating with passing test confirmation to reduce the risk of incorrect behavior.

What is failing-first TDD discipline and how does it prevent scope creep?

Failing-first TDD discipline requires writing a behavior-focused test first, confirming it fails for the right reason, and implementing only what the current failing test requires. This prevents scope creep by avoiding unnecessary work during code changes.

How do I write a behavior-named failing test before modifying business logic?

To write a behavior-named failing test before modifying business logic, define the expected behavior in a test, run it to verify the failure source is correct, then implement the minimum production code required to make that specific test pass.

Can I refactor code while maintaining test-driven commit discipline?

You can refactor code while maintaining commit discipline by making one behavior-focused change per commit, then refactoring only when the tests still pass. This ensures your behavior-driven tests confirm correctness throughout the process.

Does test-driven development work for adding new functions or is it only for bug fixes?

Test-driven development works for both writing new functions and modifying business logic, as well as bug fixes where you want to confirm the failure reason and implementation correctness through a failing-first workflow.