// 当用户明确要求头脑风暴、收集需求、写 PRD、或探索「要不要做 / 做什么」时使用。通过协作对话将粗略想法转化为清晰的产品需求文档。不自动触发——仅在用户显式发起需求探索流程时才启动。
| name | brainstorming-cn |
| description | 当用户明确要求头脑风暴、收集需求、写 PRD、或探索「要不要做 / 做什么」时使用。通过协作对话将粗略想法转化为清晰的产品需求文档。不自动触发——仅在用户显式发起需求探索流程时才启动。 |
通过自然的协作对话，帮助将粗略想法转化为清晰、可执行的产品需求。
首先了解当前项目上下文，然后逐一提问来完善想法。目标是产出一份完整、无歧义的产品需求文档（PRD），回答构建什么（WHAT）和为什么构建（WHY）。如何构建（HOW）留给后续阶段。
本技能只关注需求（WHAT）。不得讨论技术架构、技术选型、代码结构、API 设计、数据库 schema、或任何实现细节。在 PRD 编写完成、审查通过并获得用户批准之前，不得调用任何实现技能、编写任何代码、搭建任何项目、或采取任何实现行动。无论项目看起来多简单，此规则一律适用。每个项目都要经过这个流程。一个待办事项列表、一个单函数工具、一个配置变更——全都需要。"简单"的项目恰恰是未经检验的假设造成最多浪费的地方。PRD 可以很简短（对于真正简单的项目几句话就够了），但你必须写出来并获得批准。
你必须为以下每个条目创建任务，并按顺序完成：
docs/prd/<topic>.md 并 commitdigraph brainstorming {
"探索项目上下文" [shape=box];
"有视觉相关问题?" [shape=diamond];
"提供视觉伴侣\n（独立消息，不含其他内容）" [shape=box];
"提出澄清问题" [shape=box];
"提出 2-3 种需求方案" [shape=box];
"分节展示需求" [shape=box];
"用户批准需求?" [shape=diamond];
"编写 PRD" [shape=box];
"PRD 自检\n（内联修复）" [shape=box];
"用户审查 PRD?" [shape=diamond];
"调用 design/\n规划技能" [shape=doublecircle];
"探索项目上下文" -> "有视觉相关问题?";
"有视觉相关问题?" -> "提供视觉伴侣\n（独立消息，不含其他内容）" [label="是"];
"有视觉相关问题?" -> "提出澄清问题" [label="否"];
"提供视觉伴侣\n（独立消息，不含其他内容）" -> "提出澄清问题";
"提出澄清问题" -> "提出 2-3 种需求方案";
"提出 2-3 种需求方案" -> "分节展示需求";
"分节展示需求" -> "用户批准需求?";
"用户批准需求?" -> "分节展示需求" [label="否，修改"];
"用户批准需求?" -> "编写 PRD" [label="是"];
"编写 PRD" -> "PRD 自检\n（内联修复）";
"PRD 自检\n（内联修复）" -> "用户审查 PRD?";
"用户审查 PRD?" -> "编写 PRD" [label="要求修改"];
"用户审查 PRD?" -> "调用 design/\n规划技能" [label="批准"];
}
终止状态是调用 design 或实现规划技能。 不要调用任何实现技能。头脑风暴之后你应该调用的是设计/规划技能。
理解想法：
探索需求方案：
展示需求：
一份好的 PRD 应该清楚回答以下问题：
文档：
docs/prd/<topic>.mdPRD 自检： 编写 PRD 文档后，以全新的视角审视它：
发现问题就直接内联修复。无需重新审查——修好继续推进。
用户审查关卡： PRD 自检完成后，请用户在继续之前审查书面 PRD：
"PRD 已编写并 commit 到
<path>。请审查一下，如果在我们进入设计和实现之前你想做任何修改，请告诉我。"
等待用户回复。如果他们要求修改，做出修改并重新运行 PRD 自检。只有在用户批准后才继续。
实现：
一个基于浏览器的伴侣工具，用于在头脑风暴过程中展示原型、图表和视觉选项。它是一个工具——不是一种模式。接受伴侣意味着它可用于适合视觉呈现的问题；并不意味着每个问题都要通过浏览器。
提供伴侣： 当你预计后续问题会涉及视觉内容（原型、布局、用户流程）时，提供一次以获得同意：
"我们接下来讨论的一些内容，如果能在浏览器中展示给你看可能会更直观。我可以在讨论过程中为你制作原型、图表、对比图和其他视觉材料。这个功能还比较新，可能会消耗较多 token。要试试吗？（需要打开一个本地 URL）"
此提议必须是一条独立的消息。 不要将它与澄清问题、上下文摘要或任何其他内容合并。消息中应该只包含上述提议，没有其他内容。等待用户回复后再继续。如果他们拒绝，继续纯文本的头脑风暴。
逐问题决策： 即使用户接受了，也要对每个问题单独决定是使用浏览器还是终端。判断标准：用户看到它是否比读到它更容易理解？
关于 UI 主题的问题不一定是视觉问题。"引导流程应该完成什么？"是一个需求问题——使用终端。"引导向导的哪种布局感觉对？"是一个视觉问题——使用浏览器。
如果他们同意使用伴侣，在继续之前阅读详细指南：
skills/brainstorming-cn/visual-companion.md
生图 / 生成图片 / 画图 — 用 OpenAI gpt-image-2 生成图像。支持文生图、参考图生图 (img2img)、蒙版修补 (inpainting)。当用户要求用 GPT 画图、OpenAI 生图、gpt-image-2、文+图生图、参考图片生成、img2img、inpainting 时必加载此技能。Auth 自动继承 OPENAI_API_KEY / Codex OAuth (Pi/Codex) / .env / config.yaml。
Remove AI writing patterns from English prose. Covers blog posts, technical docs, social copy, release notes, scientific writing. Trigger: deslop, de-AI, make it sound human, remove AI patterns, fix slop, polish, rewrite, sound natural
去除中文写作中的 AI 腔调，让文本像人写的而非模型生成的。覆盖博客、技术文档、推文、发行说明、科学论文等场景。触发词：去 AI 味、改写、润色、审稿、翻译腔重、像人写的、自然一点。英文去 AI 味见 deslop-en
Use when reviewing code changes, PRs, diffs, or commits. 触发：审查、review、CR、看看这段代码、检查这个 PR、审一下。
为任意 coding agent 编写高质量任务目标的指南。当用户提到「设定目标」「goal」「任务目标」「持久目标」「完成标准」、或需要为复杂多轮任务（性能优化、调试、迁移、研究复现等）定义可验证的完成条件和约束时触发。
Control herdr from inside it. Manage workspaces and tabs, split panes, run commands, read output, and wait for state changes — all via CLI commands that talk to the running herdr instance over a local unix socket. Use when running inside herdr (HERDR_ENV=1).