---
title: "TDD Green Phase: review, role & definition · Undominated.ai"
canonical: https://undominated.ai/agents/github-tdd-green/
description: "Implements the smallest behavior change needed to satisfy an existing failing test."
---

# TDD Green Phase: review, role & definition · Undominated.ai

> Implements the smallest behavior change needed to satisfy an existing failing test.

[← Explore all agents](/agents/)

TESTING AND RELIABILITY / GitHub community

# TDD Green Phase

Implements the smallest behavior change needed to satisfy an existing failing test.

 [Use this definition ↓](#setup)[Original source ↗](https://github.com/github/awesome-copilot/blob/3a685010a7afdc0dbd4c83b7fbda6c316aa516e5/agents/tdd-green.agent.md)

SOURCE REVIEW

 Reviewed 2026-10-14
 Evidence 3 linked sources
 Publisher GitHub community
 Licence [MIT ↗](https://github.com/github/awesome-copilot/blob/3a685010a7afdc0dbd4c83b7fbda6c316aa516e5/LICENSE)
 Revision 3a685010a7af
 [Read what was—and wasn’t—checked ↓](#review)

“Implement minimal code to satisfy GitHub issue requirements and make failing tests pass without over-engineering.”

 [GitHub community · upstream description ↗](https://github.com/github/awesome-copilot/blob/3a685010a7afdc0dbd4c83b7fbda6c316aa516e5/agents/tdd-green.agent.md) Our analysis follows below.

01 / THE REASONING

## Why this made the selection.

 - Green-phase rules say to implement only the current issue and not to modify the failing test.
- The same confirmation rule as the red phase forbids starting changes before the user confirms the plan.

### A good fit for

 - Provide a verified issue and the single failing behaviour test from the red phase.
- Receive minimal implementation plus the full existing-test result and remaining acceptance gaps.

### Weigh up before choosing

 - Green tests demonstrate only the asserted examples; hidden requirements and untested behavior still need review.
- Hard-coded examples are intermediate scaffolding, not a complete solution; inspect untested input cases before release.
- The definition requests broad github/* and terminal tools. Narrow these in your working copy; issue comments or closure require explicit authorization.

02 / THE REVIEW RECORD

## What we actually inspected.

Source review has boundaries. A clear record is more useful than a “safe” badge.

### Material inspected

 - agents/tdd-green.agent.md
- LICENSE
- Definition reread at the preserved revision; scoped workflow and output-contract review on 2026-10-14

### Our findings

 - Frontmatter tools include github/*, edit/editFiles, runTests, and runInTerminal.
- The opening says to write the minimal code that makes the failing tests pass.
- It says not to implement features that are not in the current issue.
- Step 6 says not to modify the test in the green phase.
- It reruns the failing test before implementation and asks not to weaken or rewrite the test to achieve green.
- Constant returns are explicitly a temporary triangulation technique; additional issue scenarios should force generalisation.

### Not established by this review

 - The agent was not executed against a live repository or host.

The review applies to the material and revision named here. A newer upstream release can change its behavior.

03 / PUT IT TO WORK

## Use the role in your project.

[Upstream setup instructions ↗](https://code.visualstudio.com/docs/copilot/customization/custom-agents)
 - Download the original definition with its licence and attribution; inspect the prompt before loading it.
- Put a reviewed working copy at .github/agents/tdd-green.agent.md in the intended project.
- Check the model and tool identifiers supported by your client; grant only the tools needed for the selected task.
- Select the agent in your client and begin with a bounded task whose result you can independently inspect.

### Before you start

 - VS Code GitHub Copilot with custom-agent support
- A project with runnable tests; GitHub integration only if using the issue workflow

### Compatibility

VS Code GitHub Copilot

### Agent instructions and host-provided tools

 - github/*, edit/editFiles, runTests, runInTerminal, and related read and search tools.

### Cost model

MIT. The file does not state a hosted-model price.

THE COMPLETE REVIEWED DEFINITION

## Read it before you reuse it.

Original source bytes, with attribution. Review the host-specific setup notes above.

 Copy definition ↗ [Download definition + licence ↗](/resources/agents/github-tdd-green/bundle.zip)[Raw Markdown ↗](/resources/agents/github-tdd-green/definition.md)
 ---
description: 'Implement minimal code to satisfy GitHub issue requirements and make failing tests pass without over-engineering.'
name: 'TDD Green Phase - Make Tests Pass Quickly'
tools: ['github/*', 'search/fileSearch', 'edit/editFiles', 'execute/runTests', 'execute/runInTerminal', 'execute/getTerminalOutput', 'execute/testFailure', 'read/readFile', 'read/terminalLastCommand', 'read/terminalSelection', 'read/problems', 'search/codebase']
---
# TDD Green Phase - Make Tests Pass Quickly

Write the minimal code necessary to satisfy GitHub issue requirements and make failing tests pass. Resist the urge to write more than required.

## GitHub Issue Integration

### Issue-Driven Implementation
- **Reference issue context** - Keep GitHub issue requirements in focus during implementation
- **Validate against acceptance criteria** - Ensure implementation meets issue definition of done
- **Track progress** - Update issue with implementation progress and blockers
- **Stay in scope** - Implement only what's required by current issue, avoid scope creep

### Implementation Boundaries
- **Issue scope only** - Don't implement features not mentioned in the current issue
- **Future-proofing later** - Defer enhancements mentioned in issue comments for future iterations
- **Minimum viable solution** - Focus on core requirements from issue description

## Core Principles

### Minimal Implementation
- **Just enough code** - Implement only what's needed to satisfy issue requirements and make tests pass
- **Fake it till you make it** - Start with hard-coded returns based on issue examples, then generalise
- **Obvious implementation** - When the solution is clear from issue, implement it directly
- **Triangulation** - Add more tests based on issue scenarios to force generalisation

### Speed Over Perfection
- **Green bar quickly** - Prioritise making tests pass over code quality
- **Ignore code smells temporarily** - Duplication and poor design will be addressed in refactor phase
- **Simple solutions first** - Choose the most straightforward implementation path from issue context
- **Defer complexity** - Don't anticipate requirements beyond current issue scope

### Implementation Strategies (Polyglot)
- **Start with constants** - Return hard-coded values from issue examples initially
- **Progress to conditionals** - Add if/else logic as more issue scenarios are tested
- **Extract to methods/functions** - Create simple helpers when duplication emerges
- **Use basic collections** - Simple arrays, lists, or maps over complex data structures

## Execution Guidelines

1. **Review issue requirements** - Confirm implementation aligns with GitHub issue acceptance criteria
2. **Run the failing test** - Confirm exactly what needs to be implemented
3. **Confirm your plan with the user** - Ensure understanding of requirements and edge cases. NEVER start making changes without user confirmation
4. **Write minimal code** - Add just enough to satisfy issue requirements and make test pass
5. **Run all tests** - Ensure new code doesn't break existing functionality
6. **Do not modify the test** - Ideally the test should not need to change in the Green phase.
7. **Update issue progress** - Comment on implementation status if needed

## Green Phase Checklist
- [ ] Implementation aligns with GitHub issue requirements
- [ ] All tests are passing (green bar)
- [ ] No more code written than necessary for issue scope
- [ ] Existing tests remain unbroken
- [ ] Implementation is simple and direct
- [ ] Issue acceptance criteria satisfied
- [ ] Ready for refactoring phase

The download contains tdd-green.agent.md . Keep its filename when placing it in the agent directory described above.

By **GitHub community**. [Exact upstream source ↗](https://raw.githubusercontent.com/github/awesome-copilot/3a685010a7afdc0dbd4c83b7fbda6c316aa516e5/agents/tdd-green.agent.md) · [Licence](/resources/agents/github-tdd-green/LICENSE.txt) · [Attribution](/resources/agents/github-tdd-green/ATTRIBUTION.txt)

SHA-256 4fc9b0de32880d56ffdba6127ed286ea435f9f568091eb6fb8f794878fa7e18c

 Read the applicable licence MIT License

Copyright GitHub, Inc.

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

04 / FOLLOW THE EVIDENCE

## The source trail.

Our notes are separate from the original resource. Check upstream before adopting a new version.

 - [Definition at the reviewed revision ↗](https://github.com/github/awesome-copilot/blob/3a685010a7afdc0dbd4c83b7fbda6c316aa516e5/agents/tdd-green.agent.md) Checked 2026-10-14 https://github.com/github/awesome-copilot/blob/3a685010a7afdc0dbd4c83b7fbda6c316aa516e5/agents/tdd-green.agent.md Supports: summary, upstreamDescription, whySelected, bestFor, limitations, review, access
- [Licence at the reviewed revision ↗](https://github.com/github/awesome-copilot/blob/3a685010a7afdc0dbd4c83b7fbda6c316aa516e5/LICENSE) Checked 2026-10-14 https://github.com/github/awesome-copilot/blob/3a685010a7afdc0dbd4c83b7fbda6c316aa516e5/LICENSE Supports: license, access.cost
- [Host custom-agent files and tool permissions ↗](https://code.visualstudio.com/docs/copilot/customization/custom-agents) Checked 2026-10-07 https://code.visualstudio.com/docs/copilot/customization/custom-agents Supports: install, compatibility, limitations, access

KEEP COMPARING

## Other approaches to consider.

Related by category or shared topics. These are alternatives to inspect, not a measured quality order.

 [### TDD Red Phase ↗ Writes a failing test tied to a requirement before implementation work begins.](/agents/github-tdd-red/)[### TDD Refactor Phase ↗ Improves a tested implementation through small changes while preserving the existing behavior checks.](/agents/github-tdd-refactor/)[### Pull Request Test Analyzer ↗ Maps a pull request to its tests and identifies meaningful missing failure cases, brittle assertions and uncovered behavioral contracts.](/agents/anthropic-pr-test-analyzer/)

 [AI Tools ↗](/tools/)[Skills ↗](/skills/)[Agents ↗](/agents/)[MCP Servers ↗](/mcp-servers/)[Workflows ↗](/workflows/)

## Continue your investigation

 - [Find reusable instructions](/skills/)
- [Inspect connections](/mcp-servers/)
- [Build a toolkit](/tools/)
- [Choose the model](/compare/)
