tdd-execute-codex

name	tdd-execute-codex
description	Full TDD with Codex-native routing: write failing tests first, verify RED, implement locally for small changes, and use Codex subagents for larger parallelizable work when delegation is allowed. Finish with a review pass before delivery. Use when the user asks for /tdd-execute-codex, TDD execute, test-driven implementation, or a larger TDD change that benefits from explicit delegation.

TDD-Execute-Codex

Core Protocols

• Write tests first. Confirm RED before changing production code.
• Keep the main thread responsible for task framing, test intent, final design choice, and final merge.
• Use English for code, test names, commit-style notes, and subagent instructions unless the repository already uses another convention.
• Sanitize secrets before sharing file contents with subagents.
• Route by production-code scope only. Ignore test files when sizing the change.

Workflow

Phase 0: Read the Task

1. If the argument looks like a readable path, read it as the task or plan file.
2. Otherwise, treat the argument as the task description.
3. Restate the implementation target in one short paragraph before editing.

Phase 1: Gather Context and Establish a Baseline

1. Read the relevant production files and existing tests.
2. Record START_SHA with git rev-parse HEAD.
3. If the worktree is dirty, inspect whether the existing edits overlap the task. Continue without reverting unrelated changes. Ask the user only when the overlap is ambiguous or would require touching the same lines.
4. Run the smallest useful baseline test scope and note existing failures.

Phase 2: Write Tests First (RED)

1. Read references/tdd-specialist-role.md from this skill directory.
2. Add or update tests before touching production code.
3. Create failing tests only.
4. Run the new tests and confirm RED.
5. If the tests pass unexpectedly or fail for the wrong reason, fix the tests first.

Phase 3: Review the Tests

1. Inspect the new tests for requirement coverage, false positives, brittle assertions, missing edge cases, and readability.
2. Fix serious issues in the tests.
3. Re-run the new tests and confirm RED again.

Phase 4: Route the Implementation

Use this routing rule against production-code scope only:

• Small change: touches at most 2 production files, estimated implementation diff is at most 30 lines, and introduces no new abstraction or cross-cutting logic.
• Large change: anything else.

Announce the chosen route before implementing.

Route A: Small Change

1. Implement locally in the main thread.
2. Keep the new tests green after each edit.
3. Run the new tests and then the baseline scope.
4. Run the platform review flow on the current diff. Prefer /review if the environment exposes it. Otherwise run an explicit review pass using the Codex review rule below.
5. Fix accepted critical or high-confidence correctness issues and re-review if needed.

Route B: Large Change

1. Decide whether delegation is allowed by the user request and current environment.
2. If delegation is allowed, read references/codex-worker-role.md from this skill directory before spawning production-code subagents.
3. If delegation is not allowed, keep the production edits in the main thread and preserve the same bounded-file mindset you would have assigned to subagents.
4. When delegating, prefer explorer agents for read-only analysis and worker agents for production-code changes. Give each worker a disjoint write scope when parallelizing.
5. When delegating, split work into focused tasks such as codebase exploration, implementation-plan validation, edge-case analysis, targeted implementation slices, or targeted refactor review.
6. Keep the main thread responsible for final design choice, test ownership, direct test edits, and merging subagent findings.
7. When delegating, give each subagent a narrow goal, the required files, hard constraints, and a concrete output format.
8. Do not allow subagents to change test intent unless the main thread approves it.
9. After each implementation round, run the new tests and then the baseline scope.
10. Once the implementation stabilizes, run the platform review flow on the final diff. Prefer /review if the environment exposes it. Otherwise run an explicit review pass using the Codex review rule below.

Codex Review Rule

When running review, prioritize:

• bugs
• regressions
• incorrect assumptions
• missing tests
• risky edge cases

Treat critical or high-confidence correctness issues as must-fix before delivery. Record any deferred medium or low-risk items explicitly.

Delivery

Report:

• RED confirmation
• chosen route
• what changed
• GREEN confirmation
• coverage status or coverage not measured
• review outcome
• any deferred medium or low-risk items