brainstorming

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Brainstorming Ideas Into Designs

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

Overview

概述

Transform rough ideas into fully-formed designs through structured questioning and alternative exploration.

Core principle: Ask questions to understand, explore alternatives, present design incrementally for validation.

Announce at start: "I'm using the brainstorming skill to refine your idea into a design."

通过结构化提问和替代方案探索，将粗略想法转化为完整成熟的设计方案。

核心原则： 通过提问来理解需求、探索替代方案、分阶段呈现设计以进行验证。

开始时需告知： "我将使用头脑风暴技能把你的想法完善为设计方案。"

Quick Reference

快速参考

Phase	Key Activities	Tool Usage	Output
1. Understanding	Ask questions (one at a time)	AskUserQuestion for choices, agents for research	Purpose, constraints, criteria
2. Exploration	Propose 2-3 approaches	AskUserQuestion for approach selection, agents for patterns	Architecture options with trade-offs
3. Design Presentation	Present in 200-300 word sections	Open-ended questions	Complete design with validation

阶段	关键活动	工具使用	输出
1. 理解阶段	逐个提出问题	用AskUserQuestion提供选项，用Agent进行研究	目标、约束条件、成功标准
2. 探索阶段	提出2-3种方案	用AskUserQuestion让用户选择方案，用Agent查找模式	包含权衡的架构选项
3. 设计呈现阶段	分200-300字的段落呈现	开放式问题	经过验证的完整设计方案

The Process

流程说明

REQUIRED: Create task tracker at start

Use TaskCreate to create todos for each phase (or TodoWrite in older Claude Code versions):

Phase 1: Understanding (purpose, constraints, criteria gathered)
Phase 2: Exploration (2-3 approaches proposed and evaluated)
Phase 3: Design Presentation (design validated in sections)

Use TaskUpdate to mark each phase as in_progress when working on it, completed when finished (or TodoWrite in older versions).

强制要求：在开始时创建任务追踪器

使用TaskCreate为每个阶段创建待办事项（旧版Claude Code中可使用TodoWrite）：

阶段1：理解（收集目标、约束条件、成功标准）
阶段2：探索（提出并评估2-3种方案）
阶段3：设计呈现（分阶段验证设计）

在处理每个阶段时，使用TaskUpdate将其标记为in_progress，完成后标记为completed（旧版中可使用TodoWrite）。

Research Agents

研究Agent使用指南

DO NOT perform deep research yourself. Delegate to specialized agents.

禁止自行进行深度研究。请委托给专业Agent处理。

When to Use codebase-investigator

何时使用codebase-investigator

Use codebase-investigator when you need to:

Understand how existing features are implemented
Find where specific functionality lives in the codebase
Identify existing patterns to follow
Verify assumptions about codebase structure
Check if a feature already exists

Example delegation:

Question: "How is authentication currently implemented?"
Action: Dispatch codebase-investigator with: "Find authentication implementation, including file locations, patterns used, and dependencies"

在以下场景中使用codebase-investigator：

了解现有功能的实现方式
定位特定功能在代码库中的位置
识别可遵循的现有模式
验证关于代码库结构的假设
检查某功能是否已存在

委托示例：

Question: "How is authentication currently implemented?"
Action: Dispatch codebase-investigator with: "Find authentication implementation, including file locations, patterns used, and dependencies"

When to Use internet-researcher

何时使用internet-researcher

Use @agent-ed3d-research-agents:internet-researcher when available. Otherwise use WebSearch/WebFetch aggressively.

Use internet research when you need to:

Find current API documentation for external services
Research library capabilities and best practices
Compare technology options
Understand current community recommendations
Find code examples and patterns from documentation
Verify "what's the latest version" type questions
Look up "how do people solve X" patterns

Example delegation (with agent):

Question: "What's the recommended way to handle file uploads with this framework?"
Action: Dispatch internet-researcher with: "Find current best practices for file uploads in [framework], including official docs and common patterns"

Example without agent (use WebSearch):

Question: "What's the current Stripe API for subscriptions?"
Action: Use WebSearch for: "Stripe subscriptions API latest version 2025"
Then use WebFetch to read the official docs

When to use internet research:

External API documentation (always get latest)
"How do people solve X?" (community patterns)
Library comparison (which one is maintained?)
Best practices (what's current recommendation?)
Version checking (what's latest?)

Don't overdo it:

Don't research things Claude already knows well
Don't research project-specific code (use codebase-investigator)
Don't research for every small decision

Balance: Use research for external knowledge and current information. Use Claude's existing knowledge for general programming concepts.

若可用，请使用@agent-ed3d-research-agents:internet-researcher。否则请积极使用WebSearch/WebFetch工具。

在以下场景中使用互联网研究：

查找外部服务的最新API文档
研究库的功能和最佳实践
比较不同技术方案
了解当前社区的推荐方案
从文档中查找代码示例和模式
验证“最新版本是什么”这类问题
查找“人们如何解决X问题”的模式

带Agent的委托示例：

Question: "What's the recommended way to handle file uploads with this framework?"
Action: Dispatch internet-researcher with: "Find current best practices for file uploads in [framework], including official docs and common patterns"

无Agent时的示例（使用WebSearch）：

Question: "What's the current Stripe API for subscriptions?"
Action: Use WebSearch for: "Stripe subscriptions API latest version 2025"
Then use WebFetch to read the official docs

何时使用互联网研究：

外部API文档（务必获取最新版本）
“人们如何解决X问题？”（社区模式）
库的对比（哪个仍在维护？）
最佳实践（当前的推荐方案是什么？）
版本检查（最新版本是什么？）

请勿过度使用：

无需研究Claude已熟知的内容
无需研究项目特定代码（使用codebase-investigator）
无需为每个小决策都进行研究

平衡原则： 研究用于获取外部知识和最新信息，Claude已有的知识用于通用编程概念。

Research Protocol

研究流程规范

If codebase pattern exists:

Use codebase-investigator to find it
Unless pattern is clearly unwise, assume it's the correct approach
Design should follow existing patterns for consistency

If no codebase pattern exists:

Use internet research to find external patterns
Present 2-3 approaches from research in Phase 2
Let user choose which pattern to adopt

If agent/research can't find answer:

Redirect question to user via AskUserQuestion
Explain what was searched and not found
Present as a design decision for user to make

Be persistent with research:

If first query doesn't yield results, refine the question
Try alternative search terms or approaches
Don't give up after one attempt

若代码库中存在相关模式：

使用codebase-investigator查找该模式
除非该模式明显不合理，否则默认其为正确方案
设计应遵循现有模式以保持一致性

若代码库中无相关模式：

使用互联网研究查找外部模式
在阶段2中呈现研究得到的2-3种方案
让用户选择采用哪种模式

若Agent/研究无法找到答案：

通过AskUserQuestion将问题转交给用户
说明已搜索的内容和未找到的结果
将其作为设计决策交由用户决定

研究需坚持不懈：

若首次查询无结果，优化问题后重试
尝试使用替代搜索词或方法
不要尝试一次就放弃

Phase 1: Understanding

阶段1：理解

Before asking questions:

Investigate current state - DON'T do this yourself:
- Dispatch codebase-investigator to verify project structure
- Ask investigator to find existing architecture and patterns
- Ask investigator to identify constraints from current codebase
- Review investigator's findings before proceeding
Then gather requirements:
- Use TaskUpdate to mark Phase 1 as in_progress
- Ask ONE question at a time to refine the idea
- Use AskUserQuestion tool when you have multiple choice options
- Use agents when you need to verify technical information
- Gather: Purpose, constraints, success criteria
- Mark Phase 1 as completed when understanding is clear

Example using AskUserQuestion:

Question: "Where should the authentication data be stored?"
Options:
  - "Session storage" (clears on tab close, more secure)
  - "Local storage" (persists across sessions, more convenient)
  - "Cookies" (works with SSR, compatible with older approach)

When to delegate vs ask user:

"Where is auth implemented?" -> codebase-investigator
"What auth library should we use?" -> internet-researcher (if not in codebase)
"Do you want JWT or sessions?" -> AskUserQuestion (design decision)

Ask only useful, coherent, and effective questions: Do not ask a question when only one answer is useful, coherent, and effective. For example, in an auth system with magic links and social logins:

Example (WRONG):
What should happen when a logged-in user requests a magic link for their own email address?

1. Send new magic link (allow re-login)
   User can request magic links even when logged in. Useful for re-authentication or session refresh scenarios.
2. Return error or redirect to home
   Logged-in users can't request magic links. They must log out first. Simpler, prevents confusion.
3. Silent success (no email sent)
   Say 'check your email' but don't send anything. Prevents leaking login state but may confuse legitimate users.

In this case, only #1 is a useful, coherent, and effective option. Option #2 doesn't make any sense (magic links can be used to verify emails after a social login) and #3 is aggressively bad (lies to the user).

Example (WRONG):
How should the magic link token verification be structured?

1. Single-use token with immediate session creation
   Token is consumed on first click, session created immediately. Simple flow. User can't re-click the link. Standard pattern for passwordless auth.
2. Token valid for multiple users within TTL
   Token can be used multiple times within 15 minutes. Allows re-clicking link if session cookie is lost. More complex state management.
3. Token with idempotent verification
   First use creates session, subsequent uses within TTL return same session. Safe re-clicking, prevents double-session creation. Moderate complexity.

No reasonably secure system would do either options #2 or #3. The way this question is written obviously indicates one acceptable answer and the other two answers are trap answers. Do not suggest trap answers for human users.

If you want to ask a question where there is only one useful, coherent, and effective path, state your assumption and continue onward.

Do not ask questions just to ask them. If you have no useful, coherent, and effective questions, cease asking questions.

If starting-a-design-plan already gathered context:

Phase 1 may be very short
Focus on remaining unknowns
Don't re-ask questions already answered in clarification
Still complete Phase 1 (don't skip it)

提问前的准备：

调查当前状态 - 禁止自行操作：
- 调用codebase-investigator验证项目结构
- 让该Agent查找现有架构和模式
- 让该Agent从当前代码库中识别约束条件
- 在继续之前查看该Agent的调查结果
然后收集需求：
- 使用TaskUpdate将阶段1标记为in_progress
- 每次只提一个问题来完善想法
- 当有多个选项时，使用AskUserQuestion工具
- 当需要验证技术信息时，使用Agent
- 收集：目标、约束条件、成功标准
- 当需求清晰后，将阶段1标记为completed

使用AskUserQuestion的示例：

Question: "Where should the authentication data be stored?"
Options:
  - "Session storage" (clears on tab close, more secure)
  - "Local storage" (persists across sessions, more convenient)
  - "Cookies" (works with SSR, compatible with older approach)

何时委托Agent vs 询问用户：

“认证功能在哪里实现？” -> 交给codebase-investigator
“我们应该使用哪个认证库？” -> 交给internet-researcher（若代码库中无相关内容）
“你想要JWT还是会话？” -> 使用AskUserQuestion（设计决策）

仅提出有用、连贯且有效的问题： 当只有一个答案是有用、连贯且有效的时，请勿提出该问题。例如，在包含魔法链接和社交登录的认证系统中：

Example (WRONG):
What should happen when a logged-in user requests a magic link for their own email address?

1. Send new magic link (allow re-login)
   User can request magic links even when logged in. Useful for re-authentication or session refresh scenarios.
2. Return error or redirect to home
   Logged-in users can't request magic links. They must log out first. Simpler, prevents confusion.
3. Silent success (no email sent)
   Say 'check your email' but don't send anything. Prevents leaking login state but may confuse legitimate users.

在这种情况下，只有选项1是有用、连贯且有效的。选项2毫无意义（魔法链接可用于社交登录后的邮箱验证），选项3则非常糟糕（欺骗用户）。

Example (WRONG):
How should the magic link token verification be structured?

1. Single-use token with immediate session creation
   Token is consumed on first click, session created immediately. Simple flow. User can't re-click the link. Standard pattern for passwordless auth.
2. Token valid for multiple users within TTL</think_never_used_51bce0c785ca2f68081bfa7d91973934>
   Token can be used multiple times within 15 minutes. Allows re-clicking link if session cookie is lost. More complex state management.
3. Token with idempotent verification
   First use creates session, subsequent uses within TTL return same session. Safe re-clicking, prevents double-session creation. Moderate complexity.

任何合理安全的系统都不会选择选项2或3。这个问题的表述明显暗示只有一个可接受的答案，另外两个是陷阱选项。请勿向人类用户提出陷阱选项。

如果你想提出的问题只有一个有用、连贯且有效的解决方案，请说明你的假设并继续推进。

请勿为了提问而提问。如果你没有有用、连贯且有效的问题，就停止提问。

若starting-a-design-plan已收集相关背景信息：

阶段1可能会非常简短
专注于剩余的未知信息
请勿重复询问已在澄清阶段回答过的问题
仍需完成阶段1（请勿跳过）

Phase 2: Exploration

阶段2：探索

Before proposing approaches:

Research existing patterns - DON'T do this yourself:
- Dispatch codebase-investigator: "Find similar features and patterns used"
- If similar feature exists, base one approach on that pattern
- If no codebase pattern, use internet research: "Find recommended approaches for [problem]"
- Review research findings before proposing
Then propose approaches:
- Use TaskUpdate to mark Phase 2 as in_progress
- Propose 2-3 different approaches based on research
- At least one approach should follow codebase patterns (if they exist)
- For each: Core architecture, trade-offs, complexity assessment
- Use AskUserQuestion tool to present approaches as structured choices
- Mark Phase 2 as completed when approach is selected

Example using AskUserQuestion:

Question: "Which architectural approach should we use?"
Options:
  - "Event-driven with message queue" (matches existing notification system, scalable, complex setup)
  - "Direct API calls with retry logic" (simple, synchronous, easier to debug)
  - "Hybrid with background jobs" (balanced, moderate complexity, best of both)

Research integration:

If codebase has pattern -> Present it as primary option (unless unwise)
If no codebase pattern -> Present internet research findings
If research yields nothing -> Ask user for direction

提出方案前的准备：

研究现有模式 - 禁止自行操作：
- 调用codebase-investigator：“查找已使用的类似功能和模式”
- 若存在类似功能，基于该模式提出一种方案
- 若代码库中无相关模式，使用互联网研究：“查找针对[问题]的推荐方案”
- 在提出方案前查看研究结果
然后提出方案：
- 使用TaskUpdate将阶段2标记为in_progress
- 基于研究提出2-3种不同方案
- 至少有一种方案应遵循代码库中的模式（若存在）
- 每个方案需包含：核心架构、权衡点、复杂度评估
- 使用AskUserQuestion工具以结构化选项的形式呈现方案
- 当方案选定后，将阶段2标记为completed

使用AskUserQuestion的示例：

Question: "Which architectural approach should we use?"
Options:
  - "Event-driven with message queue" (matches existing notification system, scalable, complex setup)
  - "Direct API calls with retry logic" (simple, synchronous, easier to debug)
  - "Hybrid with background jobs" (balanced, moderate complexity, best of both)

研究整合：

若代码库中有模式 -> 将其作为首要选项呈现（除非不合理）
若代码库中无模式 -> 呈现互联网研究结果
若研究无结果 -> 询问用户的方向

Phase 3: Design Presentation

阶段3：设计呈现

Use TaskUpdate to mark Phase 3 as in_progress
Present in 200-300 word sections
Cover: Architecture, components, data flow, error handling, testing
Use research agents if you need to verify technical details during presentation
Ask after each section: "Does this look right so far?" (open-ended)
Use open-ended questions here to allow freeform feedback
Mark Phase 3 as completed when all sections validated

Level of detail: Present architecture and components, not implementation code.

Contracts/interfaces: OK. If a component exposes an API or interface that other systems depend on, show the shape (types, method signatures, request/response formats).
Implementation code: NOT OK. Function bodies, algorithms, and executable logic belong in implementation plans, not design.

The distinction: contracts define boundaries between components. Implementation defines behavior within components. Brainstorming validates the boundaries; implementation planning fills in the behavior.

Output: Validated design held in conversation context, ready for documentation.

使用TaskUpdate将阶段3标记为in_progress
以200-300字的段落为单位呈现
涵盖：架构、组件、数据流、错误处理、测试
若在呈现过程中需要验证技术细节，使用研究Agent
在每个段落结束后询问：“到目前为止，这个设计看起来合适吗？”（开放式问题）
此处使用开放式问题以获取自由形式的反馈
当所有段落都通过验证后，将阶段3标记为completed

细节程度： 呈现架构和组件，而非实现代码。

契约/接口：可以呈现。 若组件暴露了其他系统依赖的API或接口，可展示其结构（类型、方法签名、请求/响应格式）。
实现代码：禁止呈现。 函数体、算法和可执行逻辑属于实施计划，而非设计阶段的内容。

区别在于：契约定义组件之间的边界，实现定义组件内部的行为。头脑风暴用于验证边界；实施计划用于填充行为细节。

输出： 经过验证的设计方案保存在对话上下文中，可随时用于文档编写。

Question Patterns

提问模式

When to Use AskUserQuestion Tool

何时使用AskUserQuestion工具

Use AskUserQuestion for:

Phase 1: Clarifying questions with 2-4 clear options
Phase 2: Architectural approach selection (2-3 alternatives)
Any decision with distinct, mutually exclusive choices
When options have clear trade-offs to explain
When agent research yields no answer (present as open decision)

Benefits:

Structured presentation of options with descriptions
Clear trade-off visibility for partner
Forces explicit choice (prevents vague "maybe both" responses)

在以下场景中使用AskUserQuestion：

阶段1：带有2-4个明确选项的澄清问题
阶段2：架构方案选择（2-3种替代方案）
任何具有明确互斥选项的决策
当选项有明确的权衡点需要说明时
当Agent研究无结果时（作为开放式决策呈现）

优势：

带有描述的结构化选项呈现
合作方可清晰看到权衡点
促使明确选择（避免模糊的“可能两者都要”的回复）

When to Use Open-Ended Questions

何时使用开放式问题

Use open-ended questions for:

Phase 3: Design validation ("Does this look right so far?")
When you need detailed feedback or explanation
When partner should describe their own requirements
When structured options would limit creative input

Example decision flow:

"What authentication method?" -> Use AskUserQuestion (2-4 options)
"Does this design handle your use case?" -> Open-ended (validation)

在以下场景中使用开放式问题：

阶段3：设计验证（“到目前为止，这个设计看起来合适吗？”）
当你需要详细反馈或解释时
当合作方应描述自己的需求时
当结构化选项会限制创意输入时

决策流程示例：

“使用哪种认证方法？” -> 使用AskUserQuestion（2-4个选项）
“这个设计能满足你的用例吗？” -> 开放式问题（验证）

When to Use Research Agents

何时使用研究Agent

Use codebase-investigator for:

"How is X implemented?" -> Agent finds and reports
"Where does Y live?" -> Agent locates files
"What pattern exists for Z?" -> Agent identifies pattern

Use internet research for:

"What's the current API for X?" -> Research finds docs
"How do other projects solve Y?" -> Research finds patterns
"What libraries exist for Z?" -> Research compares options

Don't do deep research yourself - you'll consume context and may hallucinate. Delegate to agents or use web tools.

在以下场景中使用codebase-investigator：

“X是如何实现的？” -> Agent查找并报告
“Y位于哪里？” -> Agent定位文件
“Z有什么可用模式？” -> Agent识别模式

在以下场景中使用互联网研究：

“X的当前API是什么？” -> 研究查找文档
“其他项目如何解决Y问题？” -> 研究查找模式
“有哪些针对Z的库？” -> 研究对比选项

禁止自行进行深度研究 - 这会消耗上下文信息，且可能产生幻觉。请委托给Agent或使用网络工具。

When to Revisit Earlier Phases

何时回溯到之前的阶段

dot

digraph revisit_phases {
    rankdir=LR;
    "New constraint revealed?" [shape=diamond];
    "Partner questions approach?" [shape=diamond];
    "Requirements unclear?" [shape=diamond];
    "Return to Phase 1" [shape=box, style=filled, fillcolor="#ffcccc"];
    "Return to Phase 2" [shape=box, style=filled, fillcolor="#ffffcc"];
    "Continue forward" [shape=box, style=filled, fillcolor="#ccffcc"];

    "New constraint revealed?" -> "Return to Phase 1" [label="yes"];
    "New constraint revealed?" -> "Partner questions approach?" [label="no"];
    "Partner questions approach?" -> "Return to Phase 2" [label="yes"];
    "Partner questions approach?" -> "Requirements unclear?" [label="no"];
    "Requirements unclear?" -> "Return to Phase 1" [label="yes"];
    "Requirements unclear?" -> "Continue forward" [label="no"];
}

You can and should go backward when:

Partner reveals new constraint during Phase 2 or 3 -> Return to Phase 1
Validation shows fundamental gap in requirements -> Return to Phase 1
Partner questions approach during Phase 3 -> Return to Phase 2
Something doesn't make sense -> Go back and clarify
Agent research reveals constraint you didn't know -> Reassess phase

Don't force forward linearly when going backward would give better results.

dot

digraph revisit_phases {
    rankdir=LR;
    "New constraint revealed?" [shape=diamond];
    "Partner questions approach?" [shape=diamond];
    "Requirements unclear?" [shape=diamond];
    "Return to Phase 1" [shape=box, style=filled, fillcolor="#ffcccc"];
    "Return to Phase 2" [shape=box, style=filled, fillcolor="#ffffcc"];
    "Continue forward" [shape=box, style=filled, fillcolor="#ccffcc"];

    "New constraint revealed?" -> "Return to Phase 1" [label="yes"];
    "New constraint revealed?" -> "Partner questions approach?" [label="no"];
    "Partner questions approach?" -> "Return to Phase 2" [label="yes"];
    "Partner questions approach?" -> "Requirements unclear?" [label="no"];
    "Requirements unclear?" -> "Return to Phase 1" [label="yes"];
    "Requirements unclear?" -> "Continue forward" [label="no"];
}

在以下情况下，你可以且应该回溯到之前的阶段：

合作方在阶段2或3中透露新的约束条件 -> 回溯到阶段1
验证显示需求存在根本性缺口 -> 回溯到阶段1
合作方在阶段3中对方案提出疑问 -> 回溯到阶段2
某些内容不合理 -> 回溯并澄清
Agent研究发现了你未知的约束条件 -> 重新评估当前阶段

当回溯能得到更好的结果时，请勿强行线性推进。

Common Rationalizations - STOP

常见借口 - 停止这些行为

These are violations of the skill requirements:

Excuse	Reality
"Idea is simple, can skip exploring alternatives"	Always propose 2-3 approaches. Comparison reveals issues.
"Partner knows what they want, can skip questions"	Questions reveal hidden constraints. Always ask.
"I'll present whole design at once for efficiency"	Incremental validation catches problems early.
"Checklist is just a suggestion"	Create task todos with TaskCreate. Track progress properly.
"I can research this quickly myself"	Use agents or web tools. You'll hallucinate or consume excessive context.
"Agent didn't find it on first try, must not exist"	Be persistent. Refine query and try again.
"Partner said yes, done with brainstorming"	Design is in conversation. Next step is documentation.
"I know this codebase, don't need investigator"	You don't know current state. Always verify.
"Obvious solution, skip research"	Codebase may have established pattern. Check first.
"Don't need internet research for this"	External knowledge and current docs matter. Research when relevant.
"I'll show the implementation so partner understands"	Show contracts/interfaces, not implementation. Implementation planning generates code later.

All of these mean: STOP. Follow the requirements exactly.

以下是违反该技能要求的常见借口：

借口	实际情况
"想法很简单，可以跳过替代方案探索"	始终要提出2-3种方案。对比能发现潜在问题。
"合作方知道自己想要什么，可以跳过提问"	提问能揭示隐藏的约束条件。务必提问。
"为了效率，我会一次性呈现完整设计"	渐进式验证能尽早发现问题。
"checklist只是建议"	使用TaskCreate创建待办事项。正确跟踪进度。
"我自己可以快速完成这项研究"	使用Agent或网络工具。自行研究可能产生幻觉或消耗过多上下文信息。
"Agent第一次没找到，肯定不存在"	要坚持不懈。优化查询后重试。
"合作方已经同意，头脑风暴完成了"	设计保存在对话中。下一步是文档编写。
"我熟悉这个代码库，不需要investigator"	你并不了解当前状态。务必验证。
"解决方案很明显，跳过研究"	代码库可能已有既定模式。先检查。
"这个不需要互联网研究"	外部知识和最新文档很重要。相关时务必研究。
"我会展示实现代码以便合作方理解"	展示契约/接口，而非实现代码。实现计划阶段会生成代码。

所有这些借口都意味着：停止。严格遵循要求执行。

Key Principles

核心原则

Principle	Application
One question at a time	YOU MUST ask single questions in Phase 1, use AskUserQuestion for choices
Delegate research	YOU MUST use agents or web tools for codebase and internet research, never do it yourself
Be persistent with research	If search doesn't find answer, refine query and try again before asking user
Follow existing patterns	If codebase pattern exists and is reasonable, design must follow it
Structured choices	YOU MUST use AskUserQuestion tool for 2-4 options with trade-offs
YAGNI ruthlessly	Remove unnecessary features from all designs
Explore alternatives	YOU MUST propose 2-3 approaches before settling
Incremental validation	Present design in sections, validate each - never all at once
Task tracking	YOU MUST create task todos at start with TaskCreate, update with TaskUpdate as you progress (or TodoWrite in older versions)
Flexible progression	Go backward when needed - flexibility > rigidity
Internet research matters	Use research agents or web tools for external knowledge and current information

原则	应用要求
一次只提一个问题	在阶段1中必须逐个提问，有选项时使用AskUserQuestion
委托研究工作	必须使用Agent或网络工具进行代码库和互联网研究，禁止自行操作
研究需坚持不懈	若搜索无结果，优化查询后重试，再询问用户
遵循现有模式	若代码库中的模式存在且合理，设计必须遵循该模式
结构化选项	必须使用AskUserQuestion工具提供2-4个带有权衡点的选项
严格遵循YAGNI原则	从所有设计中移除不必要的功能
探索替代方案	在确定方案前必须提出2-3种替代方案
渐进式验证	分阶段呈现设计并逐一验证，禁止一次性全部呈现
任务追踪	开始时必须使用TaskCreate创建待办事项，推进过程中使用TaskUpdate更新（旧版用TodoWrite）
灵活推进	必要时回溯阶段 - 灵活性优于刚性
互联网研究很重要	使用研究Agent或网络工具获取外部知识和最新信息

After Brainstorming

头脑风暴完成后

When Phase 3 is complete, announce:

"Design is validated and ready for documentation."

Next step: The orchestrating skill (starting-a-design-plan) will invoke writing-design-plans to document this design.

You do NOT:

Write design document (that's writing-design-plans)
Set up worktrees (that's later in workflow)
Create implementation plans (that's writing-plans)

You DO:

Hold validated design in conversation context
Have clear understanding of architecture, components, and approach
Know which existing patterns were followed (from investigation)

当阶段3完成时，告知用户：

"Design is validated and ready for documentation."

下一步： 编排技能（starting-a-design-plan）将调用writing-design-plans来编写该设计的文档。

禁止操作：

编写设计文档（这是writing-design-plans的职责）
设置工作树（这是工作流后续阶段的内容）
制定实施计划（这是writing-plans的职责）

需要操作：

将经过验证的设计保存在对话上下文中
清晰理解架构、组件和方案
了解（通过调查）遵循了哪些现有模式",