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字）呈现设计，每部分完成后确认是否符合预期。

The Process

流程

Understanding the idea:

Review current project context first (key files/docs, recent commits, existing patterns).
Ask one question per message to refine the idea (prefer multiple-choice when possible).
Focus on: purpose, constraints, success criteria, non-goals.

Exploring approaches:

Propose 2–3 approaches with trade-offs.
Recommend one approach and explain why.

Presenting the design:

Present the design in 200–300 word chunks and confirm after each chunk.
Cover: architecture, components, data flow, error handling, testing.
Be ready to backtrack if the user says something doesn’t fit.

理解想法：

首先回顾当前项目背景（关键文件/文档、近期提交、现有模式）。
每次只提一个问题来完善想法（尽可能采用选择题形式）。
聚焦于：目的、约束条件、成功标准、非目标。

探索实现方案：

提出2–3种带有权衡分析的实现方案。
推荐其中一种方案并说明理由。

呈现设计：

分200–300字的模块呈现设计，每个模块后进行确认。
涵盖：架构、组件、数据流、错误处理、测试。
若用户表示内容不符合需求，随时准备回溯调整。

After the Design

设计完成后

Documentation:

Write the validated design to
```
docs/plans/YYYY-MM-DD-<topic>-design.md
```
when that convention exists; otherwise create
```
docs/plans/
```
or ask where to put it.
If you have a writing-quality skill available, use it before finalizing the doc.
If the repo is under git and the user wants it tracked, commit the design doc.

Implementation (if continuing):

Ask: “Ready to set up for implementation?”
If the user wants a separate workspace, use a git worktree.
Create a concrete implementation plan before writing code.

文档撰写：

若存在既定规范，将经过验证的设计写入
```
docs/plans/YYYY-MM-DD-<topic>-design.md
```
；否则创建
```
docs/plans/
```
目录或询问存储位置。
若有写作质量相关的Skill可用，在最终确定文档前使用该Skill。
若仓库基于Git且用户希望追踪文档，提交该设计文档。

实现（若继续推进）：

询问：“是否准备好进入实施阶段？”
若用户需要独立工作区，使用git worktree。
在编写代码前创建具体的实施计划。

Key Principles

核心原则

One question at a time — Don’t overwhelm with a questionnaire.
Multiple choice preferred — Faster to answer and reduces ambiguity.
YAGNI ruthlessly — Remove unnecessary scope/features from designs.
Explore alternatives — Always consider 2–3 viable approaches.
Incremental validation — Confirm each design chunk before continuing.
Be flexible — Adjust quickly when something doesn’t fit.

一次只提一个问题 —— 不要用大量问题让用户不知所措。
优先使用选择题 —— 回答更高效且减少歧义。
严格遵循YAGNI原则 —— 从设计中移除不必要的范围/功能。
探索替代方案 —— 始终考虑2–3种可行的实现方案。
增量式验证 —— 继续推进前确认每个设计模块。
保持灵活性 —— 当出现不符合需求的情况时快速调整。