Brainstorming
A curated collection of WorkBuddy agent skills — academic pipeline, frontend slides, PPTX generator, tool-call repair, and more.
npx -y skills add yinqd3/workbuddy-skills --skill brainstormingAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
创建功能、构建组件、添加特性或修改行为前必须使用。探索用户意图、需求和设计，获得批准后才能写代码。触发词：做功能、加特性、构建、新项目、我想做、let's build、implement、create feature。
SKILL.md
3.1 KB, as published. Nobody here has run it
头脑风暴 → 设计文档
在动手写代码之前，通过结构化对话把想法变成完整设计。
硬门禁（HARD GATE）
在设计获得用户批准之前，禁止调用任何实现技能、写任何代码、搭建任何项目框架。
每个项目都要过这关——Todo 列表、工具函数、配置修改，全都不例外。简单的项目可以有简短的设计，但你必须呈现设计并获取批准。
反模式："这个太简单不需要设计"
每个项目都要走这个流程。"简单"项目恰恰是未经检验的假设造成最多浪费的地方。设计可以短（真正简单的项目只需几句话），但必须呈现并获得批准。
检查清单（按顺序完成）
- 探索项目上下文 — 检查文件、文档、最近的提交记录
- 提出澄清性问题 — 一次只问一个，理解目的、约束、成功标准
- 提出 2-3 个方案 — 带权衡分析和你推荐的方案
- 呈现设计方案 — 按复杂度分节展示，每节获取用户批准
- 编写设计文档 — 保存到
docs/plans/YYYY-MM-DD-<主题>-design.md并提交 - 规格自查 — 快速检查占位符、矛盾、歧义、范围
- 用户审查 — 请用户审查规格文档再继续
- 移交实现 — 调用
writing-plans技能创建实现计划
提问规则
- 每条消息只问一个问题
- 优先使用选择题，开放式也行
- 理解：目的、约束、成功标准、明确不做什么
方案探讨
- 提出 2-3 个不同方案，每个带权衡分析
- 对话式呈现，先说你推荐的，并解释原因
设计呈现
- 确认理解后，呈现设计
- 按复杂度调整每节长度
- 每节问"这看起来对吗？"
- 覆盖：架构、组件、数据流、错误处理、测试策略
关键原则
- 一次一个问题，不要轰炸
- 选择题优先
- YAGNI 无情——移除所有设计中不必要的功能
- 探索替代方案——确定前至少提 2-3 个
- 渐进式验证——呈现设计，获批准，再前进
- 灵活——哪里不对就回去澄清
设计文档
# [功能名称] 设计文档
**目标:** [一句话描述要构建什么]
**架构:** [2-3 句关于方案]
**技术栈:** [关键技术/库]
**文件结构:** [新建/修改的文件，每个文件的职责]
**数据流:** [数据如何流转]
**错误处理:** [错误处理策略]
**测试策略:** [如何测试]
撰写设计文档后
- 占位符扫描 — 有 "TBD"、"TODO"、不完整的部分吗？修复。
- 内部一致性 — 各部分有矛盾吗？架构和功能描述一致吗？
- 范围检查 — 足够聚焦吗？还是需要再分解？
- 歧义检查 — 有需求能有两种解读吗？选定一种并明确。
然后请用户审查，等待批准后再调 writing-plans。