This skill takes the current conversation context and codebase understanding and produces a spec. Do NOT interview the user; just synthesize what you already know.

This repo tracks work in GitHub Issues. Use the gh CLI, which infers the repository from the clone.

Issue tracker: GitHub

Create the spec: gh issue create --title "<spec title>" --body-file -, with the spec body on stdin.
Ensure the triage label exists: gh label create ready-for-agent --description "Fully specified, ready for an AFK agent" --color 0E8A16 (ignore an "already exists" error).
Apply it: gh issue edit <number> --add-label ready-for-agent.

The canonical triage labels are needs-triage, needs-info, ready-for-agent, ready-for-human, and wontfix. This skill applies ready-for-agent; no additional triage is needed here.

Process

Explore the repo to understand the current state of the codebase, if you haven't already. Before exploring, read GLOSSARY.md at the repo root (or GLOSSARY-MAP.md and the per-context glossaries it points at) and the ADRs under docs/adr/ or src/*/docs/adr/ that touch the area. If they don't exist, proceed silently and don't create them. Use the project's domain glossary vocabulary throughout the spec, and surface any ADR conflict rather than silently overriding it.
Sketch out the seams at which you're going to test the feature. Existing seams should be preferred to new ones. Use the highest seam possible. If new seams are needed, propose them at the highest point you can. The fewer seams across the codebase, the better - the ideal number is one.

Check with the user that these seams match their expectations.

to-spec

Issue tracker: GitHub

Process