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, CONTEXT.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.
• 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.

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.