brainstorming

Files (1)

• SKILL.md

SKILL.md (first lines)

# Brainstorming — 从想法到设计

在写任何代码之前，通过协作对话把模糊想法变成完整设计。

先理解项目上下文，然后一个一个问问题来细化想法。理解要构建什么之后，展示设计方案并获取用户确认。

## 核心规则

**在展示设计方案并获得用户确认之前，不要写任何代码、不要 scaffold 项目、不要调用任何实现工具。** 不管需求看起来多简单，这条规则适用于所有项目。

## 反模式："这太简单了不需要设计"

所有项目都走这个流程。Todo list、工具函数、配置修改 —— 全都一样。"简单"项目正是未经审视的假设造成最多返工的地方。设计可以很短（真正简单的项目几句话就行），但必须先展示并获得确认。

## 流程

1. **探索项目上下文** — 查看文件、文档、最近的提交
2. **逐个问澄清问题** — 理解目的、约束、成功标准
3. **提出 2-3 种方案** — 含权衡和推荐
4. **分段展示设计** — 按复杂度分段，每段获取确认
5. **写设计文档** — 保存到 `docs/specs/YYYY-MM-DD-<topic>-design.md` 并提交
6. **设计自查** — 检查占位符、矛盾、歧义、范围
7. **用户审阅** — 展示设计文档，等用户确认
8. **过渡到实现** — 调用 `/skill writing-plans` 创建实施计划

## 关键原则

- **一次一个问题** — 不要一次抛出多个问题
- **优先选择题** — 比开放式问题更容易回答
- **YAGNI** — 无情地移除不必要的功能
- **探索替代方案** — 总是提出 2-3 种方式
- **增量验证** — 展示设计，获取确认，再继续
- **灵活** — 有不清楚的地方就回头澄清

## 实现入口

设计文档被用户确认后，调用 `/skill writing-plans` 创建实施计划。不要直接跳到编码。

From noobke/reasonix-skills, MIT.

More from noobke/reasonix-skills