spec-to-issueslisted

# Spec to issues ## When to use - A spec or roadmap item is APPROVED and someone asks to turn it into work. - You are handed a design doc and told to "make issues out of this". - A feature touches more than one repo and needs to be split so each issue is single-repo and independently mergeable. - Before any implementation firing runs: a good issue is what makes an autonomous run land cleanly instead of sprawling. Do NOT use this to invent scope. If the spec is a draft or the goal is unclear, stop and say so. Issues derived from a fuzzy spec produce fuzzy PRs. ## Procedure 1. Read the spec. Confirm it has the minimal shape (goal, current behavior, target behavior, acceptance criteria, out-of-scope). If it does not, see `references/spec-shape.md` and ask for the missing pieces before scoping. 2. Identify the repos the spec touches. One issue per repo. If a single repo's work is large, split it along a seam a reviewer can verify independently (an endpoint, a screen, a migration), never along "part 1 / part 2" of the same file. 3. Order the issues by dependency. If `your-backend` must ship an endpoint before `your-frontend` can call it, say so in each issue's first line ("Depends on: your-backend #NN") so the fleet does not start the dependent work early. 4. For each issue write: - A one-line title in the form `feat(<area>): <verb> <thing>`. - A short context paragraph: what the spec wants and why this slice exists. - Acceptance criteria