to-spec

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.

Output destination

Settle this before writing the spec. The spec always gets written somewhere; the only question is where.

First, ask whether to publish

Ask first — never assume, and never publish to a tracker the user hasn't agreed to:

Do you want this spec published to an issue tracker, or written as a local markdown file in your OS temp directory?

If they want it published, find the tracker

Look in the agent instructions you were given — AGENTS.md, CLAUDE.md, or whichever instruction files this project uses — plus any tracker configuration they point to, for a named tracker. It counts as available only if you can both name it (GitHub, Linear, Jira, …) and reach it with the tools you have.

• Available → publish the spec as an issue there. Apply whatever labelling convention the project's agent instructions document; if they document none, apply none.
• Not available → say so plainly, naming where you looked, and fall back to the local file. Don't stall on it. If the user names a tracker or points you at its configuration on the spot, use that instead, and offer to record it in the project's agent instructions so the next session doesn't have to ask.