Menu
在任何创意工作前使用 - 创建功能、构建组件、添加功能或修改行为前，探索用户意图、需求和设计
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
何时使用需要为编程项目、monorepo 或多级目录创建/更新 AGENTS.md、CLAUDE.md 软链接、项目级 agent 操作手册、子目录局部规则、验证命令和 Coding Agent 上下文边界时使用。
分析代码库结构并生成中文 token-lean 架构文档。
用于构建或维护个人 LLM 驱动的知识库。触发词：将资料导入 wiki、查询 wiki 知识、检查 wiki 质量、'添加到 wiki'、'我了解什么关于'，或任何提到 'LLM wiki' 的场景。
当有书面实施计划要在单独会话中执行并带审查检查点时使用
用户明确要求隔离工作区、并行分支验证或临时试验时使用 - 创建隔离的 git worktree
开始开发编程相关对话时使用 - 建立如何查找和使用 skills，在做出任何响应前要求先检查适用的 skill
| name | dev-brainstorming |
| description | 在任何创意工作前使用 - 创建功能、构建组件、添加功能或修改行为前，探索用户意图、需求和设计 |
通过自然协作对话，帮助将想法转化为完整的设计和规范。
首先了解当前项目上下文，然后一次提出一个问题来完善想法。一旦理解了要构建的内容，展示设计并获得用户批准。
在呈现设计并获得用户批准之前，**禁止**调用任何实现 skill、编写任何代码、搭建任何项目或采取任何实现行动。这适用于**每个**项目，无论其看起来多么简单。每个项目都必须经过此流程。一个待办事项列表、一个单功能工具、一个配置更改——所有这些都需要。所谓"简单"的项目正是未经审视的假设造成最多浪费工作的地方。设计可以很简短（真正简单的项目几句话即可），但你必须展示它并获得批准。
你必须为以下每一项创建任务并按顺序完成：
docs/plans/YYYY-MM-DD-<主题>-design.md 并提交到 gitdigraph brainstorming {
"探索项目上下文" [shape=box];
"涉及视觉问题？" [shape=diamond];
"提供 Visual Companion\n（独立消息）" [shape=box];
"提出澄清问题" [shape=box];
"提出 2-3 种方案" [shape=box];
"展示设计各节" [shape=box];
"用户批准设计？" [shape=diamond];
"编写设计文档" [shape=box];
"Spec review loop" [shape=box];
"Spec review 通过？" [shape=diamond];
"用户审查 spec？" [shape=diamond];
"调用 dev-writing-plans skill" [shape=doublecircle];
"探索项目上下文" -> "涉及视觉问题？";
"涉及视觉问题？" -> "提供 Visual Companion\n（独立消息）" [label="是"];
"涉及视觉问题？" -> "提出澄清问题" [label="否"];
"提供 Visual Companion\n（独立消息）" -> "提出澄清问题";
"提出澄清问题" -> "提出 2-3 种方案";
"提出 2-3 种方案" -> "展示设计各节";
"展示设计各节" -> "用户批准设计？";
"用户批准设计？" -> "展示设计各节" [label="否，修改"];
"用户批准设计？" -> "编写设计文档" [label="是"];
"编写设计文档" -> "Spec self-review\n（内联修复）";
"Spec self-review\n（内联修复）" -> "用户审查 spec？";
"用户审查 spec？" -> "编写设计文档" [label="请求更改"];
"用户审查 spec？" -> "调用 dev-writing-plans skill" [label="批准"];
}
终止状态是调用 dev-writing-plans。 不要调用 frontend-design、mcp-builder 或任何其他实现技能。brainstorming 之后只能调用 dev-writing-plans。
理解想法：
首先进行结构化调研，必须使用 subagent 并发调研，禁止串行探索浪费上下文。
可用调研工具（按场景选用，不强依赖任何单一工具）：
| 工具 | 适用场景 | 可替代 |
|---|---|---|
auggie-mcp codebase-retrieval | 语义搜索项目代码，理解已有实现 | Grep / Glob / Read |
context7（resolve-library-id → query-docs） | 查询第三方库的最新官方文档和 API | WebSearch + WebFetch |
mcp__zai-web-search-prime__web_search_prime | 网络搜索成熟方案、开源实现、社区讨论 | WebSearch |
mcp__zai-github-read__search_doc | 搜索 GitHub 仓库的文档、issues、commits | WebSearch |
mcp__zai-web-reader__webReader | 深度阅读搜索结果中的关键页面 | WebFetch |
根据调研维度拆分 subagent，个数按实际需要决定，相互独立的调研维度就并发跑：
示例：用户想给项目加一个 OAuth 登录功能
并行启动 subagent（3 个独立维度）：
├── Agent A: Grep/Glob 搜索项目 → 是否已有 auth 相关代码、中间件、session 管理
├── Agent B: context7 查文档 → 技术栈对应的 OAuth 库最新 API（如 next-auth v5）
└── Agent C: web search → 社区最佳实践、同类项目如何实现、常见踩坑点
汇总 → 发现项目已有 session 中间件可复用 + next-auth v5 API 变化大
→ 方案：Extend 现有中间件 + context7 确认 v5 写法
调研纪律：
澄清想法：
提问格式要求：
选项 A: 方案名称 (Recommended)
描述：简要说明 + 为什么推荐这个方案（理由）
预览：关键代码/配置/效果展示
选项 B: 备选方案
描述：简要说明 + 适用场景或劣势
预览：对比展示
探索方案：
(Recommended)展示设计：
文档：
docs/plans/YYYY-MM-DD-<主题>-design.mdSpec Self-Review（内联自审）： 写完设计文档后，用 fresh eyes 快速检查：
直接 inline 修复问题，无需重新分派 reviewer。修复后继续下一步。
用户审查 Gate： Spec review loop 通过后，请用户在继续之前审查书面 spec：
"Spec 已写入并提交到
<path>。请审查它，如果需要在开始编写实施计划之前做任何更改，请告诉我。"
等待用户的回复。如果他们请求更改，进行更改并重新运行 spec review loop。只有在用户批准后才能继续。
实现：
Visual Companion 是一个基于浏览器的可视化辅助工具，用于在头脑风暴期间展示 mockups、图表和视觉选项。作为工具提供 —— 不是一种模式。接受它意味着可以用于受益于视觉处理的问题；并不意味着每个问题都通过浏览器。
提供 Visual Companion： 当你预期即将到来的问题将涉及视觉内容（mockups、布局、图表）时，一次性征求同意：
"我们正在处理的一些内容，如果我能在 web 浏览器中展示给你，可能会更容易解释。我可以在进行过程中整理 mockups、图表、比较和其他视觉内容。这个功能仍然很新，可能会消耗大量 token。想试试吗？（需要打开本地 URL）"
此提议必须是独立的消息。 不要将其与澄清问题、上下文总结或任何其他内容合并。消息应该只包含上面的提议，其他什么都没有。等待用户的回复后再继续。如果他们拒绝，继续仅使用文本进行头脑风暴。
每个问题的决策： 即使在接受后，也要为每个问题决定是使用浏览器还是终端。测试：用户通过看会比读更理解这个吗？
关于 UI 主题的问题不自动是视觉问题。"在这个上下文中 personality 是什么意思？" 是一个概念问题 —— 使用终端。"哪个向导布局更好？" 是一个视觉问题 —— 使用浏览器。
如果用户同意使用，在继续之前阅读详细指南：
skills/dev-brainstorming/visual-companion.md