Brainstorming

When a request is a goal ("add superpowers", "make scrolling feel right"),
building immediately produces the wrong thing fast. First make the intent
concrete.

What to pin down

• The real outcome. What should be TRUE after this that is not true now?
  Not the feature name — the result the operator wants to see.
• The acceptance check. How will the operator know it works? "I open X
  and Y happens." If neither of you can state this, the task is not ready.
• Scope edges. What is explicitly NOT part of this (the operator often
  has an opinion, e.g. "no button", "don't touch the existing code").
• The alternatives you considered and why you chose one — a decision is
  cheaper to correct before it is built.

The zames constraint (IMPORTANT)

zames has NO conversational turn: the operator sees only your final respond
and your tool calls, and a task is expected to make PROGRESS, not to ask
questions and wait. So do the brainstorming yourself and return it as a
SHORT, concrete proposal in ONE respond, instead of an interview:

• state the goal as you understood it;
• state your assumptions and the choices you made by default;
• state what you will NOT do;
• then either (a) proceed if the request was clearly actionable, or (b) stop
  and ask the ONE decision you genuinely cannot make alone.

For a request that is already precise ("read file X", "rename Y"), skip this
entirely — brainstorming a one-line task wastes the operator's time.