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 minhtri2710/opencode-warcraft
br
>-
1writing-plans
Use when you have a spec or requirements for a multi-step task, before touching code
1writing-skills
Use when creating or updating built-in skills so they remain discoverable, testable, and aligned with both upstream superpowers and Warcraft workflows.
1code-reviewer
Use when reviewing implementation changes against an approved plan or task (especially before merging or between Warcraft tasks) to catch missing requirements, YAGNI, dead code, and risky patterns
1executing-plans
Use when you have a written implementation plan to execute in a separate session with review checkpoints
1using-git-worktrees
Use when starting implementation work that requires Warcraft-managed task workspaces and reproducible task execution.
1