Menu
Enforces red-green-refactor TDD cycle with atomic commits per phase. Used when implementing features, fixing bugs, or when tests should drive the design.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Evidence-based verification with 2 quality gates (pre-check and post-check), anti-rationalization enforcement, and 3-step retry escalation. Used when completing tasks, verifying implementations, or before claiming work is done.
Routes work through MaxsimCLI commands based on project state and user intent. Provides command reference and decision routing table. Used when determining which MaxsimCLI command to use or when starting a new session.
Coordinates Tier 2 Agent Teams with TeamCreate, SendMessage, competitive implementation, multi-reviewer code review, and collaborative debugging patterns. Used when workflows require inter-agent communication, adversarial debate, or shared task lists.
Autonomous optimization loop with reference workflows. Powers /maxsim:improve, /maxsim:fix-loop, /maxsim:debug-loop, /maxsim:security. Used when running autonomous optimization, error repair, bug hunting, or security audit loops.
GitHub-native persistence for project learnings, decisions, and patterns using issue labels and structured comments. Used when recording what worked, what failed, or architectural decisions that should persist across sessions.
Orchestrates parallel agent execution using worktree isolation following Anthropic's batch pattern. Used when multiple independent tasks can be executed simultaneously.
| name | tdd |
| description | Enforces red-green-refactor TDD cycle with atomic commits per phase. Used when implementing features, fixing bugs, or when tests should drive the design. |
Write the test first. Watch it fail. Write minimal code to pass. Clean up.
Good fit: Business logic with defined I/O, API endpoints with contracts, data transformations, validation rules, algorithms, state machines, bug fixes.
Poor fit: UI layout, configuration files, build scripts, one-off scripts, mechanical renames, exploratory spikes.
Verify RED: Run the test. It MUST fail with an assertion error — not a syntax error or import failure. If the test passes immediately, it is testing existing behavior. Rewrite it.
Verify GREEN: Run all tests. The new test must pass. ALL existing tests must still pass. If any existing test fails, fix the code — not the tests.
Verify REFACTOR: All tests still pass. No behavior changed.
Move to the next failing test for the next unit of behavior.
Each TDD cycle produces 2–3 atomic commits:
| Phase | Commit format |
|---|---|
| RED | test({scope}): add failing test for [feature] |
| GREEN | feat({scope}): implement [feature] |
| REFACTOR | refactor({scope}): clean up [feature] (omit if no changes) |
Keep commits small. One cycle = one feature unit = one commit group.
TDD uses approximately 40% more context than direct implementation due to cycle overhead. Plan accordingly for long task lists.
| Excuse | Why It Fails |
|---|---|
| "Too simple to test" | Simple code breaks. The test takes 30 seconds to write. |
| "I'll add tests after" | Tests written after pass immediately — they prove nothing. |
| "I know the code works" | Knowledge is not evidence. A passing test is evidence. |
| "TDD is slower" | TDD is faster than debugging. Every skipped test creates debt. |
| "Mocks make this easy" | Over-mocking tests the mock, not the code. Prefer real code paths. |
Stop immediately if you catch yourself writing implementation code before a test, writing a test that passes on the first run, skipping VERIFY RED, or adding features beyond what the current test requires.
See also: verification for evidence-based completion claims after TDD cycles.
