eng-tdd
Test-Driven Development (TDD)
Overview
Write the test first. Watch it fail. Implement just enough to pass. Refactor while staying green. If you didn’t see the test fail, you don’t know whether it tests the right behavior.
Iron Law
NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
Wrote code before the test? Delete it. Start from tests.
When to Use
- Every feature, bug fix, refactor, or behavior change.
- Exceptions only with explicit human approval (throwaway prototypes, generated code, etc.).
Red-Green-Refactor Cycle
- RED – Write one minimal test describing desired behavior.
- Clear, specific name.
- Tests real behavior (avoid unnecessary mocks).
More from tjboudreaux/cc-plugin-engineering-excellence
eng-verification
Mandatory checklist before claiming work is complete—run the evidence-producing command, inspect output, and only then state a result.
2eng-performance
Guard latency, memory, battery, bandwidth, and gas/compute budgets by measuring before and after every change.
2eng-user-impact
Anchor every engineering decision in user value, measurable outcomes, accessibility, and cross-platform experience coherence.
2meta-superpowers
Startup protocol for every task—discover applicable skills, run them, announce usage, and follow required workflows (brainstorming, TodoWrite checklists, etc.).
2eng-observability
Design every change with traceability, diagnostics, and fast incident triage in mind across mobile, web, and web3 stacks.
2eng-quality-handoff
Deliver changes with clear communication, reviewer-ready context, and follow-up accountability.
2