| name | draft-test-cases |
| description | Draft or refine the test-cases checklist for this card |
| label | Draft test cases |
| pill-order | {"specifying":9,"implementing":5} |
| jockey-hint | Surface when the card has specs but no test cases yet, or when the user wants to refresh the scenario list. Demote once a healthy test-cases file exists unless the user signals a fresh area to cover. |
| workhorse-version | 0.1.0 |
Your task: Draft test cases
If you don't already have this card's context (title, identifier, description) — for instance when running outside Workhorse — establish it first by following .agents/docs/card-context.md.
Produce or refine the card's test-cases checklist — the concrete scenarios that verify this card is done. The file is read by both the tester running scenarios by hand and the implementing agent writing automated tests against them.
- Read the card's specs in
.workhorse/specs/ and any existing test cases at .workhorse/test-cases/{card-id}/
- Skim the target repo to ground the scenarios in the actual surfaces involved
- If a test-cases file already exists, edit it in place — add, refine, or reorder scenarios. Don't replace work that still applies
- If none exists, create one at
.workhorse/test-cases/{card-id}/overview.md with an H1 title, an optional summary, and one or more checklist sections
- Write each scenario as one concrete verifiable step in operational voice — a thing to do and the observable outcome. Avoid vague items like "test the feature"
- Cite the spec id (e.g. "verifies spec: ALG") on scenarios that directly exercise an acceptance criterion. Scenarios without a citation are valid for operational concerns (smoke checks, cross-browser, manual feel)
- Ask only the clarifying questions you genuinely need — one or two turns at most, not an extended interview
See .workhorse/specs/test-cases/overview.md for the file's shape.