headworklisted

# headwork Take the one decision blocking the work in hand and put it to the user as one question they answer by **choosing**, not by composing. Name a recommendation and say what would overturn it, so disagreeing means checking a condition, not overruling a machine. ## When not to use - **Designing a new thing** - `superpowers:brainstorming`. - **Stress-testing a whole plan** - grill-me, from [`mattpocock/skills`](https://github.com/mattpocock/skills). - **An independent model's view** - `groupwork`. - **Which issue comes next** - `deskwork`. - **A stalled Trello board** - `life-manager`. - **A failing problem rather than a choice** - `superpowers:systematic-debugging` or `paseo-committee`. ## Never ask what you can find out Before every question, look: the session first, then whatever the decision touches - `git log`, the file, open issues, the register, the tests. Say in one line what you checked and what it settled; that line is the proof you looked. A question a file could have answered is a bug. ## A round, exactly 1. **Look.** 2. **Say what you checked**, in one line. 3. **Explain** in two to four short numbered points: just enough that the options mean something. 4. **Ask one question**, in the form for your tools. 5. **Stop and wait.** No second question in the same message, no closing "and also", no "let me know if you'd like me to...". 6. **Carry out the chosen option as normal work, before any next round.** Start a new round only if another dec