ideation
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseIdeation: Ideas Into Structured Documents
创意构思：将零散想法转化为结构化文档
Help turn rough ideas into structured, validated idea documents through natural collaborative dialogue. Start by understanding the current project context, then ask questions one at a time to refine the idea. Once the idea is clear, present approaches with feasibility evaluation and get user approval.
Do NOT skip to implementation. The purpose of this skill is to produce a well-thought-out idea document that can feed into requirements definition (e.g., USDM) or be tracked as a task. Even if the idea seems simple, unexamined assumptions cause the most wasted work.
帮助通过自然协作对话将粗略想法转化为结构化、经过验证的想法文档。首先了解当前项目上下文，然后逐个提出问题以完善想法。一旦想法明确，就提出带有可行性评估的方案并获得用户认可。
请勿直接跳到实施阶段。本Skill的目的是生成一份考虑周全的想法文档，作为需求定义（如USDM）的输入，或作为任务进行跟踪。即使想法看似简单，未经审视的假设也会导致大量无效工作。
Process
流程
Complete these steps in order:
按顺序完成以下步骤：
Step 1: Explore Context
步骤1：探索上下文
Review the current project to understand what already exists:
- Check project files, documentation, and recent commits
- Identify existing solutions, patterns, and conventions
- Note constraints, dependencies, and technical boundaries
This grounds the ideation in reality rather than starting from a blank slate.
回顾当前项目以了解已有的内容：
- 查看项目文件、文档和最近的提交记录
- 识别现有解决方案、模式和惯例
- 记录约束条件、依赖关系和技术边界
这能让创意构思基于实际情况，而非从零开始。
Step 2: Ask Clarifying Questions
步骤2：提出澄清问题
Understand the idea through focused dialogue:
- Ask one question at a time — do not overwhelm with multiple questions
- Prefer multiple choice questions when feasible — easier to answer than open-ended
- Focus on understanding: purpose, target users, constraints, success criteria
- Be ready to revisit earlier questions if new information changes the picture
Continue until you have a clear understanding of what the user wants and why.
通过聚焦对话了解想法：
- 一次只提一个问题——不要用多个问题淹没用户
- 可行时优先采用选择题——比开放式问题更容易回答
- 重点理解：目的、目标用户、约束条件、成功标准
- 如果新信息改变了情况，随时准备重新审视之前的问题
持续提问，直到你清楚了解用户的需求及其背后的原因。
Step 3: Propose Approaches
步骤3：提出替代方案
Present 2-3 different approaches with trade-offs:
- Lead with your recommended approach and explain why
- Present options conversationally with reasoning
- Each approach must include a feasibility evaluation:
- Differentiation: How does this differ from existing solutions?
- Technical risks and constraints: What could go wrong technically?
- Pre-mortem: "If this idea fails, what would be the cause?"
- Apply YAGNI — remove unnecessary features from all approaches
提出2-3种带有权衡分析的不同方案：
- 首先推荐你的首选方案并解释原因
- 以对话形式呈现选项并说明理由
- 每个方案必须包含可行性评估：
- 差异化：与现有解决方案有何不同？
- 技术风险与约束：技术层面可能出现哪些问题？
- 事前验尸：“如果这个想法失败，原因会是什么？”
- 严格遵循YAGNI原则——从所有方案中移除不必要的功能
Step 4: Present and Validate
步骤4：呈现并验证
Once the user selects an approach (or a combination):
- Present the idea in sections, scaled to complexity
- Ask after each section whether it looks right so far
- Be ready to go back and revise if something does not make sense
一旦用户选择了某个方案（或组合方案）：
- 按章节呈现想法，复杂度按需调整
- 每呈现完一个章节，询问用户当前内容是否正确
- 如果内容不合理，随时准备返回修改
Step 5: Write Idea Document
步骤5：撰写想法文档
After the user approves the idea, generate the document.
Save to:
.docs/ideas/YYYY-MM-DD-<topic>.mdThe document must contain these sections:
| Section | Content |
|---|---|
| What | What it does, the problem it solves |
| Why | Rationale, user benefit, business value |
| Scope | In scope / out of scope boundaries |
| Stakeholders | Target users, affected systems |
| Approaches | The explored alternatives with trade-offs and feasibility evaluation |
| Decision | The selected approach and rationale |
See for the output template.
templates/idea-document.mdThese sections are structured to serve as input for requirements definition tools (e.g., USDM):
- What maps to Requirements
- Why maps to Reasons
- Scope maps to Descriptions (context, constraints)
- Stakeholders informs scope confirmation
获得用户认可后，生成文档。
保存路径：
.docs/ideas/YYYY-MM-DD-<topic>.md文档必须包含以下章节：
| 章节 | 内容 |
|---|---|
| What（内容） | 功能描述、解决的问题 |
| Why（原因） | 理由、用户收益、业务价值 |
| Scope（范围） | 包含/不包含的边界 |
| Stakeholders（利益相关方） | 目标用户、受影响的系统 |
| Approaches（方案） | 探索过的替代方案及其权衡分析和可行性评估 |
| Decision（决策） | 选定的方案及其理由 |
可参考的输出模板。
templates/idea-document.md这些章节的结构可直接作为需求定义工具（如USDM）的输入：
- What（内容） 对应需求
- Why（原因） 对应理由
- Scope（范围） 对应描述（上下文、约束条件）
- Stakeholders（利益相关方） 用于确认范围
Step 6: Output Selection
步骤6：选择输出形式
After writing the idea document, ask the user which output they want:
| Option | Action |
|---|---|
| A: Markdown only (default) | Save the idea document to |
| B: Markdown + GitHub Issue | Save the document and create a GitHub Issue with the content |
| C: Markdown + requirements | Save the document and invoke a requirements definition skill (e.g., |
撰写完想法文档后，询问用户需要哪种输出形式：
| 选项 | 操作 |
|---|---|
| A: 仅Markdown（默认） | 将想法文档保存到 |
| B: Markdown + GitHub Issue | 保存文档并创建包含内容的GitHub Issue |
| C: Markdown + 需求定义 | 保存文档并调用需求定义Skill（如 |
Key Principles
核心原则
- One question at a time — do not bundle multiple questions in one message
- Multiple choice preferred — easier to answer than open-ended when feasible
- YAGNI ruthlessly — remove unnecessary features from all approaches
- Explore alternatives — always propose 2-3 approaches before settling
- Incremental validation — present sections, get approval, then move on
- Be flexible — go back and clarify when something does not make sense
- Feasibility over optimism — every approach needs honest risk assessment
- 一次只提一个问题——不要在一条消息中包含多个问题
- 优先选择选择题——可行时比开放式问题更容易回答
- 严格遵循YAGNI原则——从所有方案中移除不必要的功能
- 探索替代方案——在确定方案前始终提出2-3种选择
- 增量式验证——分章节呈现，获得认可后再继续
- 保持灵活性——当内容不合理时，返回重新澄清
- 可行性优先于乐观预期——每个方案都需要诚实的风险评估
Credits
致谢
This skill is based on the brainstorming skill from obra/superpowers (MIT License).
本Skill基于obra/superpowers的头脑风暴Skill（MIT许可证）。