thread-speclisted

# Write a thread's spec Read [threads.md](../wiki/references/threads.md). Tools: `threads`, `thread`, `status`. The spec says what will be true when the thread is done, and why. It is the agreement between the user and whoever does the work. It is quick to write: most of the work is reading, and the user answers only what reading cannot. ## Understand before you ask 1. Call `threads` with the `id`. Read the stub. 2. Find the answers yourself: the code the thread touches, its tests, the CLAUDE.md of the work, recent commits, and the knowledge base (the project's page, `wiki/hot.md`, a Grep for the subject). A question the code answers is not a question for the user. 3. Decide what you can decide. Where one option is right, take it and give the reason in the spec. The user reads the spec and can disagree there. ## Ask only what changes the spec A question goes to the user when the answer is theirs alone (a preference, a priority, a constraint outside the code) and a wrong guess would change what is built. There is no right number of questions: none is common, and ten are fine for a thread that needs them. Ask them together in one message, each with the answer you recommend, so the user can reply in a line. Do not ask for approval section by section. When the stub holds several independent pieces of work, say so first and offer a thread for each (`thread-stub`). Spec the one the user picks. ## What the spec holds Write for someone who has not seen this conve