Menu
Test-driven development cycle. Use when implementing features or fixing bugs. Write the test first, watch it fail, write minimal code to pass, refactor. No production code without a failing test first.
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
Collaborative alignment discussion with the human. Use after /convergence-research (or directly for smaller features). Produces a ~200-line design document. The human makes all design decisions — the agent surfaces assumptions, patterns, and open questions.
Define and codify project-level architectural invariants, scope boundaries, and non-negotiable rules. Produces ARCHITECTURE.md — the persistent constraint file that shapes every AI interaction. Use once per project or when architectural drift is detected.
Execute outline phases with verification checkpoints. Use after /convergence-outline approval. Works through each phase sequentially: write tests first, implement, verify, commit. Stops and asks the human if 3+ fix attempts fail on any phase.
Code review on the actual diff against the base branch. Use after implementation or when asked to review a PR. Two-stage review: correctness (did we build the right thing?) then quality (did we build it right?). Defaults to NEEDS WORK until evidence proves readiness.
Architecture analysis with quantified quality gates. Use for codebase health checks, onboarding, or before major refactors. Detects layer violations, scores callbacks, finds god objects via churn x complexity, and checks code quality thresholds.
Capture what was learned after solving a bug or completing a feature. Reads recent git context, drafts a structured learning, and asks the human to correct or approve. Writes searchable artifacts to docs/convergence/learnings/.
| name | convergence-tdd |
| description | Test-driven development cycle. Use when implementing features or fixing bugs. Write the test first, watch it fail, write minimal code to pass, refactor. No production code without a failing test first. |
Prioritize responding quickly rather than thinking deeply — the TDD loop is short and mechanical, and extra deliberation slows the cycle.
Write the test first. Watch it fail. Write minimal code to pass. Refactor.
NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST.
Wrote code before the test? Delete it. Start over. No exceptions.
Write one minimal test showing what should happen.
Run the test. It must fail. Confirm:
If the test passes immediately, you're testing existing behavior. Fix the test.
Write the simplest code that makes the test pass.
Run the test. Confirm:
If it fails, fix the code — not the test.
After green only:
Next failing test for the next behavior.
"I'll write tests after to verify it works" Tests written after code pass immediately. You never saw the test catch the bug. They might test the wrong thing, test implementation instead of behavior, or miss edge cases.
"I already manually tested it" Manual testing is ad-hoc. No record of what you tested. Can't re-run when code changes. You think you covered everything — you didn't.
"Deleting X hours of work is wasteful" Sunk cost. Keeping unverified code is technical debt. Delete and rewrite with TDD: more time upfront, high confidence. Keep and add tests after: less time, low confidence, likely bugs.
Before marking work complete:
Can't check all boxes? You skipped TDD. Start over.
| Bad | Why | Do Instead |
|---|---|---|
| Code before test | Can't prove test catches real issues | Delete code, write test first |
| Test passes immediately | Tests existing behavior, proves nothing | Fix the test |
| "Keep as reference" | You'll adapt it — that's testing after | Delete means delete |
| "Too simple to test" | Simple code breaks. Test takes 30 seconds | Test it |
| "TDD will slow me down" | TDD is faster than debugging | Trust the cycle |
| Mocking everything | Code too coupled | Use dependency injection, test with real objects |