| name | tdd |
| description | Practice test-driven development for new features and bug fixes. |
TDD
Invocation
This skill is performed in the Developer persona. If you are not already running as Developer (for example, the user invoked /tdd directly), read subagents/developer.md and adopt its role guidance for the rest of this task. Stay in the current chat—do not delegate to a subagent.
Objective
Use a red -> green -> refactor workflow for changes that should be test-first.
Use /code instead when the work is implementation-heavy but not centered on new automated test coverage, such as tooling, config, or linting work.
Instructions
- Determine whether the task is a bug fix or a new feature.
- For new features, read the relevant spec or acceptance criteria before writing tests.
- For bug fixes, capture the expected behavior, actual behavior, and reproduction path before writing tests.
- Identify the most appropriate unit-level test location based on nearby repo patterns.
- Write the failing test first.
- Verify the red phase by running the relevant test suite.
- Implement the smallest change needed to make the new test pass.
- Re-run tests, then run the applicable verification checks (linting, type checking, etc.).
- If the change also requires browser-flow validation, call out that E2E tests are relevant and why.
- End with the test paths, the observed red failure, the passing result, and any follow-up work.
Guardrails
- Do not create or modify E2E tests unless the user explicitly asks for E2E coverage.
- Keep TDD changes scoped to the behavior under test.
- Refactor only after the tests demonstrate the intended behavior.