team-tdd

Enforce a RED-GREEN-REFACTOR test-driven development workflow with failing tests before production code.

1|Updated Mar 6, 2026
One-click install
npx skills add https://github.com/davekim917/bootstrap --skill team-tdd
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: team-tdd
Source: https://github.com/davekim917/bootstrap/tree/main/plugins/workflow/skills/team-tdd
Command: npx skills add https://github.com/davekim917/bootstrap --skill team-tdd

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

Enforces test-first development discipline, ensuring that production changes are always guarded by failing tests before implementation.

Core Features & Use Cases

  • RED-GREEN-REFACTOR workflow across software tasks (build, fix, refactor) to guarantee verifiable changes
  • Anti-pattern awareness and guardrails (no test-after rationalization, no mock-duplication) integrated into team processes
  • Cross-domain applicability: software engineering, analytics, data pipelines, ML features all benefit from a test-driven mindset

Quick Start

Write a failing test first to drive development, then implement just enough production code to pass.

Frequently Asked Questions about team-tdd

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

FAQPage Schema
How do I enforce test-driven development across my software engineering team?

The RED-GREEN-REFACTOR workflow requires writing a failing test first to define requirements, implementing just enough production code to pass that test, and then refactoring the code while ensuring tests remain green for verifiable changes.

Can I apply test-first discipline to tasks like bug fixes and refactoring?

Yes, test-first discipline applies across software engineering domains including bug fixes, refactoring, and feature development, ensuring all production changes are guarded by failing tests to verify behavior and maintain quality.

What are common anti-patterns when implementing a TDD workflow?

Common TDD anti-patterns include writing tests after development to rationalize existing code and duplicating mock logic, which this workflow guards against by enforcing strict test-first discipline and explicit acceptance criteria.

Does test-driven development work for analytics and data pipelines?

Test-driven development benefits cross-domain analytics, data pipelines, and ML features by applying a test-first mindset, ensuring data transformations and pipeline changes remain verifiable and guarded by failing tests before implementation.

Why should I write a failing test before implementing production code?

Writing a failing test before production code ensures your changes are explicitly verifiable and driven by requirements, preventing untested code paths and establishing clear acceptance criteria for reliable software engineering.