在创建功能、组件或修改行为前…

适用于任何创造性开发工作开始前，先分类 spike/bounded/architectural，并与人类伙伴对齐意图、设计和批准。

适用场景

解决思路

1. 在任何创造性工作前先执行头脑风暴：探索用户意图、需求和设计，再进入实现。
2. 先分类请求需要的流程量，再按路径走：理解上下文、细化想法、呈现设计、获得人类伙伴批准。
3. 发现意图：用请求和可用上下文识别预期结果、给谁用、成功标准。
4. 当缺少目的或预期用途信息时，在提出功能或方案前只问一个聚焦问题。
5. 不要因为知道应用类型就假设知道伙伴为什么想要它。
6. 收集缺失需求时不要要求伙伴再次授权任务。
7. 写回你的理解：用简短笔记总结预期结果、相关约束、成功标准，供伙伴评估。
8. 在笔记中区分伙伴说的内容和你的假设。
9. 邀请纠正，并在把理解当作设计简报前采纳回答。
10. 将意图带入设计：把达成一致的理解保留在所选路径的设计工件中——架构工作写规格，有界工作和 spike 用聊天设计/探针。
11. 用该理解检查提议的功能和技术选择。
12. 当请求已提供目的和约束时，反映该理解，不重复问同样问题。
13. 保持理解笔记简洁，准确性和可纠正机会比长度重要。
14. 遵守 HARD-GATE：在采取任何实现行动前，包括调用实现技能、写产品代码、搭脚手架、安装产品依赖、创建外部项目，完成所选路径先决条件。
15. Spike 先决条件：人类伙伴批准问题和探针。
16. Bounded 先决条件：人类伙伴批准简短聊天设计。
17. Architectural 先决条件：人类伙伴审查并批准书面规格，然后审查书面实现计划并选择执行方法。
18. 对话设计批准只允许写规格；书面规格批准只允许调用 writing-plans。
19. 回复只批准实际呈现的阶段；批准想法或功能范围不批准尚不存在的工件。
20. 从最早未完成阶段继续；不要把一个批准变成跳过所选路径其余部分的许可。
21. 只读项目探索可在先决条件未完成时进行。
22. 在第一个问题前分类请求，并说出分类，以便人类伙伴可覆盖。
23. Spike 路径：用于可行性问题（「can we...」、「is it possible...」、「quick and dirty is fine」），输出是答案而非保留代码。
24. Spike：用 2-3 句话呈现问题和会尝试什么，得到点头，然后以正确性允许的最低成本查明。
25. Spike：不写设计文档，不写规格文件。
26. Spike：报告发现作为建议；构建的任何东西标记为一次性。
27. Bounded 路径：用于已存在于仓库中的代码的范围明确变更，如新 flag、小 endpoint、单文件修复。
28. Bounded：确认要修改的流程已存在于仓库可读；若没有现有流程可改，则任务不是 bounded。
29. Bounded：问重要的澄清问题，在聊天中呈现简短设计（几句话到几段），然后停止。
30. Bounded：只有人类伙伴对该设计明确说是，才开始实现；无规格文件、无实现计划文档。
31. Architectural 路径：用于新项目、新子系统、重组组件如何搭配或改变他人依赖接口的变化。
32. Architectural：遵循完整流程：问题、方案、分节设计、书面规格，然后 writing-plans 技能。
33. 当在两个路径之间犹豫，选更重的路径。
34. 棘轮单向：任务中途发现隐藏复杂性会升级路径——停止、说明并升级。
35. 不中途降级路径。
36. 每个路径最终都需要人类伙伴在实现前批准所需设计。
37. Bounded 变更可能只需聊天两句话；新 todo-list 项目是架构性，需要书面规格和规划交接。
38. 根据所选路径缩放工件；在实现前完成该路径的审查。
39. 避免「太简单不需要设计」：bounded 变更获得简短聊天设计；架构变更获得书面规格和规划交接。
40. 避免用标签跳过工作；伸手拿标签来跳过工作就是疑虑，选更重路径。
41. 不要在呈现设计的同时开始实现；门是批准，不是设计长度。呈现，然后停止直到听到 yes。
42. 不要因为熟悉应用类型就称 bounded；bounded 衡量仓库，不是熟悉度。新项目没有现有流程，是架构性。
43. 不要因为 spike 成功就保留代码；spike 输出是答案，保留代码是新请求，需分类。
44. 不要因为任务变大但快完成就不重新分类；隐藏复杂性在任务中途升级路径，停止并说明。
45. 不要因为批准了 spike 就认为后续变更也批准；每个任务有自己的分类和批准。
46. 先分类，宣布路径，然后为路径上每个检查项创建任务并按顺序完成。
47. Spike 检查项：探索项目上下文——足以框定探针。
48. Spike 检查项：呈现问题 + 探针计划——2-3 句话。
49. Spike 检查项：获得批准——点头即可。
50. Spike 检查项：调查——以正确性允许的最低成本。
51. Spike 检查项：报告发现——给建议；任何构建物标记为一次性。
52. Bounded 检查项：探索项目上下文——检查文件、文档、最近提交。
53. Bounded 检查项：一次问一个重要的澄清问题。
54. Bounded 检查项：在聊天中呈现简短设计——方法、涉及文件、测试。
55. Bounded 检查项：获得批准——停止并等待明确 yes；呈现设计和开始在同一口气就是跳过门。
56. Bounded 检查项：实现——按正常开发工作流进行（适用 TDD）；无计划文档。
57. Architectural 检查项：探索项目上下文——检查文件、文档、最近提交。
58. Architectural 检查项：仅在需要时提供视觉 companion，不要提前。第一次问题真正展示比描述更清楚时，作为单独消息提供。
59. Architectural 检查项：一次问一个澄清问题，理解目的/约束/成功标准。
60. Architectural 检查项：提出 2-3 个方案——带权衡和你的推荐。
61. Architectural 检查项：呈现设计——按复杂度分节，每节后获得用户批准。
62. Architectural 检查项：写设计文档——保存到 `docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md` 并提交。
63. Architectural 检查项：规格自审——快速内联检查占位符、矛盾、歧义、范围。
64. Architectural 检查项：用户审查书面规格——继续前请用户审查规格文件。
65. Architectural 检查项：过渡到实现——调用 writing-plans 技能创建实现计划。
66. 终端状态按路径绑定：Architectural 在头脑风暴后唯一调用 writing-plans，绝不调用 frontend-design、mcp-builder 或其他实现技能。
67. Bounded 批准后直接通过正常开发工作流实现，无计划文档。
68. Spike 终端状态是报告建议。
69. 先检查当前项目状态（文件、文档、最近提交）。
70. 在问详细问题前评估范围：若请求描述多个独立子系统（如「build a platform with chat, file storage, billing, and analytics」），立即标记。
71. 不要花问题细化一个需要先分解的项目的细节。
72. 若项目对单个规格太大，帮助用户分解为子项目：独立部分是什么、如何关联、按什么顺序构建。
73. 然后通过正常设计流程头脑风暴第一个子项目。
74. 每个子项目有自己的 spec → plan → implementation 循环。
75. 对适当范围项目，一次一个问题细化想法。
76. 尽可能偏好多选题，但开放式也可以。
77. 每条消息只问一个问题；若主题需要更多探索，拆成多个问题。
78. 聚焦理解：目的、约束、成功标准。
79. 提出 2-3 个不同方案及权衡。
80. 以对话方式呈现选项，带推荐和理由。
81. 以推荐选项开头并解释为什么。
82. 无情 YAGNI：从每个方案和设计中移除不必要功能。
83. 一旦相信理解要构建什么，呈现设计。
84. 按复杂度缩放每节：简单几句，细微可 200-300 词。
85. 每节后问是否看起来对。
86. 覆盖：架构、组件、数据流、错误处理、测试。
87. 如果某事不合理，准备好回去澄清。
88. 为隔离和清晰设计：把系统拆成更小单元，每个有清晰目的，通过明确定义接口通信，可独立理解和测试。
89. 对每个单元能回答：它做什么、如何使用、依赖什么。
90. 检查别人不读内部能否理解单元做什么；能否改内部不破坏消费者；不能则改进边界。
91. 使用更小、边界良好的单元，便于推理和可靠编辑；文件变大通常是做太多的信号。
92. 在现有代码库工作：提议变更前探索当前结构，遵循现有模式。
93. 若现有代码有问题影响工作（文件太大、边界不清、职责纠缠），把针对性改进作为设计一部分。
94. 不要提议无关重构，聚焦服务当前目标。
95. 架构路径写已验证设计（spec）到 `docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md`；用户偏好 spec 位置覆盖默认。
96. 如可用，使用 elements-of-style:writing-clearly-and-concisely 技能。
97. 提交设计文档到 git。
98. 规格自审：占位符扫描——修复任何「TBD」、「TODO」、不完整部分或模糊需求。
99. 规格自审：内部一致性——检查部分是否矛盾，架构是否匹配功能描述。
100. 规格自审：范围检查——是否聚焦于单个实现计划，或需分解。
101. 规格自审：歧义检查——任何需求可被两种方式解释？选一个并明确。
102. 内联修复问题，无需重新审查，修复并继续。
103. 规格审查循环通过后，让用户审查书面规格再继续。
104. 用类似消息：Spec written and committed to `<path>`. Please review it and let me know if you want to make any changes before we start writing out the implementation plan.
105. 等待用户回应；如请求变更，做变更并重跑 spec review loop。
106. 只有用户批准后才继续。
107. 调用 writing-plans 技能创建详细实现计划。
108. 不要调用任何其他技能；writing-plans 是下一步。
109. 视觉 companion 是浏览器工具，用于显示 mockup、图表、视觉选项；作为工具不是模式。
110. 接受 companion 意味着它可用于受益于视觉处理的问题，不意味着每个问题都走浏览器。
111. 不要提前提供视觉 companion；等到一个问题真正展示比告诉更清楚——真实 mockup/布局/图表问题，不只是 UI 主题。
112. 第一次发生时，作为单独消息提供，例如：「This next part might be easier if I show you — I can put together mockups, diagrams, and comparisons in a browser tab as we go. It's still new and can be token-intensive. Want me to? I'll open it for you.」
113. 该 offer 必须自己的消息，只包含 offer，无澄清问题、总结或其他内容。
114. 等待用户回应；如接受，用 `--open` 启动服务器，让浏览器自动打开到第一屏。
115. 如拒绝，继续纯文本且不再提供，除非他们提出。
116. 即使用户接受，对每个问题决定用浏览器还是终端；测试：用户通过看比读更理解吗？
117. 对本质视觉内容使用浏览器：mockup、wireframe、布局比较、架构图、并排视觉设计。
118. 对文本内容使用终端：需求问题、概念选择、权衡列表、A/B/C/D 文本选项、范围决策。
119. UI 主题的问题不自动是视觉问题；概念问题用终端，视觉问题用浏览器。
120. 如用户同意 companion，继续前读详细指南：`skills/brainstorming/visual-companion.md`。

适用边界 · 注意事项

• 不要把 spike 产出的代码当作可保留的实现；若想保留，需重新分类并获批准。
• 不要在未获得对应路径批准前开始实现，包括写产品代码、搭脚手架、安装产品依赖或创建外部项目。
• 不要用「太简单」或「我熟悉这类应用」跳过设计/批准；新项目没有现有流程，应走 architectural 路径。