to-spec

Synthesize a spec (PRD) from what you already know — do not interview. Then validate it once. Do not run /to-tickets or implement unless the user asks in the same turn.

Default tracker: local markdown under work/. If docs/agents/issue-tracker.md exists, follow it. Run /setup-work only when the tracker is not local work/ (or you need to switch / record a non-default tracker).

User clarifications (Cursor)

When you need a discrete decision with a small set of clear options (about 2–6), prefer the AskQuestion tool so the user gets structured choices. Ask one decision at a time when this skill already sequences questions that way.

If AskQuestion is unavailable in the current environment, ask the same choices in ordinary chat (same options, same ordering).

Use plain chat (not forced multiple-choice) when the answer is inherently free-form—for example pasted logs, a paragraph describing a custom tracker workflow, or an open-ended design explanation.

Process

1. Explore the repo if you haven't already. Use the project's domain glossary; respect ADRs in the area you're touching. Done when: you can write the spec in glossary vocabulary without inventing modules you haven't seen.

2. Sketch test seams — prefer existing, highest seam; fewer is better (ideal: one). Check with the user that seams match expectations. Done when: user has confirmed the seams (or accepted the default).