菜单
在开始实现前，把需求澄清成设计文档。适用于新增功能、修改行为、组件设计、接口设计、流程改造、架构取舍和多方案比较。只要改动跨文件、改行为或涉及多方案取舍，就值得先做设计，无论体量大小；单点直改不必走本 skill。用户说'先想一下''先给方案''先规划一下''先比较两种做法'时优先使用这个 skill。
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/iasiv5/ob-harness --skill brainstorming命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
在任务完成后，对仓库内长期知识做深度整理、沉淀与规范审计。仅在用户明确要求 cleanup、最终沉淀、长期知识同步、收尾整理，或明确要求检查仓库规则执行情况时触发；不要用于中途续做、普通总结、状态同步或实现过程中的正常文档更新。默认保守触发，强制 cleanup 也不默认写入用户记忆。
为新的 chat / 新会话生成面向下一会话目标的 handoff / continuation context。仅在用户明确要把当前工作交接到新 chat 继续时触发；不要用于普通总结、状态同步、代码评审、changelog 或文章摘要。基于只读证据输出可直接粘贴到新 chat 的中文优先接续上下文。
在已有设计文档或清晰需求、但还没开始实现时，把目标写成可执行的分步实施计划。适用于跨文件改动、非平凡功能、重构，以及任何需要明确测试或验证命令的任务。只要用户要把已定需求、现成 spec、明确目标，或 /grill-with-docs / /grilling 后达成的共识，拆成 step-by-step plan，就优先使用这个 skill；如果设计还没定，不要硬写计划，退回 brainstorming 或 grill-with-docs 把设计做扎实。
基于 SOC 职业分类
正在显示 SKILL.md
| name | brainstorming |
| description | 在开始实现前，把需求澄清成设计文档。适用于新增功能、修改行为、组件设计、接口设计、流程改造、架构取舍和多方案比较。只要改动跨文件、改行为或涉及多方案取舍，就值得先做设计，无论体量大小；单点直改不必走本 skill。用户说'先想一下''先给方案''先规划一下''先比较两种做法'时优先使用这个 skill。 |
| argument-hint | 描述要做的功能、约束、背景或已有想法；可留空 |
这个 skill 用于把模糊想法收敛成经用户批准的设计文档，再把下一步明确交给 writing-plans。
这是一个 manual-first 的规划 skill，不是实现 skill。 在这个 skill 中，设计获批前不要写代码、不要生成补丁、不要进入实现。
在以下场景优先使用这个 skill：
以下请求默认不要使用这个 skill：
docs/specs/writing-plans，不是直接编码接受：推荐方案、接受：方案 A/B/C 或同等明确确认后，才能进入 PHASE 5 写设计文档批准：<设计文档路径> 或同等明确批准后，才能进入 PHASE 8 和 writing-plans默认形态：
这一步不该继续用 brainstorming，应切到
writing-plans（或实现 / review 流程）。 你现在要的是把已定需求拆成计划 / 直接编码 / 审查，不需要再做方案比较。
模糊表述不算通过检查点，例如“看起来可以”“先这样”“应该行”“你继续吧”“好的”“继续吧”“都行”。遇到这些表述时，只发一个确认问题，要求用户改用上面的确认令牌。
判定“同等明确”（🔴 CHECKPOINT A 与 B 通用）：必须明确点名所选方案（如“方案 A”“推荐方案”）或批准的具体文档（如“批准刚才那份设计”“就按 docs/specs/xxx 批准”），或使用确认令牌本身（接受：... / 批准：<path>）；只表达整体态度（“看起来可以”“先这样”“应该行”“你继续吧”“好的”“继续吧”“都行”）而未点名的，一律视为模糊。半角冒号与全角冒号等价。
命中下列已知翻车点时按“信号 → 一线动作”处理。本表是诊断索引——每条只写一线动作并指向详细规则归属，不在此重复正文：
| 信号 | 一线动作 | 详见 |
|---|---|---|
| 请求本质不是设计（bugfix / review / 已有设计只要拆计划） | 🛑 STOP，路由到实现 / review / writing-plans | “不要路由”、🛑 STOP |
| mixed intent（实现 + 设计混合） | 不编码、不写补丁，只问路由选择题：A 只做设计 / B 停 brainstorming 进实现 | — |
| 直接写文档但方案尚未确认 | 先给推荐方案 + trade-offs，触发 CHECKPOINT A；草稿标“草稿 / 待审批” | CHECKPOINT A |
| 跨多个独立子系统 | 先拆分，只继续第一个子项目 | PHASE 0、硬约束 |
| 相关上下文找不到 / 无现成实现 | 列 1-3 条工作假设，按最保守假设写边界级设计，风险进未决事项 | PHASE 1 |
| 含糊话术当 CHECKPOINT 批准 | 不推进，要求 接受：... / 批准：<path> 令牌 | 🔴 CHECKPOINTS |
| 可视化工具不可用 | 降级 Mermaid / ASCII / 文字结构，不伪造已验证视觉方案 | 硬约束 |
| 跨轮矛盾 / 拒绝澄清 / 无声漂移 | 就地守卫已 co-locate 在执行点，见对应 PHASE | PHASE 2、PHASE 5 |
其余（为“更干净”重做边界 / scope creep via doc / handoff payload 留字面量 <path> 等）已在硬约束与 references/spec-self-review.md 规定，此处不重复。
开始前先确认：
如果需求明显包含多个独立子系统：
先读取最小必要的项目上下文：
探索目标不是把项目全部看完，而是回答三个问题：
停止条件：一旦能指出最相关的 owning abstraction、一个邻近调用点或测试、一个会影响方案的现实约束，就停止探索并进入澄清或方案比较；不要为了提高信心继续扩大搜索范围。
先阅读 references/questioning-rules.md 里的规则，再发澄清问题。
澄清阶段的目标：
默认形态：
先把这次讨论收敛成设计文档，不进入实现。 （若跨子系统）这次需求可拆成 X / Y / Z；这轮只继续 X。 先确认一个点：首要目标更偏 A / B / C？
两条运行期守卫：
如果某个问题属于真实视觉判断，例如布局、界面草图、关系图或架构图，比文字更容易判断，就在那个问题出现时单独询问是否启用可视化辅助。UI 主题本身不等于视觉问题；如果只是需求、范围或 trade-off 选择，继续用文字提问。
在你理解需求后，给出 2-3 个方案：
方案比较时同时检查设计单元是否足够清楚：每个单元都应该能回答“它负责什么、怎么使用、依赖什么”。如果必须读内部实现才能理解一个单元的用途，或改内部实现会牵动消费者，边界还没有设计好。
默认形态（每个方案写 4 项：核心思路 / 优点 / 缺点 / 适用条件）：
方案 A：…… 方案 B：…… 方案 C：…… 推荐方案：…… 先确认一个点：请回复
接受：推荐方案，或改选接受：方案 A/B/C。
设计要分段呈现，并在每个重要段落后确认：
每段内容要和复杂度匹配：
如果用户对某一段提出异议：
🔴 CHECKPOINT A：用户没有用 接受：... 或同等明确表述接受推荐方案、范围和关键边界前，不要进入 PHASE 5。
在 CHECKPOINT A 通过（用户用 接受：推荐方案 或 接受：方案 A/B/C 等明确令牌接受了所选方案）后，把设计写成文档。
无声漂移守卫：写文档时若偏离了 CHECKPOINT A 已批准的方案（范围、边界或关键取舍），把偏离点单独列出，回到用户面前重新触发 CHECKPOINT A 确认方向；未重确认前按已批准版本写，偏离写进未决事项。
路径选择顺序：
docs/specs/<YYYY-MM-DD>-<topic>-design.md如需固定骨架，先读取 references/spec-template.md。
设计文档至少覆盖：
写完文档后，读取 references/spec-self-review.md 并完成单轮 inline 自检。
修复真正会影响后续计划的问题：
不要为了文风润色反复循环。修完就继续。
自检通过后，明确让用户审阅设计文档。
建议使用类似表述：
设计文档已写好并保存到
<path>。请先审阅这份设计；如果需要改动，我会先改设计，再进入实施计划。 如果批准，请回复批准：<path>。
如果用户要求修改：
只有在用户明确批准后，才能进入下一阶段。
🔴 CHECKPOINT B：没有 批准：<path> 或同等明确批准，就停在设计阶段；不要切到 writing-plans。
用户批准设计后：
writing-planswriting-plans 直接接续：handoff_to: writing-plans
approved_design: <path>
approval: <用户批准原文>
scope: <本次做什么>
non_scope: <本次不做什么>
open_items: <不阻塞计划的未决事项；没有则写 none>
planning_goal: 基于已批准设计拆成可执行实施计划，不重新做方案比较
<path> 等尖括号占位符必须替换成真实已批准路径，不要保留字面量One question · Multiple choice · YAGNI · Alternatives first · Incremental validation · Just-in-time visual · Isolation & clarity · Follow the repo（各词已在对应 PHASE 与硬约束里定义）
先验证请求与范围，再读取最小必要上下文，然后按上述流程推进到已批准的设计文档。