test-driven-development

Name: test-driven-development
Availability: InStock
Author: sciman-top

Applies a focused Red-Green-Refactor loop to one explicitly requested behavior seam.

Updated Mar 26, 2026

Search Tags:#tdd #unit testing #test-driven development #red-green-refactor #software testing #test-first

Ready to run

npx skills add https://github.com/sciman-top/skills-manager --skill test-driven-development-sciman-top

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: test-driven-development
Source: https://github.com/sciman-top/skills-manager/tree/main/overrides/patches/test-driven-development
Command: npx skills add https://github.com/sciman-top/skills-manager --skill test-driven-development-sciman-top

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? It prevents test-driven development from being over-applied to routine work by scoping the Red-Green-Refactor cycle to only the behavior seam the user explicitly requests, avoiding unnecessary fixtures, coverage gates, and full-suite runs. ## Core Features & Use Cases - Focused Test-First Loop: Write the smallest failing test, confirm the failure, implement the minimum change, and re-run only that focused test. - Explicit Opt-In Scope: Activates only when the user requests strict TDD or a task contract requires test-first development, leaving configuration, documentation, and generated files untouched. - Use Case: When a task contract says a new validation rule must be developed test-first, use this Skill to write one failing test for that rule, implement the minimal code to pass it, and stop without adding unrelated test infrastructure. ## Quick Start Ask the assistant to use strict test-driven development for the specific behavior you want implemented, naming the exact seam to test first.

Frequently Asked Questions about test-driven-development

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

FAQPage Schema

How do I apply test-driven development to a single feature?▼

Write the smallest test that fails for the missing behavior, run only that focused test to confirm the failure, then implement the minimum change that makes it pass. Re-run the focused test and refactor only while the passing behavior is preserved.

When should I use strict TDD instead of writing tests after code?▼

Use strict TDD only when you explicitly request Red-Green-Refactor or a task contract requires test-first development. Ordinary implementation, configuration, documentation, and generated files do not require this approach.

Does test-driven development require running the full test suite?▼

No. This approach runs only the focused test for the named behavior seam during the loop. The repository's existing risk-based closeout gate is used once at the defined closeout point instead of repeated full-suite runs.

What are the limitations of focused TDD workflows?▼

Focused TDD does not add unrelated fixtures, coverage thresholds, CI jobs, review gates, or one-test-per-file rules. Exploratory work and already-characterized mechanical changes remain outside its scope unless the user explicitly opts in.