Test driven development codex

Skill mzored/superpowers-cc-to-codex/skills/test-driven-development-codex

Enforce strict test-driven development via Codex-backed implementation. Use only when the user explicitly asks for the Codex-backed TDD workflow.From its SKILL.md

Install

npx -y skills add mzored/superpowers-cc-to-codex --skill test-driven-development-codex

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

7 stars7 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

4.6 KB, as published. Nobody here has run it

Test-Driven Development

Keep Claude in the main thread for user interaction and task acceptance. Call the codex_implement MCP tool with promptTemplate: "tdd" for TDD-disciplined implementation. Use codex_resume for fix loops if TDD discipline is violated. Reference testing-anti-patterns.md when reviewing Codex output for testing quality.

<HARD-GATE> You MUST call codex_implement with promptTemplate: "tdd" (Step 2). You cannot implement with TDD yourself. Codex enforces red-green-refactor discipline. No MCP call = cannot proceed. </HARD-GATE>

Overview

Tests written after code prove nothing — passing tests don't confirm they test the right thing.

Core principle: NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST.

Announce at start: "I'm using the test-driven-development skill to implement this with strict red-green-refactor discipline."

The Iron Law

If you didn't watch the test fail, you don't know if it tests the right thing.

If Codex returns implementation without red-green evidence, reject it and resume with TDD enforcement.

When to Use

Any implementation task where test coverage is critical
New features, bug fixes, refactors where behavior must be verified
When the user explicitly requests TDD methodology

Workflow

Step 1: Verify Task Readiness

Task has clear acceptance criteria
Test framework is identified (check existing test files)
Codex CLI is available

If acceptance criteria are unclear, ask the user before dispatching.

Step 2: Call `codex_implement` with TDD Prompt Template

Call the codex_implement MCP tool with promptTemplate: "tdd":

{
  "tool": "codex_implement",
  "arguments": {
    "taskId": "task-17",
    "promptTemplate": "tdd",
    "prompt": "Implement the requested behavior with strict red-green-refactor discipline. Write the failing test first, then the minimal production change, then refactor only if the tests still pass.",
    "workspaceRoot": "/absolute/path/to/your/repo"
  }
}

The tdd prompt template routes through skills/test-driven-development-codex/prompts/tdd-implement-task.md.

Step 3: Verify TDD Evidence in Results

When Codex returns, check:

tests array is non-empty
Tests were written before implementation (red-green-refactor order)
Each test has a clear, descriptive name covering one behavior
No testing anti-patterns (see testing-anti-patterns.md)

Step 4: Handle Status

Status	Action
`DONE`	Verify tests pass, accept implementation
`DONE_WITH_CONCERNS`	Review concerns, check if TDD was followed despite issues
`BLOCKED`	Surface blocker to user, do not attempt workarounds
`NEEDS_CONTEXT`	Answer Codex's questions, resume with fix prompt

Step 5: Resume if TDD Violated

If the tests array is empty or implementation lacks red-green evidence, call codex_resume with promptTemplate: "tdd":

{
  "tool": "codex_resume",
  "arguments": {
    "taskId": "task-17",
    "sessionId": "<sessionId-from-previous-run>",
    "promptTemplate": "tdd",
    "prompt": "Tests must be written BEFORE implementation. Delete any production code written without a failing test. Start the red-green-refactor cycle from scratch. Fix the failing test: <describe what needs fixing>",
    "workspaceRoot": "/absolute/path/to/your/repo"
  }
}

Red Flags

Never:

Accept implementation without corresponding tests
Skip the red-green-refactor cycle "just this once"
Allow mocks to replace real behavior verification
Let Codex write tests after implementation

Always:

Verify test failure evidence before accepting
Check for anti-patterns from testing-anti-patterns.md
Ensure minimal implementation matching test requirements
Run the full test suite after accepting

Integration

Can be used standalone or as a methodology enforcer within subagent-driven-development by swapping the prompt file from implement-task.md to tdd-implement-task.md.

Pairs with:

subagent-driven-development — TDD prompt can replace the standard implement prompt
requesting-code-review — Review should verify TDD discipline was followed