| name | draft-spec-changes |
| description | Draft edits to existing specs (or a new spec if no existing one fits) from the card description |
| label | Draft spec changes |
| pill-order | {"not-started":3,"specifying":2} |
| jockey-hint | Demote once spec drafts have already been produced in this conversation, unless the user signals they want another pass or the scope has materially shifted. |
| workhorse-version | 0.1.0 |
Your task: Draft spec changes
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 spec edits directly from the card description — no extended interview.
Read .agents/docs/spec-format.md first. It defines the writing conventions, the information-architecture rules, and the fold-vs-create-vs-split guidance you must follow. Every edit you make has to conform to it.
- Read the card title and description carefully.
- Read existing specs in
.workhorse/specs/ to understand the area structure.
- Default to editing existing specs. Most spec work is a fold — a new section, criterion, or refinement on a spec that already covers the concept. Only create a new spec file when the content cannot plausibly live in any existing spec in the same area.
- Edit spec files in place, or write new ones at
.workhorse/specs/{area}/{slug}.md if genuinely needed.
- Include a brief summary of what you changed and any open questions you identified.
Do NOT start by asking questions or exploring the codebase. Go straight to drafting. If the description is too thin for meaningful acceptance criteria, write what you can and list the gaps as open questions.
Generate mockups for any UI-facing specs as part of the draft. Before writing mockup HTML, follow the Design sourcing process from your system prompt: read the section's actual implementation first, then similar components, then cross-check against .workhorse/design/. Do not skip this reading pass.