to-speclisted

This skill takes the current conversation context and codebase understanding and produces a spec (you may know this document as a PRD). Do NOT interview the user, just synthesize what you already know. ## Process 1. Explore the repo to understand the current state of the codebase, if you haven't already. Use the project's domain glossary vocabulary throughout the spec, and respect any ADRs in the area you're touching. 2. Sketch out the seams at which you're going to test the feature. Existing seams should be preferred to new ones. Use the highest seam possible. If new seams are needed, propose them at the highest point you can. The fewer seams across the codebase, the better - the ideal number is one. Check with the user that these seams match their expectations. 3. Audit the technical decisions the feature depends on: what handles each solved problem (auth, validation, jobs, …), where the code lives, what schema/API contracts change. Decisions already settled in the conversation go into the spec as-is. For any that were never settled, check the project's existing dependencies and stack conventions — usually those already cover it and no new dependency is needed; record what will be used. Only when nothing in the project covers a genuinely solved problem, pick the idiomatic candidate for the stack and confirm it with the user alongside the seams. Either way, don't leave the choice implicit in the spec. 4. Write the spec using the template below, then save it per the `ai