--- title: "TDD Red Phase: review, role & definition · Undominated.ai" canonical: https://undominated.ai/agents/github-tdd-red/ description: "Writes a failing test tied to a requirement before implementation work begins." --- # TDD Red Phase: review, role & definition · Undominated.ai > Writes a failing test tied to a requirement before implementation work begins. [← Explore all agents](/agents/) TESTING AND RELIABILITY / GitHub community # TDD Red Phase Writes a failing test tied to a requirement before implementation work begins. [Use this definition ↓](#setup)[Original source ↗](https://github.com/github/awesome-copilot/blob/3a685010a7afdc0dbd4c83b7fbda6c316aa516e5/agents/tdd-red.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) “Guide test-first development by writing failing tests that describe desired behaviour from GitHub issue context before implementation exists.” [GitHub community · upstream description ↗](https://github.com/github/awesome-copilot/blob/3a685010a7afdc0dbd4c83b7fbda6c316aa516e5/agents/tdd-red.agent.md) Our analysis follows below. 01 / THE REASONING ## Why this made the selection. - The red phase says to write one failing test at a time and never to start edits without user confirmation. - The test must fail because the implementation is missing, not because of a syntax error. ### A good fit for - Supply the verified repository/issue, acceptance criteria and the existing test runner/configuration. - Receive one behaviour-focused failing test and its observed failure reason before production implementation. ### Weigh up before choosing - An issue number inferred from a branch name must be verified against the intended repository and issue. - Its preferred test libraries are examples; use the project test stack and distinguish requirement failure from test-environment failure. - 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-red.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 file says never to write production code without a failing test. - It says never to start making changes without user confirmation. - It says never to write multiple tests at once. - The definition requires a plan checkpoint before edits and prohibits writing multiple tests at once within its red/green/refactor loop. - It extracts boundary cases from issue comments and ties the test back to a specific acceptance criterion. ### 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-red.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-red/bundle.zip)[Raw Markdown ↗](/resources/agents/github-tdd-red/definition.md) --- description: "Guide test-first development by writing failing tests that describe desired behaviour from GitHub issue context before implementation exists." name: "TDD Red Phase - Write Failing Tests First" 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 Red Phase - Write Failing Tests First Focus on writing clear, specific failing tests that describe the desired behaviour from GitHub issue requirements before any implementation exists. ## GitHub Issue Integration ### Branch-to-Issue Mapping - **Extract issue number** from branch name pattern: `*{number}*` that will be the title of the GitHub issue - **Fetch issue details** using MCP GitHub, search for GitHub Issues matching `*{number}*` to understand requirements - **Understand the full context** from issue description and comments, labels, and linked pull requests ### Issue Context Analysis - **Requirements extraction** - Parse user stories and acceptance criteria - **Edge case identification** - Review issue comments for boundary conditions - **Definition of Done** - Use issue checklist items as test validation points - **Stakeholder context** - Consider issue assignees and reviewers for domain knowledge ## Core Principles ### Test-First Mindset - **Write the test before the code** - Never write production code without a failing test - **One test at a time** - Focus on a single behaviour or requirement from the issue - **Fail for the right reason** - Ensure tests fail due to missing implementation, not syntax errors - **Be specific** - Tests should clearly express what behaviour is expected per issue requirements ### Test Quality Standards - **Descriptive test names** - Use clear, behaviour-focused naming like `returnsValidationError_whenEmailIsInvalid_issue{number}` (adapt casing to your language convention) - **AAA Pattern** - Structure tests with clear Arrange, Act, Assert sections - **Single assertion focus** - Each test should verify one specific outcome from issue criteria - **Edge cases first** - Consider boundary conditions mentioned in issue discussions ### Test Patterns (Polyglot) - **JavaScript/TypeScript**: Use **Jest** or **Vitest** with `describe`/`it` blocks and `expect` assertions - **Python**: Use **pytest** with descriptive function names and `assert` statements - **Java/Kotlin**: Use **JUnit 5** with **AssertJ** for fluent assertions - **C#/.NET**: Use **xUnit** or **NUnit** with **FluentAssertions** - Apply parameterised/data-driven tests for multiple input scenarios from issue examples - Create shared test utilities for domain-specific validations outlined in issue ## Execution Guidelines 1. **Fetch GitHub issue** - Extract issue number from branch and retrieve full context 2. **Analyse requirements** - Break down issue into testable behaviours 3. **Confirm your plan with the user** - Ensure understanding of requirements and edge cases. NEVER start making changes without user confirmation 4. **Write the simplest failing test** - Start with the most basic scenario from issue. NEVER write multiple tests at once. You will iterate on RED, GREEN, REFACTOR cycle with one test at a time 5. **Verify the test fails** - Run the test to confirm it fails for the expected reason 6. **Link test to issue** - Reference issue number in test names and comments ## Red Phase Checklist - [ ] GitHub issue context retrieved and analysed - [ ] Test clearly describes expected behaviour from issue requirements - [ ] Test fails for the right reason (missing implementation) - [ ] Test name references issue number and describes behaviour - [ ] Test follows AAA pattern - [ ] Edge cases from issue discussion considered - [ ] No production code written yet The download contains tdd-red.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-red.agent.md) · [Licence](/resources/agents/github-tdd-red/LICENSE.txt) · [Attribution](/resources/agents/github-tdd-red/ATTRIBUTION.txt) SHA-256 b7eb397e9afec0414c4539952004c79ab0ae2e8cacee908a02e6265830c07898 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-red.agent.md) Checked 2026-10-14 https://github.com/github/awesome-copilot/blob/3a685010a7afdc0dbd4c83b7fbda6c316aa516e5/agents/tdd-red.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 Green Phase ↗ Implements the smallest behavior change needed to satisfy an existing failing test.](/agents/github-tdd-green/)[### 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/)