This skill takes the current conversation context and codebase understanding and produces a spec (you may know this document as a PRD). Do NOT interview the user — just synthesize what you already know.

The issue tracker and triage label vocabulary should have been provided to you — run /setup-agent-skills if not. Setup defaults to existing Beads state, then local .scratch; it never chooses a hosted tracker from the Git remote without the user's explicit approval.

Process

Explore the repo to understand the current state of the codebase, if you haven't already. Use the project's domain glossary vocabulary throughout the spec, and respect any ADRs in the area you're touching.
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.

Write the spec using the template below, then publish it to the project issue tracker. Resolve triage-role strings through docs/agents/triage-labels.md; never assume the literal default label names.

For the normal multi-session flow (/to-spec → /to-issues), publish the spec as a non-executable coordination parent: do not apply either mapped ready label, and use the tracker's parent/epic convention where available. /to-issues will publish the executable children. Only apply the mapped ready-for-agent or ready-for-human label when the user explicitly wants the whole spec implemented as one issue.

For the default local .scratch tracker, write the spec to .scratch/<feature-slug>/spec.md and prepend the required structured frontmatter from the tracker doc: id equal to that repo-relative path, the spec title, status: open, and type: spec. Every child created by /to-issues will use that id as its parent.