Back to Details

brainstorming

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Brainstorming Ideas Into Designs

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

Overview

概述

Help turn ideas into fully formed designs and specs through natural collaborative dialogue.
Start by understanding the current project context, then ask questions one at a time to refine the idea. Once you understand what you're building, present the design in small sections (200-300 words), checking after each section whether it looks right so far.
通过自然的协作对话，帮助将想法转化为完整的设计和规格说明。
首先了解当前项目背景，然后一次提出一个问题来细化想法。当你明确要构建的内容后，分小部分（200-300字）呈现设计，每部分后确认目前的内容是否正确。

When to Activate

激活时机

Activate this skill when:
  • User has a rough idea that needs refinement
  • User is uncertain about scope or approach
  • User says "I'm not sure what we need" or "I'm not sure how to approach this"
  • During Phase 2 (Requirements) to explore WHAT to build
  • During Phase 3 (Technical Design) to explore HOW to build it
Phase 2 Focus (Requirements):
  • Clarifying what the feature should do
  • Exploring different requirement scopes
  • Understanding user needs and constraints
  • Determining must-haves vs. nice-to-haves
Phase 3 Focus (Design):
  • Exploring architectural approaches
  • Comparing technical solutions
  • Analyzing implementation trade-offs
当以下情况时激活此技能：
  • 用户有需要细化的初步想法
  • 用户对范围或实现方式不确定
  • 用户表示“我不确定我们需要什么”或“我不知道该如何着手”
  • 在阶段2（需求阶段）探索要构建什么
  • 在阶段3（技术设计阶段）探索如何构建
阶段2（需求阶段）重点：
  • 明确功能应实现的内容
  • 探索不同的需求范围
  • 了解用户需求和约束条件
  • 确定必备功能与可选功能
阶段3（设计阶段）重点：
  • 探索架构实现方式
  • 比较技术解决方案
  • 分析实现的权衡取舍

Research-Driven Exploration

基于研究的探索

When exploring unclear requirements or designs, use web research to inform decisions:
For Requirements Exploration:
  • Use WebSearch to find how others have solved similar problems
  • Use WebFetch to analyze competitor features and documentation
  • Research user expectations and industry standards
For Design Exploration:
  • Use WebSearch to find architectural patterns and best practices
  • Use WebFetch to read library/framework documentation
  • Research performance benchmarks and case studies
For API Integration:
  • Use Bash with 
    curl
    to explore and test API endpoints
  • Fetch API schemas and documentation
  • Understand rate limits, authentication, and constraints
Research Questions to Answer:
  • "How do similar products handle this?"
  • "What are common pitfalls to avoid?"
  • "What's the current best practice (2025)?"
  • "Are there established patterns for this problem?"
🗣 Say: "Let me research this before proposing options. I'll look for prior art and best practices."
Document Research:
  • Share key findings with user before presenting options
  • Include sources for transparency
  • Note any conflicting approaches found
当探索不明确的需求或设计时，使用网络研究为决策提供依据：
需求探索时：
  • 使用WebSearch查找他人如何解决类似问题
  • 使用WebFetch分析竞品功能和文档
  • 研究用户期望和行业标准
设计探索时：
  • 使用WebSearch查找架构模式和最佳实践
  • 使用WebFetch阅读库/框架文档
  • 研究性能基准和案例研究
API集成时：
  • 使用Bash和
    curl
    探索并测试API端点
  • 获取API架构和文档
  • 了解速率限制、认证机制和约束条件
需要研究的问题：
  • “类似产品是如何处理这个问题的？”
  • “有哪些常见的陷阱需要避免？”
  • “当前（2025年）的最佳实践是什么？”
  • “是否有针对该问题的成熟模式？”
🗣 可以说：“在提出方案前我先研究一下。我会查找相关先例和最佳实践。”
记录研究内容：
  • 在提出方案前与用户分享关键发现
  • 包含来源以保证透明度
  • 记录发现的不同观点或冲突的实现方式

The Process

流程步骤

Understanding the idea:
  • Check out the current project state first (files, docs, recent commits)
  • 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
When to UltraThink: Before proposing architectural approaches, activate deep thinking if:
  • Multiple valid solutions exist with significant trade-offs
  • Decision has long-term architectural implications
  • Requirements involve complex system interactions
  • Security or performance are critical concerns
🗣 Say: "Let me ultrathink this before proposing approaches. I'll question fundamentals and consider implications from first principles."
During UltraThink:
  • Question assumptions about requirements
  • Consider second-order effects of each approach
  • Think about what could go wrong (pre-mortem)
  • Evaluate against similar systems you've seen
  • Consider future maintainability and evolution
After UltraThink: Provide approaches with clear reasoning about trade-offs and long-term implications.
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
  • Consider:
    • Complexity (Low/Medium/High)
    • Maintainability
    • Performance implications
    • Security considerations
    • Testability
Presenting the design:
  • Once you believe you understand what you're building, present the design
  • Break it into sections of 200-300 words
  • 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
理解想法：
  • 首先了解当前项目状态（文件、文档、最近的提交记录）
  • 一次提出一个问题来细化想法
  • 尽可能使用选择题，开放式问题也可以
  • 每条消息只提一个问题——如果某个主题需要深入探索，拆分成多个问题
  • 重点理解：目的、约束条件、成功标准
何时启用UltraThink： 在提出架构方案前，若出现以下情况则启用深度思考：
  • 存在多个有效的解决方案，且各方案间有显著的权衡取舍
  • 决策会对长期架构产生影响
  • 需求涉及复杂的系统交互
  • 安全性或性能是关键关注点
🗣 可以说：“在提出方案前我先深度思考一下。我会质疑基本假设，从第一性原理出发考虑影响。”
UltraThink期间：
  • 质疑需求的假设前提
  • 考虑每种方案的二阶效应
  • 预想可能出现的问题（事前验尸）
  • 对比你见过的类似系统
  • 考虑未来的可维护性和扩展能力
UltraThink之后： 提出带有清晰权衡取舍和长期影响分析的方案。
探索实现方案：
  • 提出2-3种不同的方案并说明各自的权衡取舍
  • 以对话形式呈现选项，同时给出你的推荐和理由
  • 优先推荐你的首选方案并解释原因
  • 考虑以下因素：
    • 复杂度（低/中/高）
    • 可维护性
    • 性能影响
    • 安全性考量
    • 可测试性
呈现设计：
  • 当你明确要构建的内容后，开始呈现设计
  • 将内容拆分为200-300字的小部分
  • 每部分后询问用户目前的内容是否正确
  • 涵盖：架构、组件、数据流、错误处理、测试
  • 若用户表示有疑问，随时返回去澄清

After Brainstorming

头脑风暴之后

For Requirements (Phase 2):
  • Write validated requirements to 
    docx/features/[NN-feature-name]/requirements.md
  • Use EARS format (Event-Driven, State-Driven, Ubiquitous, Conditional, Optional)
  • Include:
    • Overview
    • Functional requirements
    • Non-functional requirements (performance, security, usability)
    • Constraints
    • Acceptance criteria
    • Out of scope items
  • Ask: "Requirements complete. Ready for design phase?"
For Design (Phase 3):
  • Write the validated design to 
    docx/features/[NN-feature-name]/design.md
  • Include:
    • Architecture Overview
    • Component Structure
    • Data Flow
    • API Contracts
    • Error Handling Strategy
    • Security Considerations
    • Performance Considerations
    • Testing Strategy
  • Ask: "Design complete. Ready for task breakdown?"
Transition:
  • After requirements → Proceed to Phase 3 (Technical Design)
  • After design → Transition to 
    spec-driven-implementation
    skill for task breakdown
针对需求阶段（阶段2）：
  • 将验证后的需求写入
    docx/features/[NN-feature-name]/requirements.md
  • 使用EARS格式（Event-Driven、State-Driven、Ubiquitous、Conditional、Optional）
  • 包含以下内容：
    • 概述
    • 功能需求
    • 非功能需求（性能、安全、可用性）
    • 约束条件
    • 验收标准
    • 超出范围的内容
  • 询问用户：“需求已完成。是否准备进入设计阶段？”
针对设计阶段（阶段3）：
  • 将验证后的设计写入
    docx/features/[NN-feature-name]/design.md
  • 包含以下内容：
    • 架构概述
    • 组件结构
    • 数据流
    • API契约
    • 错误处理策略
    • 安全性考量
    • 性能考量
    • 测试策略
  • 询问用户：“设计已完成。是否准备进行任务拆分？”
阶段过渡：
  • 需求阶段结束后 → 进入阶段3（技术设计）
  • 设计阶段结束后 → 切换到
    spec-driven-implementation
    技能进行任务拆分

Key Principles

核心原则

  • One question at a time - Don't overwhelm with multiple questions
  • Multiple choice preferred - Easier to answer than open-ended when possible
  • YAGNI ruthlessly - Remove unnecessary features from all designs
  • Explore alternatives - Always propose 2-3 approaches before settling
  • Incremental validation - Present design in sections, validate each
  • Be flexible - Go back and clarify when something doesn't make sense
  • Think about testing - Good designs are testable designs
  • Consider security - Build security in, don't bolt it on later
  • 一次一个问题 - 不要同时提出多个问题让用户应接不暇
  • 优先使用选择题 - 可能的话，选择题比开放式问题更容易回答
  • 严格遵循YAGNI原则 - 从所有设计中移除不必要的功能
  • 探索替代方案 - 在确定方案前，始终提出2-3种不同的实现方式
  • 逐步验证 - 分部分呈现设计，每部分都进行验证
  • 保持灵活 - 当用户有疑问时，返回去澄清
  • 考虑测试性 - 好的设计是可测试的设计
  • 重视安全性 - 从一开始就融入安全性，而不是事后补充

Example Questioning Flow

提问流程示例

Understanding Purpose:
Q: "What's the primary goal of this authentication feature?"
→ User answers

Q: "Should it support multiple auth methods (email/password, OAuth, etc.)
   or just one method initially?"
→ User answers

Q: "What happens when a session expires - force re-login or offer refresh?"
→ User answers
Exploring Approaches:
Based on your requirements, I see 3 main approaches:

**Option A: JWT-Based Authentication** [RECOMMENDED]
Pros: Stateless, scalable, works across services, standard
Cons: Token invalidation complexity, larger payload
Complexity: Medium
Best for: Microservices, APIs, future scalability

**Option B: Session-Based Authentication**
Pros: Simple invalidation, smaller cookies, familiar
Cons: Requires session storage, scaling challenges
Complexity: Low
Best for: Monolithic apps, simple use cases

**Option C: Hybrid Approach**
Pros: Combines benefits of both
Cons: More complex, harder to maintain
Complexity: High
Best for: Complex enterprise requirements

I recommend Option A (JWT) because your requirements mention
potential API integrations and future mobile app support.
JWT is industry-standard for this use case.

Does this align with your thinking?
Presenting Design Incrementally:
Let me present the architecture in sections:

**Section 1: High-Level Flow**
[200-300 words describing auth flow]

Does this look right so far?
→ User validates or requests changes

**Section 2: Component Structure**
[200-300 words describing components]

How does this look?
→ Continue...
理解目的：
Q: "这个认证功能的主要目标是什么？"
→ 用户回答

Q: "它应该支持多种认证方式（邮箱/密码、OAuth等）还是最初只支持一种方式？"
→ 用户回答

Q: "会话过期时会怎样——强制重新登录还是提供刷新选项？"
→ 用户回答
探索实现方案：
根据你的需求，我认为有3种主要实现方式：

**方案A：基于JWT的认证** [推荐]
优点：无状态、可扩展、跨服务兼容、标准化
缺点：令牌失效复杂度高、负载较大
复杂度：中等
适用场景：微服务、API、未来的扩展性需求

**方案B：基于会话的认证**
优点：失效机制简单、Cookie体积小、易于理解
缺点：需要会话存储、扩展难度大
复杂度：低
适用场景：单体应用、简单使用场景

**方案C：混合认证方式**
优点：结合前两种方案的优势
缺点：复杂度更高、维护难度大
复杂度：高
适用场景：复杂的企业级需求

我推荐方案A（JWT），因为你的需求提到了潜在的API集成和未来的移动应用支持。JWT是此类场景的行业标准。

这与你的想法一致吗？
逐步呈现设计：
我分部分呈现架构内容：

**第一部分：高层级流程**
[200-300字描述认证流程]

目前的内容看起来正确吗？
→ 用户确认或要求修改

**第二部分：组件结构**
[200-300字描述组件]

这部分看起来怎么样？
→ 继续...

Integration with Spec-Driven Workflow

与基于规格的工作流集成

This skill can be used in two phases:
Phase 2 (Requirements):
  • Use when user has rough idea but unclear requirements
  • Helps clarify what to build vs. what's out of scope
  • Explores different feature scopes and priorities
  • Outputs to 
    requirements.md
    in EARS format
Phase 3 (Technical Design):
  • Use after requirements are defined
  • Helps explore how to build the feature
  • Compares architectural approaches with trade-offs
  • Outputs to 
    design.md
    with complete technical specs
After brainstorming completes:
  • Phase 2 → Proceed to Phase 3 (Technical Design)
  • Phase 3 → Transition to 
    spec-driven-implementation
    for task breakdown
此技能可用于两个阶段：
阶段2（需求阶段）：
  • 当用户有初步想法但需求不明确时使用
  • 帮助明确要构建的内容和超出范围的内容
  • 探索不同的功能范围和优先级
  • 以EARS格式输出到
    requirements.md
阶段3（技术设计阶段）：
  • 在需求确定后使用
  • 帮助探索如何构建功能
  • 比较不同的架构方案及其权衡取舍
  • 将完整的技术规格输出到
    design.md
头脑风暴完成后：
  • 阶段2 → 进入阶段3（技术设计）
  • 阶段3 → 切换到
    spec-driven-implementation
    技能进行任务拆分

Notes

注意事项

  • Phase 2: Focus on "what" (what should system do? what's in/out of scope?)
  • Phase 3: Focus on "how" (how should we build it? what are trade-offs?)
  • Always present multiple options before recommending
  • Validate incrementally - don't dump everything at once
  • Be ready to backtrack if something doesn't make sense
  • One question at a time - let user think and respond
  • Good requirements lead to good designs
  • Good designs enable good tests - think about testability
  • Security and error handling are not afterthoughts
  • 阶段2： 重点关注“是什么”（系统应该做什么？哪些在范围内/范围外？）
  • 阶段3： 重点关注“怎么做”（我们应该如何构建？有哪些权衡取舍？）
  • 始终在推荐前呈现多个选项
  • 逐步验证——不要一次性输出所有内容
  • 当用户有疑问时，随时返回去澄清
  • 一次一个问题——让用户有时间思考和回应
  • 好的需求带来好的设计
  • 好的设计支持好的测试——要考虑可测试性
  • 安全性和错误处理不是事后补充的内容