test-driven-development
Test-Driven Development (TDD)
Overview
Write the test first. Watch it fail. Write minimal code to pass.
Core principle: If you didn't watch the test fail, you don't know if it tests the right thing.
Violating the letter of the rules is violating the spirit of the rules.
When to Use
Always:
- New features
- Bug fixes
- Refactoring
- Behavior changes
Exceptions (ask your human partner):
More from hwatkins/my-skills
elixir-tdd
Test-driven development enforcement for Elixir and Phoenix. Requires failing tests before implementation. Use when implementing features, fixing bugs, or when code quality discipline is needed.
23spam-prevention
When the user needs to prevent spam signups, bot accounts, fake registrations, or abuse of signup/trial flows. Also use when mentioning "spam accounts," "fake signups," "bot registrations," "disposable emails," "signup abuse," or "trial fraud." For broader security concerns, see saas-security.
14elixir-otp
OTP patterns for Elixir — GenServer, Agent, Task, ETS, supervision trees, Registry, and process design. Use when designing concurrent systems, stateful processes, or deciding when (and when NOT) to use processes.
8rust-tdd
Test-driven development enforcement for Rust. Requires failing tests before implementation. Use when implementing features, fixing bugs, or when code quality discipline is needed.
5rust-core
Expert Rust development with ownership, borrowing, lifetimes, traits, error handling, and idiomatic patterns. Use for any Rust code.
4rust-async
Async Rust with Tokio, futures, concurrency patterns, channels, and performance. Use when building async services, networking, or concurrent Rust applications.
4