spike

用途：在真正投入构建前，用一次性实验验证可行性、比较不同方案、暴露仅靠调研无法回答的未知问题。Spike 按设计即弃，验证完即可丢弃。

触发场景：用户说“让我试试这个”“看看 X 能不能行”“先 spike 一下”“在确认做 Y 之前”“快速原型”“这到底可不可行”“对比 A 和 B”。

不适用：答案可从文档或源码得知时只做调研；任务属于生产路径时改用 plan 技能；想法已验证则直接实现；若已安装完整 GSD 系统，或存在兄弟技能 gsd-spike（通过 npx get-shit-done-cc --hermes 安装），需要持久化 .planning/spikes/ 状态、MANIFEST 跨会话跟踪、Given/When/Then 结论格式时应优先用 gsd-spike。

核心循环：decompose → research → build → verdict，并根据发现迭代。

分解：把想法拆成 2-5 个独立可行性问题，每个问题一个 spike，用 Given/When/Then 表格呈现并标注风险，按风险排序，最可能推翻想法的先做。类型分 standard（单一方案回答一个问题）与 comparison（同一问题不同方案，编号加 a/b/c 后缀）。若用户已明确想验什么，可跳过分解。
对齐：多 spike 时先展示表格，询问是否按此顺序全部构建，允许用户删除、重排或改写。
研究：每个 spike 先写 2-3 句简述并列出候选方案对比（工具、优缺点、维护状态），说明选择理由；无外部依赖的纯逻辑可跳过。可用 web_search、web_extract、terminal 检查已安装版本，或克隆仓库读 README 与示例。
构建：每个 spike 一个独立目录（spikes/NNN-名称/），含 README.md 与代码。优先做成可交互形态：可运行 CLI、最小 HTML 页、单端点小型服务器或带断言的单测。注重深度，不只跑通一条顺利路径，要测边界情况；除特殊需要外避免复杂包管理、构建工具、Docker 与配置文件，一切硬编码。并行对比型 spike 可通过 delegate_task 分发，各自返回结论后做汇总比较。
结论：README 结尾写 Verdict: VALIDATED | PARTIAL | INVALIDATED，并列出有效之处、无效之处、意外发现与对正式实现的建议。VALIDATED 表示核心问题得到有证据的肯定回答；PARTIAL 需记录约束条件；INVALIDATED 也是成功的 spike。对比型 spike 最后做 head-to-head 表格比较。

Frontier 模式：已有若干 spike 后，可遍历目录寻找集成风险、数据交接、愿景缺口与替代方案，提出 2-4 个 Given/When/Then 候选供用户选择。

技能介绍