القائمة
当用户明确要求头脑风暴、收集需求、写 PRD、或探索「要不要做 / 做什么」时使用。通过协作对话将粗略想法转化为清晰的产品需求文档。不自动触发——仅在用户显式发起需求探索流程时才启动。
يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.
اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/ninehills/skills --skill brainstorming-cnيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
عرض SKILL.md
استنادا إلى تصنيف SOC المهني
| 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