thinklisted

# /think - Design Exploration Subject 2+ approaches to `critic-design` critique, and let only the surviving approach reach the structured plan. Write the plan to a draft file following the templates/plan.md skeleton and also return it in conversation. Persistence happens when `/issue` transfers it into the issue's Plan section. ## Input `$ARGUMENTS` carries the task description and research context. If empty, confirm with the user via AskUserQuestion. The first line is the task title. ## Phase 1: Establish the Why Read `.claude/OUTCOME.md`. If it does not exist, generate it via `/outcome`. The Why is three things, plus a fourth when the task is a Bug: who is having trouble and with what, what counts as success, why now, and for a Bug what the root cause is. Attach evidence to the trouble. Identify the root cause together with evidence such as reproduction steps or logs; when the cause is undetermined, do not proceed to design and route to `/research` instead. When the report that comes back carries a `Hypotheses Log` section, read it as the evidence for the cause. Design starts only once this Why is readable from $ARGUMENTS and the conversation. Do not proceed on placeholders; pin it down via AskUserQuestion. ## Phase 2: Design Exploration Ground the approaches in the real code and existing research before making them. Steps 1 through 4 finish with no approach yet in existence. 1. Read the relevant code. When the task, the issue, or a research report cites a mock imag