tdd
Test-Driven Development
Use this for behavioral changes where a failing test can describe the desired outcome before implementation.
Workflow
1. Understand
- Read the request, task, issue tracker item, plan, spec, and relevant code as available.
- Identify the desired behavior, existing contracts, failure paths, and verification.
- If a spec exists, note its invariants, decisions, and testing strategy.
- Ask before writing tests when missing information would materially change behavior, scope, safety, contracts, data shape, or verification.
2. Red
- Write the smallest failing test that proves the desired behavior or reproduces the bug.
- Run it and confirm it fails for the expected reason.
3. Green
More from owainlewis/blueprint
plan
Break a spec, brief, issue tracker item, or user request into a portable task list that can be reviewed, copied into an issue tracker, or delegated independently.
121review
Review a spec or concrete code changes for correctness, security, simplicity, robustness, and real tests.
120spec
Write an implementation spec to docs/<feature-slug>/spec.md and pause for human review. Use when the user says \"write a spec\", \"spec this out\", \"technical design\", \"design doc\", or when a task has decisions, invariants, or contracts that should be reviewed before code is written.
117commit
Stage the intended changes and create one clear conventional commit.
110refactor
Improve the shape of existing code without changing behavior.
104debug
Debug systematically: observe, hypothesize, test, fix, verify.
96