brainstorming
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.
通过自然协作对话,帮助将想法转化为完整的设计方案和规格说明。
When to Use
适用场景
- Before starting any creative work (features, components, UI/UX) that lacks precise requirements or design intent.
- When the user wants to explore use cases, constraints, or success criteria before implementation.
- When you need to surface multiple approaches and trade-offs with the human partner.
- 在启动任何缺乏明确需求或设计意图的创意工作(功能、组件、UI/UX)之前。
- 当用户希望在实施前探索用例、约束条件或成功标准时。
- 当你需要与协作伙伴一起梳理多种实现方案及其利弊时。
When NOT to Use
不适用场景
- The solution is already well-defined and just needs implementation.
- You are continuing an execution plan or refactoring already scoped code.
- The task is strictly maintenance or cleanup with no new design decisions.
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:
- Propose 2-3 different approaches with trade-offs
- 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
理解想法:
- 首先了解当前项目状态(文件、文档、近期commit记录)
- 逐个提出问题来细化想法
- 尽可能使用选择题,开放式问题也可
- 每条消息仅提出一个问题——若某个主题需要深入探讨,拆分为多个问题
- 重点关注:目的、约束条件、成功标准
探索实现方案:
- 提出2-3种不同的实现方案,并说明各自的利弊
- 以对话形式呈现选项,同时给出你的推荐及理由
- 优先介绍你推荐的方案并解释原因
呈现设计方案:
- 当你明确了要构建的内容后,开始呈现设计方案
- 将内容拆分为200-300字的小部分
- 每完成一部分后询问当前内容是否符合预期
- 涵盖:架构、组件、数据流、错误处理、测试
- 若内容存在疑问,随时返回进行澄清
After the Design
设计完成后
Documentation:
- Write the validated design to
docs/plans/YYYY-MM-DD-<topic>-design.md - Use elements-of-style:writing-clearly-and-concisely skill if available
- Commit the design document to git
Implementation (if continuing):
- Ask: "Ready to set up for implementation?"
- Use superpowers:using-git-worktrees to create isolated workspace
- Use superpowers:writing-plans to create detailed implementation plan
文档记录:
- 将经过验证的设计方案写入
docs/plans/YYYY-MM-DD-<topic>-design.md - 若有可用的elements-of-style:writing-clearly-and-concisely skill,可借助其完成文档
- 将设计文档commit到git仓库
实施阶段(若后续继续推进):
- 询问:“是否准备好进入实施阶段?”
- 使用superpowers:using-git-worktrees创建独立工作区
- 使用superpowers:writing-plans创建详细的实施计划
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种备选方案
- 增量式验证——分部分呈现设计方案,逐一验证
- 保持灵活性——当内容存在疑问时,返回进行澄清