fix: render design sections before the approval question in brainstorming skill

[mvanhorn]

This PR targets the dev branch.

Who is submitting this PR? (required)

Field	Value
Your model + version	GPT-5.5 (Codex CLI) wrote the diff; Claude Fable 5 orchestrated planning and review
Harness + version	Claude Code CLI (current release) driving Codex CLI 0.142.x
All plugins installed	codex plugin 1.0.4
Human partner who reviewed this diff	@mvanhorn

What problem are you trying to solve?

#1731: users going through the brainstorming skill's design review reach the "Does the design above look right?" approval prompt with nothing rendered above it. The design section never appears. @trautonen traced the root cause: after a Claude Code update, assistant message text that precedes an AskUserQuestion tool call in the same turn is not rendered, so any skill that emits a design section and then immediately asks an interactive question in one turn loses the section. @dch-actaport reproduced the same failure on Junie with Sonnet 4.6, so this is not specific to one harness or model.

What does this PR change?

Adds guidance to the "Presenting the design" flow in skills/brainstorming/SKILL.md: deliver each design section as plain rendered message text in its own turn, and only then gather approval. Never combine section content with an interactive question tool call in the same turn.

Is this change appropriate for the core library?

Yes. The brainstorming skill is core, and the failure mode (pre-tool-call text swallowed by the harness) affects every user of the skill on current Claude Code, independent of project type. No third-party service is involved.

What alternatives did you consider?

• Restructuring the design-review flow to avoid AskUserQuestion entirely: rejected as a much larger behavioral change to carefully-tuned content for the same effect.
• Waiting for the harness to restore pre-tool-call rendering: the second report on Junie shows other harnesses behave the same way, so the skill's guidance is the right layer for the fix regardless of any harness change.
• A note in README/docs instead of SKILL.md: agents don't read the README mid-session; the instruction has to live where the agent's behavior is shaped.

Does this PR contain multiple unrelated changes?

No. One file, one additive instruction (+3/-1).

Existing PRs

• I have reviewed all open AND closed PRs for duplicates or prior art
• Related PRs: none found (checked open and closed PRs referencing Design Review not showing the Spec after claude update #1731 and searching "design preview", "AskUserQuestion render")

Environment tested

Harness (e.g. Claude Code, Cursor)	Harness version	Model	Model version/ID
Not session-tested (see Evaluation)	-	-	-

New harness support (required if this PR adds a new harness)

N/A - no new harness. (Transcript section omitted per template: only required when adding harness support.)

Evaluation

• Initial prompt: this change came from triaging Design Review not showing the Spec after claude update #1731 directly, not from a failing session of our own. The reproduction and root cause come from the issue thread: @trautonen's diagnosis of pre-tool-call text not rendering, confirmed by @dch-actaport on a second harness (Junie, Sonnet 4.6).
• Eval sessions after the change: 0. Being upfront about that. The change encodes the issue thread's diagnosed rendering constraint (text before an in-turn interactive tool call is not rendered on current Claude Code) as presentation guidance; we have not run before/after brainstorming eval sessions.
• Outcome change: expected, not measured - the approval question gets visible section content above it because the section is delivered as its own rendered turn. If you want N-session before/after evals before considering this, say so and we'll run them; the two independent reproductions in the thread are the evidence base today.

Rigor

• I used superpowers:writing-skills and completed adversarial pressure testing
• This change was tested adversarially, not just on the happy path - not session-tested; the edge cases were checked by analysis only (revise loop re-presents the section in its own turn each iteration; harnesses that still render pre-tool-call text read the present-then-ask pattern naturally)
• I did not modify carefully-tuned content (Red Flags table, rationalizations, "human partner" language) - the edit is additive guidance in the presentation flow only; no tuned prose was rewritten

Human review

• A human has reviewed the COMPLETE proposed diff before submission

Fixes #1731

AI was used for assistance.