to-speclisted

This skill takes the current conversation context and codebase understanding and produces a spec. Do NOT interview Kyle; 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 (`CONTEXT.md`, via `CONTEXT-MAP.md` when there's more than one), and respect any ADRs in the area you're touching. 2. Sketch out the seams at which you're going to test the feature — "seam" in the codebase-design skill's sense. 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 Kyle that these seams match his expectations. 3. Write the spec using the template below, and put it **where the repo already keeps specs** — absent a convention, `docs/specs/<slug>.md` (the same convention wayfinder's cleared maps collapse into). Commit it; a spec that isn't in git is invisible to every other session. 4. **Publish to the tracker only if Kyle wants it there** — as one issue carrying the spec body, labelled `ready-for-agent` per the triage skill's vocabulary (create the label first if the repo doesn't have it), so agents can grab it. On a **public** repo's tracker, ask before the first write: everyone watching the repo receives what lands there (the same guard as wayfinder's t