to-issueslisted

# To Issues Break a plan into independently-grabbable issues using vertical slices (tracer bullets). Issues live as local markdown files — see `docs/agents/issue-tracker.md` for the file layout and `docs/agents/triage-labels.md` for valid status strings. ## Process ### 1. Gather context and determine feature slug Work from whatever is already in the conversation context. If the user passes an issue reference as an argument, it must be a local file path (e.g. `.scratch/feature/issues/01-slug.md`) or an issue number within `.scratch/`. Do NOT fetch from external URLs or remote issue trackers — only read local files. Determine the **feature slug** (the directory name under `.scratch/`): 1. If the user provided a path argument, extract the slug from it (e.g. `.scratch/auth-flow/...` → `auth-flow`). 2. Otherwise, list existing directories under `.scratch/` and check if one clearly matches the topic being discussed. 3. If no match is found, ask the user: "What feature slug should I use? (This becomes the `.scratch/<slug>/` directory name.)" Never guess the slug silently — confirm with the user if there's any ambiguity. ### 2. Check for a PRD Check whether a PRD exists at `.scratch/<feature-slug>/PRD.md`. If one exists, read it and use it as the primary source material for decomposition. If no PRD exists, ask the user: > "I don't see a PRD at `.scratch/<feature-slug>/PRD.md`. Would you like me to run `/to-prd` first to formalize the spec, or should I work from the curren