Tdd Workflow
Run a strict RED–GREEN–REFACTOR ritual with your coding agent so every feature starts from a failing test instead of guess-and-fix code.
Overview
TDD Workflow is an agent skill most often used in Ship (also Build) that guides solo builders through RED–GREEN–REFACTOR test-first implementation.
Install
npx skills add https://github.com/sickn33/antigravity-awesome-skills --skill tdd-workflowWhat is this skill?
- RED–GREEN–REFACTOR cycle with explicit phase rules
- Three Laws of TDD (production code only for failing tests, minimal test, minimal code)
- RED guidance: behavior, edge cases, and error-state test targets
- GREEN guidance: YAGNI, simplest pass, no premature optimization
- REFACTOR guidance: duplication, naming, structure, and complexity
- 3-phase TDD cycle: RED, GREEN, REFACTOR
- 3 Laws of TDD defined in the skill
Adoption & trust: 796 installs on skills.sh; 40.1k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You are letting your agent write production code without failing tests first, so behavior is vague and fixes become expensive guesswork.
Who is it for?
Feature work in repos that already have a test runner, or greenfield modules where you want the agent to define behavior via tests before implementation.
Skip if: Throwaway prototypes, pure config-only edits, or tasks where the SKILL explicitly cannot run tests (no harness and no intent to add one).
When should I use this skill?
Test-Driven Development workflow principles. RED-GREEN-REFACTOR cycle.
What do I get? / Deliverables
Your agent writes minimal failing tests, passes them with the smallest code change, then refactors with a clear safety net—hand off to code-review or debugging skills if tests still fail unexpectedly.
- Failing test(s) that describe expected behavior
- Minimal passing implementation
- Refactored code with tests still green
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
TDD is canonically shelved under Ship → Testing because the skill’s center of gravity is test-first verification before and during implementation. The subphase is testing: the skill defines laws, phases, and tables for writing failing tests, minimal passes, and refactor—not distribution or infra ops.
Where it fits
Agent adds a pricing API endpoint by writing failure tests for totals and invalid input before handler code.
Agent specs a cart badge component with a failing test for empty-state behavior, then implements minimal UI.
Before release, agent refactors duplicated assertion helpers only after all green tests document current behavior.
When patching a production bug, agent reproduces it with a new failing test, then applies the smallest fix.
How it compares
Use instead of asking the agent to “add tests at the end”—this skill enforces test-first order and phase boundaries.
Common Questions / FAQ
Who is tdd-workflow for?
Solo and indie builders using agentic IDEs who want TDD discipline enforced in chat: failing test → minimal code → refactor, without skipping the red step.
When should I use tdd-workflow?
During Build when implementing endpoints or components, and during Ship when hardening behavior—any time you want RED–GREEN–REFACTOR instead of code-first patches.
Is tdd-workflow safe to install?
It is procedural guidance only; review the Security Audits panel on this Prism page before trusting any third-party skill bundle in your environment.
SKILL.md
READMESKILL.md - Tdd Workflow
# TDD Workflow > Write tests first, code second. --- ## 1. The TDD Cycle ``` 🔴 RED → Write failing test ↓ 🟢 GREEN → Write minimal code to pass ↓ 🔵 REFACTOR → Improve code quality ↓ Repeat... ``` --- ## 2. The Three Laws of TDD 1. Write production code only to make a failing test pass 2. Write only enough test to demonstrate failure 3. Write only enough code to make the test pass --- ## 3. RED Phase Principles ### What to Write | Focus | Example | |-------|---------| | Behavior | "should add two numbers" | | Edge cases | "should handle empty input" | | Error states | "should throw for invalid data" | ### RED Phase Rules - Test must fail first - Test name describes expected behavior - One assertion per test (ideally) --- ## 4. GREEN Phase Principles ### Minimum Code | Principle | Meaning | |-----------|---------| | **YAGNI** | You Aren't Gonna Need It | | **Simplest thing** | Write the minimum to pass | | **No optimization** | Just make it work | ### GREEN Phase Rules - Don't write unneeded code - Don't optimize yet - Pass the test, nothing more --- ## 5. REFACTOR Phase Principles ### What to Improve | Area | Action | |------|--------| | Duplication | Extract common code | | Naming | Make intent clear | | Structure | Improve organization | | Complexity | Simplify logic | ### REFACTOR Rules - All tests must stay green - Small incremental changes - Commit after each refactor --- ## 6. AAA Pattern Every test follows: | Step | Purpose | |------|---------| | **Arrange** | Set up test data | | **Act** | Execute code under test | | **Assert** | Verify expected outcome | --- ## 7. When to Use TDD | Scenario | TDD Value | |----------|-----------| | New feature | High | | Bug fix | High (write test first) | | Complex logic | High | | Exploratory | Low (spike, then TDD) | | UI layout | Low | --- ## 8. Test Prioritization | Priority | Test Type | |----------|-----------| | 1 | Happy path | | 2 | Error cases | | 3 | Edge cases | | 4 | Performance | --- ## 9. Anti-Patterns | ❌ Don't | ✅ Do | |----------|-------| | Skip the RED phase | Watch test fail first | | Write tests after | Write tests before | | Over-engineer initial | Keep it simple | | Multiple asserts | One behavior per test | | Test implementation | Test behavior | --- ## 10. AI-Augmented TDD ### Multi-Agent Pattern | Agent | Role | |-------|------| | Agent A | Write failing tests (RED) | | Agent B | Implement to pass (GREEN) | | Agent C | Optimize (REFACTOR) | --- > **Remember:** The test is the specification. If you can't write a test, you don't understand the requirement. ## When to Use This skill is applicable to execute the workflow or actions described in the overview. ## Limitations - Use this skill only when the task clearly matches the scope described above. - Do not treat the output as a substitute for environment-specific validation, testing, or expert review. - Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.