thread-speclisted

# Write a thread's spec 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. Tools: `status`, `threads`, `thread`. Reads [threads.md](../thread/references/threads.md). ## 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 AGENTS.md and CLAUDE.md of the work, recent commits, and the wiki (the page that describes the work, `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. 4. Keep the evidence straight while you decide. Separate what you **observed** (read in the code, the wiki, a test, a measurement), what you **inferred** from it (say the step), what is **unknown** (and could change the decision), and what is the user's **preference**. For a decision that is hard to reverse, write the strongest case against it before you take it. ## 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 a