限时技术/设计 Spike…

适用场景：一次限时（time-boxed）的技术或设计可行性探索已结束，需要把原始问题、做法、有证据的发现和明确的「做/不做」建议记录下来供团队决策。

适用场景

解决思路

1. 清晰陈述问题：写明这次 Spike 要回答的具体问题；好的 Spike 问题应当聚焦、且在当前时间盒内可回答。如果问题在过程中发生了变化，把原始版本和最终版本都记录下来。
2. 定义时间盒：记录分配的时间（例如 3 days）与实际花费的时间；如果超出时间盒，说明原因并注明还有哪些未完成的工作。
3. 描述做法：说明尝试了什么、按什么顺序尝试、以及为什么这样选；让后来的读者能理解方法论，并判断是否考虑过其他可选方案。
4. 用证据呈现发现：记录学到了什么，并配上具体证据——代码示例、性能基准测试数据、截图或 API 响应；区分「已验证的结论」和「仍需继续验证的假设」。
5. 给出明确建议：直接回答最初的问题——继续推进、不推进、或带条件推进；不要含糊其辞，团队需要可执行的指引。
6. 记录产出物：链接到 Spike 期间创建的代码、原型、图表或文档；这些产出物通常在总结之外仍有长期价值。
7. 记录遗留问题：写明这次 Spike 没有回答的问题，以及可能还需要哪些额外调研。
8. 按模板输出：使用 references/TEMPLATE.md 中的模板组织结果，完整的 Spike Summary 要填满模板的每个章节——Overview、Background、Approach、Findings、Recommendation、Artifacts、Open Questions 和 Follow-up Items。
9. 定稿前核对：原始问题是否已清晰陈述。
10. 定稿前核对：时间盒是否已记录（分配时长 vs. 实际时长）。
11. 定稿前核对：发现是否有证据支撑，而不只是观点。
12. 定稿前核对：建议是否直接回答了该问题。
13. 定稿前核对：产出物（代码、图表）是否已链接或附上。
14. 定稿前核对：遗留问题是否已指出剩余的未知项。

适用边界 · 注意事项

• 要记录的是由此得出的架构决策本身——应使用 develop-adr：Spike 负责提供信息，ADR 负责做决策。
• 这次探索属于用户研究、而非技术或设计可行性验证——应使用 discover-interview-synthesis。
• 想提出 Spike 指向的解决方案——应使用 develop-solution-brief；另外若 Spike 还没真正做过，先设定时间盒并执行探索，本技能只负责记录结果。