Menu
Draft edits to existing specs (or a new spec if no existing one fits) from the card description
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Check whether this card's code meets the acceptance criteria
Run a quick UX/UI workshop using ASCII-art sketches
Write automated tests for unticked scenarios in this card's test cases
Review code changes on this card for likely bugs, regressions, and missed edges
Cherry-pick post-merge commits onto a new follow-up branch
Maintain a support docs pack — dedup, length budgets, and no splintering — and land changes as a reviewed pull request. Use when a support thread, or a hand-off from Support assist, surfaces a new resolution, a correction to an existing one, or a deployment quirk worth recording. Not for ordinary code changes.
| 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.2.0 |
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.
.workhorse/specs/ to understand the area structure..workhorse/specs/{area}/{slug}.md if genuinely needed.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.