to-spec

This skill takes the current conversation context and codebase understanding and produces a spec. Default to synthesizing what you already know: by the time this skill runs, the deciding is usually done, so do not reopen it as an interview.

You may ask questions when you genuinely need to. The bar is a gap you cannot close from the conversation, the codebase, GLOSSARY.md, or the ADRs, and that would otherwise force you to invent a decision the user never made. When you hit that bar:

• Ask in one batch, before writing the spec, not question by question.
• Keep it to the few that actually change what the spec says.
• Carry your best guess with each one, so the user can answer by confirming.
• The seams (step 3) are one of those questions: put your proposed seams in the batch as the best guess. If nothing else clears the bar, ask one short question about the seams only.
• Then write the spec. Never stall waiting on answers you could have assumed and flagged.

If nothing clears that bar, write the spec without asking anything, except the seams: those are always confirmed, in the batch or as the one short seams-only question.

Process

1. Resolve where to publish. This one never needs a question: the chain below always lands somewhere, so pick a destination silently and carry it into step 4 rather than presenting a picker.

   1. If the user explicitly asked this run to publish to GitHub, GitLab, local markdown, or another tracker: use that.
   2. Else if docs/agents/issue-tracker.md exists (written by /setup-skills) and names a tracker: use that.
   3. Else: Local markdown (.scratch/<feature-slug>/SPEC.md). Do not probe git remote. Do not present a destination picker.