sp-brainstorming

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Brainstorming Ideas Into Designs

将头脑风暴想法转化为设计

Help turn ideas into fully formed designs and specs through natural collaborative dialogue.

Start by classifying how much process the request needs, then work through your path: understand the context, refine the idea, present a design, and get your human partner's approval.

<HARD-GATE> Do NOT invoke any implementation skill, write any code, scaffold any project, or take any implementation action until you have told your human partner what you intend and they have approved it. This applies to EVERY task on EVERY path below — the ceremony scales with the task; the approval gate never does. </HARD-GATE>

通过自然协作对话，帮助将想法转化为完整的设计和规格说明。

首先对请求所需的流程程度进行分类，然后按以下步骤推进：理解背景、完善想法、呈现设计，并获得人类合作者的批准。

<HARD-GATE> 在告知人类合作者你的计划并获得批准之前，请勿调用任何实现类Skill、编写任何代码、搭建任何项目或采取任何实现行动。这适用于以下所有路径中的每一项任务——流程的严谨程度随任务规模调整，但审批环节永远不可省略。 </HARD-GATE>

Three Paths

三种路径

Before your first question, classify the request and say the classification out loud — "this looks bounded, so I'll present a short design here rather than write a spec" — so your human partner can override it:

Spike — a feasibility question ("can we...", "is it possible...", "quick and dirty is fine") whose output is an answer, not code you keep. Present the question and what you'll try in 2-3 sentences, get a nod, then find out as cheaply as correctness allows. No design doc, no spec file. Report findings as a recommendation; anything you built stays labeled throwaway.
Bounded — a well-scoped change to code that already exists in this repo: a new flag, a small endpoint, a one-file fix. Understanding the kind of app is not enough — bounded means the flow you are changing is already here to read. If there is no existing flow to change, the task is not bounded. Ask the clarifying questions that matter, present a short design IN CHAT (a few sentences to a few short paragraphs), and STOP. Implementation starts only after your human partner says yes to that design — a bounded task's approval is as hard a gate as an architectural one. No spec file, no implementation plan document.
Architectural — new projects, new subsystems, changes that restructure how components fit together or alter interfaces others depend on. Follow the full process: questions, approaches, sectioned design, written spec, then the sp-writing-plans skill.

When in doubt between two paths, take the heavier one. The ratchet is one-way: hidden complexity discovered mid-task upgrades the path — stop, say so, and step up. Nothing downgrades mid-task.

在提出第一个问题之前，先对请求进行分类并明确告知分类结果——例如“这看起来属于有界任务，因此我会在此呈现简短设计，而非编写规格文档”——以便人类合作者可以进行调整：

Spike（探索性任务） —— 可行性问题（如“我们能否……”“是否有可能……”“快速粗略实现即可”），其输出为答案，而非需要保留的代码。用2-3句话呈现问题及你的探索计划，获得同意后，以尽可能低成本且保证正确性的方式开展探索。无需设计文档或规格文件。将结果作为建议汇报；任何搭建的内容都需标记为可丢弃。
Bounded（有界任务） —— 对当前仓库中已存在的代码进行范围明确的修改：新增一个标志位、一个小型端点、单文件修复。仅了解应用类型还不够——有界意味着你要修改的流程已存在于当前仓库中可供查阅。如果没有可修改的现有流程，则该任务不属于有界任务。提出关键的澄清问题，在聊天中呈现简短设计（几句话至几段短文字），然后停止。只有在人类合作者批准该设计后，才能开始实现——有界任务的审批门槛与架构任务一样严格。无需规格文件或实现计划文档。
Architectural（架构任务） —— 新项目、新子系统、重组组件结构或修改其他组件依赖的接口的变更。遵循完整流程：提问、制定方案、分模块设计、编写规格文档，然后调用sp-writing-plans Skill。

当对两个路径存在疑问时，选择流程更严谨的路径。任务只能升级：在任务进行中发现隐藏的复杂性时，需升级路径——停止当前工作，告知情况并切换至更高级别的路径。任务不可降级。

Anti-Pattern: "Too Simple To Need Approval"

反模式：“太简单，无需审批”

Every path ends with your human partner approving your intent before implementation. A todo list, a single-function utility, a config change — the design may be two sentences in chat, but you MUST present it and get approval. "Simple" tasks are where unexamined assumptions cause the most wasted work. What scales with simplicity is the artifact, never the approval.

所有路径都必须在获得人类合作者批准你的计划后才能开始实现。待办事项、单函数工具、配置变更——设计可能只是聊天中的两句话，但你必须呈现并获得批准。“简单”任务恰恰是未经审视的假设导致大量无效工作的重灾区。随任务简化而调整的是产出物的形式，而非审批环节。

Red Flags

警示信号

Thought	Reality
"This is too simple to need a design"	Simple means a short design, not no design. Two sentences in chat, then approval.
"I'll call it bounded and skip the spec"	Reaching for a label to skip work IS the doubt — take the heavier path.
"It's bounded and the design is obvious — I'll start while they read it"	The gate is the approval, not the design's length. Present, then stop until you hear yes.
"I understand this kind of app, so it's bounded"	Bounded measures the repo, not your familiarity. A new project has no existing flow — it is architectural.
"The spike works, so I'll keep the code"	A spike's output is an answer. Keeping the code is a new request — classify it.
"It grew, but I'm almost done — no need to re-classify"	Hidden complexity upgrades the path mid-task. Stop and say so.
"They approved the spike, so the follow-up change is approved too"	Each task gets its own classification and its own approval.

错误想法	实际情况
“这太简单了，不需要设计”	简单意味着设计简短，而非无需设计。在聊天中用两句话呈现设计，然后等待批准。
“我会将其归类为有界任务，跳过规格文档”	为了偷懒而选择分类本身就是不确定的信号——应选择流程更严谨的路径。
“这是有界任务，设计显而易见——我会在他们阅读设计的同时开始实现”	审批是必须的门槛，与设计篇幅无关。先呈现设计，然后等待明确的同意信号再开始。
“我了解这类应用，所以这是有界任务”	有界的判断依据是仓库现有内容，而非你的熟悉程度。新项目没有现有流程，属于架构任务。
“Spike任务成功了，所以我会保留代码”	Spike任务的输出是答案。保留代码属于新请求——需重新分类。
“任务范围扩大了，但我快完成了——无需重新分类”	发现隐藏复杂性时需中途升级路径。停止工作并告知情况。
“他们批准了Spike任务，所以后续变更也自动获批”	每个任务都需单独分类并获得审批。

Checklist

检查清单

Classify first, announce the path, then create a task for each item on your path and complete them in order.

Spike:

Explore project context — enough to frame the probe
Present question + probe plan — 2-3 sentences
Get approval — a nod is enough
Investigate — as cheaply as correctness allows
Report findings — a recommendation; label anything built as throwaway

Bounded:

Explore project context — check files, docs, recent commits
Ask clarifying questions — one at a time, the ones that matter
Present short design in chat — approach, files touched, testing
Get approval — STOP and wait for an explicit yes; presenting the design and starting in the same breath is skipping the gate
Implement — proceed with the normal development workflow (TDD applies); no plan document

Architectural:

Explore project context — check files, docs, recent commits
Offer the visual companion just-in-time — NOT upfront. The first time a question would genuinely be clearer shown than described, offer it then (its own message); on approval its browser tab opens for you. If no visual question ever arises, never offer it. See the Visual Companion section below.
Ask clarifying questions — one at a time, understand purpose/constraints/success criteria
Propose 2-3 approaches — with trade-offs and your recommendation
Present design — in sections scaled to their complexity, get user approval after each section

Write design doc — save to

docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md

and commit

Spec self-review — quick inline check for placeholders, contradictions, ambiguity, scope (see below)
User reviews written spec — ask user to review the spec file before proceeding
Transition to implementation — invoke sp-writing-plans skill to create implementation plan

先分类，宣布路径，然后为路径中的每个项目创建任务并按顺序完成。

Spike任务：

探索项目背景 —— 足够支撑探索性测试的背景信息
呈现问题+探索计划 —— 2-3句话
获得批准 —— 点头同意即可
开展探索 —— 以尽可能低成本且保证正确性的方式进行
汇报结果 —— 提出建议；将搭建的任何内容标记为可丢弃

Bounded任务：

探索项目背景 —— 查看文件、文档、近期提交记录
提出澄清问题 —— 一次一个问题，只提关键问题
在聊天中呈现简短设计 —— 实现方案、涉及文件、测试计划
获得批准 —— 停止工作，等待明确的同意信号；不能在呈现设计的同时立即开始实现，这是跳过审批门槛的行为
实现 —— 遵循常规开发流程（测试驱动开发TDD适用）；无需计划文档

Architectural任务：

探索项目背景 —— 查看文件、文档、近期提交记录
适时提供可视化辅助工具 —— 不要提前提供。当某个问题通过展示比描述更清晰时，再主动提供（单独发消息）；获得批准后，会为你打开浏览器标签页。如果没有需要可视化的问题，则永远无需提供。详见下方“可视化辅助工具”部分。
提出澄清问题 —— 一次一个问题，理解目标、约束条件、成功标准
提出2-3种方案 —— 说明各方案的权衡及你的推荐理由
呈现设计 —— 根据复杂度分模块呈现，每个模块获得用户批准后再推进下一个

编写设计文档 —— 保存至

docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md

并提交至git

规格文档自我审查 —— 快速内联检查占位符、矛盾点、歧义、范围（详见下方）
用户审核书面规格文档 —— 请用户在推进前审核规格文件
过渡到实现阶段 —— 调用sp-writing-plans Skill创建实现计划

Process Flow

流程示意图

dot

digraph brainstorming {
    "Classify: spike / bounded / architectural" [shape=diamond];
    "Present question + probe (2-3 sentences)" [shape=box];
    "Ask clarifying questions (bounded)" [shape=box];
    "Present short design in chat" [shape=box];
    "Human approves?" [shape=diamond];
    "Investigate; report recommendation" [shape=doublecircle];
    "Implement via normal workflow (no plan doc)" [shape=doublecircle];
    "Explore project context" [shape=box];
    "Ask clarifying questions" [shape=box];
    "Propose 2-3 approaches" [shape=box];
    "Present design sections" [shape=box];
    "User approves design?" [shape=diamond];
    "Write design doc" [shape=box];
    "Spec self-review\n(fix inline)" [shape=box];
    "User reviews spec?" [shape=diamond];
    "Invoke sp-writing-plans skill" [shape=doublecircle];
    "Hidden complexity? Upgrade path" [shape=box];

    "Classify: spike / bounded / architectural" -> "Present question + probe (2-3 sentences)" [label="spike"];
    "Classify: spike / bounded / architectural" -> "Ask clarifying questions (bounded)" [label="bounded"];
    "Classify: spike / bounded / architectural" -> "Explore project context" [label="architectural"];
    "Present question + probe (2-3 sentences)" -> "Human approves?";
    "Ask clarifying questions (bounded)" -> "Present short design in chat";
    "Present short design in chat" -> "Human approves?";
    "Human approves?" -> "Investigate; report recommendation" [label="spike: yes"];
    "Human approves?" -> "Implement via normal workflow (no plan doc)" [label="bounded: yes"];
    "Hidden complexity? Upgrade path" -> "Classify: spike / bounded / architectural";
    "Explore project context" -> "Ask clarifying questions";
    "Ask clarifying questions" -> "Propose 2-3 approaches";
    "Propose 2-3 approaches" -> "Present design sections";
    "Present design sections" -> "User approves design?";
    "User approves design?" -> "Present design sections" [label="no, revise"];
    "User approves design?" -> "Write design doc" [label="yes"];
    "Write design doc" -> "Spec self-review\n(fix inline)";
    "Spec self-review\n(fix inline)" -> "User reviews spec?";
    "User reviews spec?" -> "Write design doc" [label="changes requested"];
    "User reviews spec?" -> "Invoke sp-writing-plans skill" [label="approved"];
}

Terminal states are path-bound. Architectural: the ONLY skill you invoke after brainstorming is sp-writing-plans — never frontend-design, mcp-builder, or any other implementation skill. Bounded: after approval, implementation proceeds directly through the normal development workflow; no plan document. Spike: the terminal state is a reported recommendation.

dot

digraph brainstorming {
    "Classify: spike / bounded / architectural" [shape=diamond];
    "Present question + probe (2-3 sentences)" [shape=box];
    "Ask clarifying questions (bounded)" [shape=box];
    "Present short design in chat" [shape=box];
    "Human approves?" [shape=diamond];
    "Investigate; report recommendation" [shape=doublecircle];
    "Implement via normal workflow (no plan doc)" [shape=doublecircle];
    "Explore project context" [shape=box];
    "Ask clarifying questions" [shape=box];
    "Propose 2-3 approaches" [shape=box];
    "Present design sections" [shape=box];
    "User approves design?" [shape=diamond];
    "Write design doc" [shape=box];
    "Spec self-review\n(fix inline)" [shape=box];
    "User reviews spec?" [shape=diamond];
    "Invoke sp-writing-plans skill" [shape=doublecircle];
    "Hidden complexity? Upgrade path" [shape=box];

    "Classify: spike / bounded / architectural" -> "Present question + probe (2-3 sentences)" [label="spike"];
    "Classify: spike / bounded / architectural" -> "Ask clarifying questions (bounded)" [label="bounded"];
    "Classify: spike / bounded / architectural" -> "Explore project context" [label="architectural"];
    "Present question + probe (2-3 sentences)" -> "Human approves?";
    "Ask clarifying questions (bounded)" -> "Present short design in chat";
    "Present short design in chat" -> "Human approves?";
    "Human approves?" -> "Investigate; report recommendation" [label="spike: yes"];
    "Human approves?" -> "Implement via normal workflow (no plan doc)" [label="bounded: yes"];
    "Hidden complexity? Upgrade path" -> "Classify: spike / bounded / architectural";
    "Explore project context" -> "Ask clarifying questions";
    "Ask clarifying questions" -> "Propose 2-3 approaches";
    "Propose 2-3 approaches" -> "Present design sections";
    "Present design sections" -> "User approves design?";
    "User approves design?" -> "Present design sections" [label="no, revise"];
    "User approves design?" -> "Write design doc" [label="yes"];
    "Write design doc" -> "Spec self-review\n(fix inline)";
    "Spec self-review\n(fix inline)" -> "User reviews spec?";
    "User reviews spec?" -> "Write design doc" [label="changes requested"];
    "User reviews spec?" -> "Invoke sp-writing-plans skill" [label="approved"];
}

终端状态与路径绑定。架构任务：头脑风暴后唯一可调用的Skill是sp-writing-plans——绝不能调用frontend-design、mcp-builder或其他任何实现类Skill。有界任务：获得批准后，直接通过常规开发流程实现；无需计划文档。Spike任务：终端状态是提交建议报告。

The Process

详细流程

The subsections below serve the bounded and architectural paths (a spike stops at "present the probe, get a nod"). Sections from Exploring approaches onward are architectural-path depth — for bounded work, context plus a few questions plus a short in-chat design is the whole process.

Understanding the idea:

Check out the current project state first (files, docs, recent commits)
Before asking detailed questions, assess scope: if the request describes multiple independent subsystems (e.g., "build a platform with chat, file storage, billing, and analytics"), flag this immediately. Don't spend questions refining details of a project that needs to be decomposed first.
If the project is too large for a single spec, help the user decompose into sub-projects: what are the independent pieces, how do they relate, what order should they be built? Then brainstorm the first sub-project through the normal design flow. Each sub-project gets its own spec → plan → implementation cycle.
For appropriately-scoped projects, ask questions one at a time to refine the idea
Prefer multiple choice questions when possible, but open-ended is fine too
Only one question per message - if a topic needs more exploration, break it into multiple questions
Focus on understanding: purpose, constraints, success criteria

Exploring approaches:

Propose 2-3 different approaches with trade-offs
Present options conversationally with your recommendation and reasoning
Lead with your recommended option and explain why
YAGNI ruthlessly - remove unnecessary features from every approach and design

Presenting the design:

Once you believe you understand what you're building, present the design
Scale each section to its complexity: a few sentences if straightforward, up to 200-300 words if nuanced
Ask after each section whether it looks right so far
Cover: architecture, components, data flow, error handling, testing
Be ready to go back and clarify if something doesn't make sense

Design for isolation and clarity:

Break the system into smaller units that each have one clear purpose, communicate through well-defined interfaces, and can be understood and tested independently
For each unit, you should be able to answer: what does it do, how do you use it, and what does it depend on?
Can someone understand what a unit does without reading its internals? Can you change the internals without breaking consumers? If not, the boundaries need work.
Smaller, well-bounded units are also easier for you to work with - you reason better about code you can hold in context at once, and your edits are more reliable when files are focused. When a file grows large, that's often a signal that it's doing too much.

Working in existing codebases:

Explore the current structure before proposing changes. Follow existing patterns.
Where existing code has problems that affect the work (e.g., a file that's grown too large, unclear boundaries, tangled responsibilities), include targeted improvements as part of the design - the way a good developer improves code they're working in.
Don't propose unrelated refactoring. Stay focused on what serves the current goal.

以下小节适用于有界任务和架构任务（Spike任务在“呈现探索计划并获得同意”后即结束）。从探索方案开始的小节属于架构任务的深度流程——对于有界任务，仅需了解背景、提出几个问题并在聊天中呈现简短设计即可完成全部流程。

理解想法：

首先查看当前项目状态（文件、文档、近期提交记录）
在提出详细问题前，评估范围：如果请求描述了多个独立子系统（例如“构建一个包含聊天、文件存储、计费和分析功能的平台”），需立即指出。不要花费时间细化一个需要先分解的项目的细节。
如果项目规模过大，无法用单个规格文档涵盖，帮助用户分解为子项目：独立模块有哪些、它们的关系是什么、构建顺序如何？然后通过常规设计流程对第一个子项目进行头脑风暴。每个子项目都需遵循自己的“规格文档→计划→实现”周期。
对于范围合适的项目，一次提出一个问题来完善想法
尽可能使用选择题，但开放式问题也可
每条消息仅包含一个问题——如果某个主题需要深入探索，拆分为多个问题
重点理解：目标、约束条件、成功标准

探索方案：

提出2-3种不同方案，并说明各方案的权衡
以对话形式呈现选项，并给出你的推荐及理由
首先介绍你推荐的选项并解释原因
严格遵循YAGNI原则（You Aren't Gonna Need It，无需则不做）——从每个方案和设计中移除不必要的功能

呈现设计：

当你认为已理解要构建的内容时，呈现设计
根据复杂度调整每个模块的篇幅：简单内容用几句话，复杂内容最多200-300字
每个模块呈现后询问用户是否符合预期
涵盖：架构、组件、数据流、错误处理、测试
随时准备回退并澄清疑问

设计需注重隔离性与清晰性：

将系统拆分为多个更小的单元，每个单元有明确的单一目标，通过定义清晰的接口进行通信，且可独立理解和测试
对于每个单元，你应能回答：它的功能是什么、如何使用它、它依赖什么？
是否无需阅读内部实现就能理解单元的功能？修改内部实现是否不会影响使用者？如果不能，说明边界设计需要优化。
更小、边界清晰的单元也更便于你处理——你能更好地把控上下文内的代码，且当文件聚焦时，你的编辑更可靠。当文件变得过大时，通常意味着它承担了过多职责。

在现有代码库中工作：

在提出变更前，先探索当前结构。遵循现有模式。
如果现有代码存在影响工作的问题（例如文件过大、边界模糊、职责混乱），将针对性改进纳入设计——这是优秀开发者在工作中优化代码的方式。
不要提出无关的重构请求。专注于服务当前目标。

After the Design (architectural path)

设计完成后（架构任务）

Documentation:

Write the validated design (spec) to
```
docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md
```
- (User preferences for spec location override this default)
Use elements-of-style:writing-clearly-and-concisely skill if available
Commit the design document to git

Spec Self-Review: After writing the spec document, look at it with fresh eyes:

Placeholder scan: Any "TBD", "TODO", incomplete sections, or vague requirements? Fix them.
Internal consistency: Do any sections contradict each other? Does the architecture match the feature descriptions?
Scope check: Is this focused enough for a single implementation plan, or does it need decomposition?
Ambiguity check: Could any requirement be interpreted two different ways? If so, pick one and make it explicit.

Fix any issues inline. No need to re-review — just fix and move on.

User Review Gate: After the spec review loop passes, ask the user to review the written spec before proceeding:

"Spec written and committed to
<path>
. Please review it and let me know if you want to make any changes before we start writing out the implementation plan."

Wait for the user's response. If they request changes, make them and re-run the spec review loop. Only proceed once the user approves.

Implementation:

Invoke the sp-writing-plans skill to create a detailed implementation plan
Do NOT invoke any other skill. sp-writing-plans is the next step.

文档编写：

将经过验证的设计（规格文档）写入
```
docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md
```
- （用户对规格文档位置的偏好优先于默认路径）
如果可用，调用elements-of-style:writing-clearly-and-concisely Skill
将设计文档提交至git

规格文档自我审查：

编写完规格文档后，重新审视：

占位符检查： 是否存在“TBD”“TODO”、未完成章节或模糊需求？修复这些问题。
内部一致性检查： 是否存在章节矛盾？架构是否与功能描述匹配？
范围检查： 内容是否足够聚焦，可纳入单个实现计划，还是需要分解？
歧义检查： 是否有需求可被两种不同方式解读？如果有，选择一种并明确说明。

直接在文档中修复问题。无需重新审查——修复后即可推进。

用户审核门槛：

完成规格文档审查循环后，请用户在推进前审核书面规格文档：

"规格文档已编写并提交至
<path>
。请审核文档，告知我们是否需要在开始编写实现计划前进行修改。"

等待用户回复。如果用户要求修改，进行修改并重新运行规格文档审查循环。只有在用户批准后才能继续。

实现阶段：

调用sp-writing-plans Skill创建详细实现计划
请勿调用任何其他Skill。sp-writing-plans是唯一的下一步。

Visual Companion

可视化辅助工具

A browser-based companion for showing mockups, diagrams, and visual options during brainstorming. Available as a tool — not a mode. Accepting the companion means it's available for questions that benefit from visual treatment; it does NOT mean every question goes through the browser.

Offering the companion (just-in-time): Do NOT offer it upfront. Wait until a question would genuinely be clearer shown than told — a real mockup / layout / diagram question, not merely a UI topic. The first time that happens, offer it then, as its own message:

"This next part might be easier if I show you — I can put together mockups, diagrams, and comparisons in a browser tab as we go. It's still new and can be token-intensive. Want me to? I'll open it for you."

This offer MUST be its own message. Only the offer — no clarifying question, summary, or other content. Wait for the user's response. If they accept, start the server with

--open

so their browser opens to the first screen automatically. If they decline, continue text-only and don't offer again unless they raise it.

Per-question decision: Even after the user accepts, decide FOR EACH QUESTION whether to use the browser or the terminal. The test: would the user understand this better by seeing it than reading it?

Use the browser for content that IS visual — mockups, wireframes, layout comparisons, architecture diagrams, side-by-side visual designs
Use the terminal for content that is text — requirements questions, conceptual choices, tradeoff lists, A/B/C/D text options, scope decisions

A question about a UI topic is not automatically a visual question. "What does personality mean in this context?" is a conceptual question — use the terminal. "Which wizard layout works better?" is a visual question — use the browser.

If they agree to the companion, read the detailed guide before proceeding:

visual-companion.md

基于浏览器的辅助工具，用于在头脑风暴期间展示原型、图表和视觉选项。作为工具提供——而非默认模式。接受辅助工具意味着可用于需要可视化的问题；不意味着每个问题都要通过浏览器处理。

适时提供辅助工具： 请勿提前提供。等待某个问题确实通过展示比描述更清晰时——真正需要原型/布局/图表的问题，而非仅仅是UI主题。首次出现这种情况时，单独发消息提出：

"接下来这部分可能通过展示更易理解——我可以在浏览器标签页中为你制作原型、图表和对比内容。这是新工具，会消耗较多token。需要我开启吗？我会为你打开它。"

此请求必须单独发送一条消息。仅包含请求——无需澄清问题、总结或其他内容。等待用户回复。如果用户同意，使用

--open

启动服务器，自动在浏览器中打开初始界面。如果用户拒绝，继续使用文本沟通，除非用户主动提出，否则不再提供。

逐个问题决策： 即使用户同意使用辅助工具，也需为每个问题决定使用浏览器还是终端。判断标准：用户通过查看是否比阅读更容易理解？

使用浏览器处理可视化内容——原型、线框图、布局对比、架构图、并列视觉设计
使用终端处理文本内容——需求问题、概念选择、权衡列表、A/B/C/D文本选项、范围决策

UI主题的问题并非自动属于可视化问题。“此语境中的个性指什么？”是概念问题——使用终端。“哪种向导布局更好？”是可视化问题——使用浏览器。

如果用户同意使用辅助工具，请在推进前阅读详细指南：

visual-companion.md