brainstorm
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseBrainstorming 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字)呈现,每完成一部分就检查目前的内容是否合适。
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
Exploring approaches:
- Generate 6 possible approaches with trade-offs. Approaches should each include a text and a numeric probability. Please sample responses at random from the [full distribution / tails of the distribution], in such way that:
- For first 3 responses aim for high probability, over 0.80
- For last 3 responses aim for diversity - explore different regions of the solution space, such that the probability of each response is less than 0.10
- Present options conversationally with your recommendation and reasoning
- Lead with your recommended option and explain why
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
理解想法:
- 首先查看当前项目状态(文件、文档、近期提交记录)
- 逐个提出问题来完善想法
- 尽可能选择选择题,但开放式问题也可接受
- 每条消息仅包含一个问题——如果某个主题需要深入探讨,将其拆分为多个问题
- 重点理解:目标、约束条件、成功标准
探索方案:
- 生成6种带有取舍分析的可行方案。每个方案需包含文本描述和数值概率。请从[完整分布/分布尾部]中随机选取回复,要求如下:
- 前3个方案的概率需较高,超过0.80
- 后3个方案需注重多样性——探索解决方案空间的不同领域,每个方案的概率低于0.10
- 以对话形式呈现方案,并附上你的推荐及理由
- 首先展示你推荐的方案并解释原因
呈现设计:
- 当你确定已明确要构建的内容后,呈现设计方案
- 将设计拆分为200-300字的小部分
- 每完成一部分就询问目前的内容是否合适
- 涵盖:架构、组件、数据流、错误处理、测试
- 若有内容不合理,随时返回澄清
After the Design
设计完成后
Documentation:
- Write the validated design to
.specs/plans/<topic>.design.md - Use write-concisely skill if available
- Commit the design document to git
Implementation (if continuing):
- Ask: "Ready to set up for implementation?"
- Use to create isolated workspace
/worktrees create - Use to create task file for target approach
/add-task
文档记录:
- 将经过验证的设计写入
.specs/plans/<topic>.design.md - 若有write-concisely技能,请使用该技能
- 将设计文档提交至git
实施(若继续推进):
- 询问:"是否准备好开始实施?"
- 使用创建独立工作区
/worktrees create - 使用为目标方案创建任务文件
/add-task
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
- 一次一个问题 - 不要用多个问题让对方不知所措
- 优先选择选择题 - 可能的话,比开放式问题更易回答
- 严格遵循YAGNI原则 - 从所有设计中移除不必要的功能
- 探索替代方案 - 在确定方案前,始终提出2-3种备选方案
- 渐进式验证 - 分部分呈现设计,逐一验证
- 保持灵活 - 若有内容不合理,返回澄清