Synthesize the current conversation and codebase understanding. Do not interview the user.

Choose the artifact by accepted outcomes and delivery dependencies, regardless of how many files the work may touch. Keep the user's requested outcome and accepted constraints as the boundary; include necessary work and leave optional improvements out unless accepted or required to deliver the outcome.

Before publishing or updating an external work item, ensure the user's request or prior explicit authorization covers the artifact and destination. Tracker configuration establishes routing, not permission to publish. If authorization is missing, complete the local draft and present it with the destination for approval before making external changes. Reuse authorization that already covers the action; do not ask again.

When publication is authorized, read docs/agents/issue-tracker.md and the triage mapping, or reuse their unchanged contents from context. Use the configured tracker, work item types, and workstream mapping. If the destination, a required workstream, or required triage mapping cannot be established, prepare the local draft and ask for that missing value.

setup-snappedly-skills is a companion skill in this collection that configures repository conventions in docs/agents/*.md and AGENTS.md, and may migrate legacy domain documentation. It inspects the repository, presents proposed configuration and migrations, and writes confirmed changes. When repository-wide configuration is needed, recommend that the user run /setup-snappedly-skills; do not invoke it automatically or modify repository configuration as part of to-spec. Existing valid configuration is sufficient without running setup.

Process

Explore the repo to understand the current state of the codebase, if you haven't already. Follow docs/agents/domain.md when present for glossary and context-map paths. Otherwise use GLOSSARY-MAP.md or GLOSSARY.md, accepting legacy CONTEXT-MAP.md and CONTEXT.md layouts. Use the selected glossary's vocabulary and respect ADRs in the area you're touching.
Describe verification proportional to the work, using tdd's scope guidance. Reuse established test boundaries and prior decisions. Ask only when a new interface or unresolved behavioral contract materially changes the plan; existing seams need no confirmation round.
Choose the artifact. If the agreed work fits one executable issue, write one issue or brief with the outcome and acceptance criteria. Apply technical-writing. When tracker work is required, publish it with the configured executable work type, any required workstream field, exactly one bug or enhancement category when configured, and ready-for-agent state. When tracker work is not required, return the brief. This path is complete. For work needing a planning spec, continue to step 4.
Write the spec using the template below. Include only agreed outcomes and necessary work; keep optional improvements out. For multi-slice work, identify the first end-to-end tracer bullet and the evidence that will validate it. Apply technical-writing to the title and body, then publish it with the configured planning work item type and any required workstream field. A spec is a planning artifact, not an executable work item. Do not apply ready-for-agent to it. to-tickets applies that state to the implementation tickets it creates.