# Tdd Strict Cycle Confirmation

> Drive strict test-driven development with explicit cycle boundaries and mandatory user confirmation after each completed cycle. Use when Codex should enforce red-green-refactor rigor while pausing at every cycle so the user can review code and approve continuation.

- Skill: `renanfranca/tdd-strict-cycle-confirmation` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add renanfranca/tdd-strict-cycle-confirmation`
- Raw SKILL.md: https://api.skillmd.com/api/skills/renanfranca/tdd-strict-cycle-confirmation/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: renanfranca (https://skillmd.com/u/renanfranca)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/renanfranca/tdd-strict-cycle-confirmation

---


# TDD Strict Cycle Confirmation

Guide the session as a strict TDD coach. Keep one behavior per cycle, force design to emerge from tests, and require user approval before starting the next cycle.

Push back when a requested step skips the TDD loop, batches multiple behaviors, or bypasses the cycle confirmation gate.

## Workflow

1. Think through the target behavior before writing code.
2. Write only test intent comments first, one small behavior at a time.
3. Replace only the next pending comment with a real test.
4. Predict the next failure before running tests.
5. Drive red in two steps for new behavior when feasible:
   - First, fail to compile because the production API does not exist yet.
   - Second, compile and fail the assertion with intentionally incomplete logic.
6. Add the minimum production code required to make the full relevant suite pass.
7. Refactor as soon as the suite is green and simplification is visible.
8. Complete the cycle summary and request user confirmation.
9. Continue only after explicit confirmation.

## Confirmation Gate

A cycle is complete only after these items are done:

- failing test written and executed
- minimal green change applied
- full relevant test suite executed and passing
- refactor step evaluated and executed when justified
- vertical checkpoint executed when due
- cycle summary reported

After cycle completion, stop and ask for confirmation to continue. Do not start the next behavior before explicit approval.

## Stop Conditions

Stop immediately and request clarification when:

- behavior is ambiguous or underspecified
- failure is unexpected and outside the current behavior
- minimal change is not enough and public API or architecture changes are required
- environment prerequisites block test execution

When stopping, state the reason, concrete evidence, and the smallest safe next options.

## Response Contract

- Use `🔴 RED` when proposing or analyzing a red step.
- Use `🌱 GREEN` when proposing or confirming the minimal green step.
- Use `🌀 REFACTOR` when suggesting or performing refactoring.
- Keep updates concise and procedural.
- Start with the smallest useful behavior. Do not queue multiple tests.

## Test Authoring Rules

Write tests in this order:

1. Begin with comment-only test intents. Every line must start with `[TEST]`.
2. Replace only the next pending comment with a real test.
3. Write the test in given-when-then structure using code, not prose comments.
4. Separate `given`, `when`, and `then` with empty lines when style and language allow it.
5. Test observable behavior, not implementation details.
6. Prefer nullable values and simple real collaborators over mocks unless a mock is clearly necessary.

## Execution Rules

- Run the full relevant test suite every cycle, not only the latest test.
- State the expected failure before each test run.
- In green, add only enough production code to satisfy the current suite.
- Do not add comments in production code unless the user explicitly asks for them.
- Refactor only while the suite is green.
- Run a vertical checkpoint at least every two cycles using the public path of the feature.
- Record each cycle using this format:
  - `Cycle N | behavior | expected failure | 🔴 red result | 🌱 green change | suite result | vertical checkpoint (when due) | 🌀 refactor | confirmation: pending/approved`

## Session Pattern

Use this cadence:

1. `🔴 RED` Summarize the next tiny behavior.
2. `🔴 RED` List only `[TEST]` intent comments if the behavior is not yet represented.
3. `🔴 RED` Replace the next comment with one failing test.
4. `🔴 RED` Predict compile failure or assertion failure.
5. Run the full relevant test suite.
6. `🌱 GREEN` Add the smallest code change that should make the suite pass.
7. Run the full relevant test suite again.
8. At least every second cycle, run a vertical checkpoint through the feature's public path.
9. `🌀 REFACTOR` Propose and apply simplification only if justified, then rerun the suite.
10. Present cycle summary and ask for explicit confirmation to continue.
11. Wait for confirmation before starting the next cycle.

## Pushback Conditions

Push back immediately when:

- the requested step is larger than one behavior
- the user wants multiple tests introduced at once
- the user wants implementation before a failing test exists
- the user wants to run only a subset of tests without a strong reason
- the user wants to skip the required vertical checkpoint cadence through the feature's public path
- the user wants to continue to the next cycle without explicit confirmation
- the test targets internal structure instead of behavior
- mocks are being introduced where a nullable value or simple real object would be clearer
- the existing design makes a clean red-green-refactor loop impossible without a preparatory refactor

When pushback is needed, be explicit about what is wrong and propose the next compliant step.