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.
通过自然协作对话,帮助将想法转化为完整的设计方案和规格说明。

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种备选方案
  • 增量式验证——分部分呈现设计方案,逐一验证
  • 保持灵活性——当内容存在疑问时,返回进行澄清