| name | harness-tdd |
| description | Vertical-slice test-driven workflow for backend harness features and bug fixes. Use when adding or changing service, server, worker, contract, or repo-tool behavior, or when the user asks for TDD, red-green-refactor, or test-first implementation.
|
Harness TDD
Use this skill to add or change behavior one vertical slice at a time.
Workflow skills guide process. Ownership skills still decide writable boundaries.
Philosophy
Tests should verify observable behavior through public seams, not implementation details.
Prefer tests that survive internal refactors:
- service public API or application seam
- BFF handler or HTTP route behavior
- worker replay, checkpoint, or projection seam
- contract compatibility or drift seam
- repo-tool CLI or validator seam
Loop
For each behavior:
- Pick one observable behavior.
- Write one failing test at the correct public seam.
- Run it and confirm RED.
- Write the smallest correct code to pass.
- Run it and confirm GREEN.
- Refactor only while GREEN.
- Run relevant path-scoped gates.
Anti-Patterns
- Do not write all tests first and then all implementation.
- Do not test private helpers when a public seam can express the behavior.
- Do not mock internal collaborators you own.
- Do not add speculative behavior for future tests.
- Do not expose internal seams only for test convenience.
Mocking Rule
Mock true externals and hard runtime boundaries. Prefer local substitutes or in-memory adapters for owned seams when they provide better behavioral evidence.
Refactor Check
After GREEN, look for shallow modules, duplicated rules, primitive obsession, hidden coupling, or oversized traits. If the fix reveals architecture friction, hand off to harness-architecture-review.
