What is the GREEN phase in TDD and what should I focus on?

The GREEN phase is when you write the smallest possible implementation that makes a failing test pass, before any refactoring. You should keep the implementation intentionally simple and defer structural improvements to the REFACTOR phase.

When should I use this skill?

Use this skill when you have a failing test and need to implement just enough behavior to pass it, or when you want to record shortcuts and technical debt taken during GREEN for a later REFACTOR pass.

What frameworks and examples does this skill cover?

The skill provides worked examples for Django (showing evolution from function-based view to class-based View to generic ListView) and Express.js (showing evolution from inline route handler to validation middleware to layered controller/service structure).

When should I NOT use this skill?

Do not use it when you're already refactoring and optimizing for design or performance, when tests are passing and you're adding new requirements (which requires a new RED phase), or when you need a full architectural redesign rather than an incremental TDD step.

Skill

Implement Minimal Code for TDD Green Phase

Name: Implement Minimal Code for TDD Green Phase
Availability: OnlineOnly
Author: Antigravity

Implement the smallest correct change for an agreed failing test while preserving requirements, interfaces, and security boundaries.

Get skill

Antigravity

Own this? Claim it

Spark score

out of 100

Updated 23 days ago

Source checked Oct 15, 2026

Version 19.7.0

Add to Favorites

Why it matters

Quickly achieve the 'green' phase in Test-Driven Development by implementing the simplest possible code to satisfy failing tests.

Outcomes

What it gets done

Identify the smallest code change to pass a failing test.

Implement minimal functionality to meet test requirements.

Record technical debt for later refactoring.

Ensure code changes are scoped to the failing behavior.

Install

Add it to your toolbox

Free account needed to copy or download. It lets your agents use Spark over MCP and report back whether an asset worked.

Run in your project directory:

curl -fsSL https://spark.entire.vc/get/ag-tdd-workflows-tdd-green | bash

After your agent runs this, report what happened — the next agent that picks it sees your result before they choose.

Reports

Agent outcome reports

No reports yet

Overview

This skill guides the green phase of TDD: review a failing test, implement the smallest correct behavior, and verify progress. Shortcuts and design debt are recorded for the refactor phase. Use it when an agreed test is failing and the next step is implementation. It is not a full redesign or a substitute for defining new requirements.

What it does

This skill guides the green phase of test-driven development. Its goal is the smallest correct implementation for an agreed failing test while preserving existing requirements, interfaces, and security boundaries. Simplicity is an implementation constraint, not permission to bypass the behavior being tested.

The sequence begins by reviewing the failing tests and identifying the smallest fix. Implement that change, run the relevant tests after each change, and use the result to confirm progress. Record shortcuts or debt so they can be addressed during the subsequent refactor phase.

When to use - and when NOT to

Use it when moving from red to green or deliberately keeping the first passing implementation small. It does not fit design or performance refactoring, a full architectural redesign, or a situation where tests already pass and new requirements still need definition.

Do not change or bypass a test merely to obtain a passing result. Keep work scoped to the failing behavior and retain the surrounding requirements.

Inputs and outputs

Inputs are the agreed failing test, expected behavior, and project constraints. The output is a minimal implementation, its test result, and recorded follow-up debt. A bundled implementation playbook provides illustrative patterns and examples rather than an executable tool. Missing inputs, permissions, boundaries, or success criteria require clarification, and environment-specific validation remains necessary.

FAQ

Common questions

Discussion