speclisted

Produce a spec (you may know this document as a PRD) from the current conversation and codebase understanding. Synthesize what you already know — the interview, if any, already happened (`/grill-me`). ## Process 1. Explore the repo to understand the current state of the codebase, if you haven't already. Use the project's domain vocabulary throughout the spec. 2. Search `docs/solutions/` and existing `docs/specs/` for learnings that bear on this feature — root causes, gotchas, approaches that failed before, decisions already made. Fold whatever applies into the spec's decisions. 3. Propose the **test seams** — the places `/implement` will drive TDD (seam vocabulary: the `codebase-design` skill). Prefer existing seams to new ones; place any new seam at the highest point you can. The fewer seams across the codebase, the better — the ideal number is one. Check the seams with the user before writing the spec: approving them now, while the decisions are fresh, lets implementation test at them later without relitigating the design. 4. Write the spec to `docs/specs/<feature>.md` (kebab-case feature slug) using the template below. <spec-template> ## Problem Statement The problem that the user is facing, from the user's perspective. ## Solution The solution to the problem, from the user's perspective. ## User Stories A LONG, numbered list of user stories. Each user story should be in the format of: 1. As an <actor>, I want a <feature>, so that <benefit> <u