一次性实验验证想法，再决定是否正式构建
当用户想要在正式构建前试探一个想法时使用此技能——验证可行性、比较不同方案、或发现文档无法解答的未知问题。实验天生是可抛弃的。一旦它们完成了探索使命，就可以扔掉。
当用户说"让我试试这个"、"我想看看X是否可行"、"实验一下"、"在正式投入Y之前"、"Z的快速原型"、"这甚至可能吗？"或"比较A和B"时，加载此技能。
writing-plans / plan 技能如果 gsd-spike 显示为同级技能（通过 npx get-shit-done-cc --hermes 安装），当用户想要完整GSD工作流时，优先使用 gsd-spike：持久的 .planning/spikes/ 状态、跨会话的MANIFEST追踪、Given/When/Then结论格式，以及与GSD其他部分集成的提交模式。本技能是为没有（或不想用）完整系统的用户准备的轻量级独立版本。
无论规模大小，每个实验都遵循这个循环：
拆解 -> 调研 -> 构建 -> 结论
^__________________________________________|
根据发现迭代
将用户的想法拆解为2-5个独立的可行性问题。每个问题就是一个实验。用Given/When/Then框架以表格形式呈现：
| # | 实验 | 验证内容 (Given/When/Then) | 风险 |
| 001 | websocket-streaming | Given一个WebSocket连接，when LLM流式输出token，then客户端在100ms内收到数据块 | 高 |
| 002a | pdf-parse-pdfjs | Given一个多页PDF，when用pdfjs解析，then可提取结构化文本 | 中 |
| 002b | pdf-parse-camelot | Given一个多页PDF，when用camelot解析，then可提取结构化文本 | 中 |
实验类型：标准型（一个方案回答一个问题）和对比型（同一问题不同方案，共享编号，字母后缀 a/b/c）。
好的实验问题：有明确可行性验证和可观察输出。不好的实验问题：太宽泛、无可观察输出、或只是读读X的文档。
按风险排序。最可能否定想法的实验最先运行。如果最难的部分不可行，就不值得为简单的部分做原型。
跳过拆解仅当用户已经明确知道要实验什么并如此说明时。然后将他们的想法作为单个实验。
展示实验表格。问：按此顺序全部构建，还是调整？让用户在写代码前删除、重排或重新定义。
实验不是不做调研——你调研足够的内容来选择正确方案，然后构建。每个实验简要说明（2-3句话：这个实验是什么、为什么重要、关键风险），列出竞争方案如果有真正选择的话。
| 方案 | 工具/库 | 优点 | 缺点 | 状态 |
选择一个，说明原因。如果2个以上方案可信，在实验内构建快速变体。跳过调研用于纯逻辑无外部依赖的情况。
使用Hermes工具进行调研步骤：web_search、web_extract、terminal。对于没有文档页面的库，通过 read_file 克隆并阅读其 README.md / examples/。如果用户配置了Context7 MCP，也是好来源。
每个实验一个目录。保持独立。
spikes/
├── 001-websocket-streaming/
│ ├── README.md
│ └── main.py
├── 002a-pdf-parse-pdfjs/
│ ├── README.md
│ └── parse.js
└── 002b-pdf-parse-camelot/
├── README.md
└── parse.py
偏向于用户可以交互的东西。实验失败的标志是唯一输出是一行日志说它工作了。用户想要感受实验在工作。默认选择，按优先顺序：可运行的CLI，接收输入并打印可观察输出；演示行为的最小HTML页面；有一个端点的小型Web服务器；用可识别断言测试问题的单元测试。
深度胜于速度。永远不要在一次快乐路径运行后宣布它工作了。测试边界情况。追踪令人惊讶的发现。结论只有在调查诚实的情况下才值得信赖。
避免除非实验特别需要：复杂的包管理、构建工具/打包器、Docker、env文件、配置系统。全部硬编码——这是实验。
构建单个实验的典型工具序列：terminal创建目录，write_file写README和代码，terminal执行并观察输出迭代。
并行对比实验（002a / 002b）——委托。当两个方案可以并行运行且都需要真正的工程时，用 delegate_task 扩展。每个子代理返回自己的结论；你来写对比总结。
每个实验的 README.md 以以下结尾：
## 结论: VALIDATED | PARTIAL | INVALIDATED
### 有效的部分
- ...
### 无效的部分
- ...
### 意外发现
- ...
### 正式构建建议
- ...
VALIDATED = 核心问题得到肯定回答，有证据。PARTIAL = 在约束X、Y、Z下可行——记录这些约束。INVALIDATED = 不可行，因为这个原因。这也是成功的实验。
当两个方案回答同一问题（002a / 002b）时，背靠背构建，然后在最后做对比总结，表格列出维度对比和最终胜者。
如果实验已存在且用户说我接下来应该实验什么，遍历现有目录并寻找：集成风险（两个已验证的实验触及同一资源但独立测试）、数据交接（实验A的输出被假设与实验B的输入兼容从未证明）、愿景缺口（假设但未证明的能力）、替代方案（PARTIAL或INVALIDATED实验的不同角度）。提出2-4个候选作为Given/When/Then。让用户选择。
改编自GSD (Get Shit Done) 项目的 /gsd-spike 工作流——MIT (c) 2025 Lex Christopherson（gsd-build/get-shit-done）。完整GSD系统提供持久的实验状态、MANIFEST追踪，以及与更广泛的规格驱动开发流程的集成；通过 npx get-shit-done-cc --hermes --global 安装。
评论区