speclisted

Produce a spec from the current conversation and codebase understanding. Synthesize what you already know — the interview, if any, already happened (`/grilling`). ## 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. Read the repo's decision memory: the `AGENTS.md` conventions already in context, plus the records bearing on this feature from whichever knowledge stores the loop config enables — ADRs for decisions already made, solutions for gotchas and approaches that failed before. The loop config translates the storage verbs: it is `docs/agents/cantrips-loop.md`, and when that doc is absent the plugin defaults ([defaults.md](../setup-cantrips-loop/defaults.md)) govern. Fold whatever applies into the spec's decisions. When this feature's decisions conflict with a standing ADR — one whose status is `accepted` — flag the conflict explicitly in the spec — name the ADR and the revised decision — and note that the revision routes through `/compound` at loop end; `/compound` is the ADR store's sole writer, so the standing record stays as written until then. 3. Propose the **test seams** — the places `/implement` will drive TDD (seam vocabulary: `/codebase-design`). 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 with the user that these seams ma