spec-interviewlisted

# Skill: Spec Interview ## Purpose Interview the user in depth about what they want to build, then produce a complete specification in the project's specs directory: **one spec per file**, never a single overwritten `SPEC.md`. ## Location and naming 1. Read `flux-config.yml` at the project root: `specs.dir` gives the directory (default: `specs/`). Create it if missing. 2. Determine the `<ref>`: - if the spec starts from an existing GitHub issue → its number: `SPEC-42.md`; - otherwise → a short, stable kebab slug: `SPEC-candidate-pipeline.md`. The ref never changes once the file exists (even if an issue is opened later; it is then recorded in the frontmatter instead). 3. If a file already exists for this ref, update it rather than creating a second one. ## Phase 1: Interview Use `AskUserQuestion`. Dig into the hard parts: - **Implementation**: stack, data model, APIs, integrations, constraints - **UI/UX**: flows, states, edge cases in the interface - **Business rules**: the exact rules, who decides, what changes them - **Edge cases**: what happens when X is missing, null, concurrent, invalid - **Tradeoffs**: performance vs simplicity, flexibility vs consistency, now vs later - **Concerns**: what worries the user, what is uncertain Do not ask obvious questions. Go straight to the points the user has probably not considered. 3 to 6 rounds of questions, grouped by theme (max 4 questions per call). Stop when: implementation could start without further cl