| name | harness-plan |
| description | Phase skill: create an implementation plan with TDD test strategy |
| user-invocable | false |
Purpose
Produce a concrete plan that covers all acceptance criteria with a TDD approach.
Steps
-
Read ticket context and scope from state outputs
-
Draft the plan:
- List changes in order of implementation
- For each change, specify:
- What tests to write first (TDD)
- What code to implement to make them pass
- What file(s) to create or modify
- If schema changes are needed: include Drizzle migration step
- If new API routes: include Zod schema updates in
packages/types/
-
Verify coverage:
- Every acceptance criterion from the ticket maps to at least one test
- Every file change has a reason traced back to the ticket
-
Write to state outputs:
{
"plan": "...",
"test_strategy": "...",
"schema_changes": true|false,
"estimated_files": 5
}
-
Record to conversation file:
-
Insert before the ## Harness Issues marker in .harness/conversations/<task-id>.md (use Edit tool with ## Harness Issues as the anchor — do NOT literally append, that would land below the issues section):
## Plan
**Approach:** <summary>
**Test strategy:** <TDD approach>
**Files to change:** <count>
-
If you hit friction while planning (had to revise the plan, ambiguous requirements, blocked on unknowns), append an entry to the literal end of the file — it will land inside the ## Harness Issues section since that section is last.
-
If profile is full: set phase status to waiting — human reviews the plan before implementation starts. Present the plan clearly and ask for approval.
Checklist
Escalation
- If requirements are ambiguous, stop and ask rather than guessing
- If the change requires an architecture decision not covered by existing patterns, escalate
- Stuck after 2 attempts at planning → surface to human