Spike（スパイク）
このスキルは、ユーザーが実際の構築に着手する前にアイデアの感触を確かめたい場合に使用します。実現可能性の検証、アプローチの比較、調査だけでは分からない未知の要素を明らかにすることが目的です。スパイクは設計上、使い捨てです。役目を終えたら捨ててください。
ユーザーが次のように言った場合にこのスキルを読み込んでください：「これ試してみよう」「Xが動くか見てみたい」「スパイクして」「Yにコミットする前に」「Zのクイックプロトタイプ」「これって可能なの？」「A vs Bを比較して」。
使用すべきでない場合
- 答えがドキュメントやコードを読めば分かる場合 — 構築せずに調査だけで済ませてください
- 作業が本番パスである場合 —
planスキルを使用してください - アイデアがすでに検証済みの場合 — すぐに実装に進んでください
完全なGSDシステムがインストールされている場合
gsd-spike が兄弟スキルとして存在する場合（npx get-shit-done-cc --hermes でインストール済み）、ユーザーが完全なGSDワークフロー（永続的な.planning/spikes/状態、セッションをまたぐMANIFEST追跡、Given/When/Then形式の判定、GSDの他の部分と統合されたコミットパターン）を望む場合は、gsd-spike を優先してください。このスキルは、完全なシステムを持っていない（または望まない）ユーザー向けの軽量スタンドアロンバージョンです。
コアメソッド
規模に関係なく、すべてのスパイクは次のループに従います：
分解 → 調査 → 構築 → 判定
↑__________________________________________↓
発見に基づいて反復
1. 分解
ユーザーのアイデアを 2～5個の独立した実現可能性に関する質問 に分解します。各質問が1つのスパイクです。これらをGiven/When/Thenフレームで表にまとめて提示します：
| # | スパイク | 検証内容（Given/When/Then） | リスク |
|---|---|---|---|
| 001 | websocket-streaming | WebSocket接続で、LLMがトークンをストリーミングするとき、クライアントが100ms未満でチャンクを受信する | 高 |
| 002a | pdf-parse-pdfjs | 複数ページのPDFで、pdfjsで解析したとき、構造化テキストが抽出可能 | 中 |
| 002b | pdf-parse-camelot | 複数ページのPDFで、camelotで解析したとき、構造化テキストが抽出可能 | 中 |
スパイクの種類：
- 標準 — 1つの質問に1つのアプローチで答える
- 比較 — 同じ質問に異なるアプローチで答える（共通番号、文字サフィックス
a/b/c）
良いスパイク質問： 観測可能な出力を伴う具体的な実現可能性。 悪いスパイク質問： 広すぎる、観測可能な出力がない、または単に「Xについてのドキュメントを読む」だけ。
リスク順に並べます。 アイデアを最も否定しそうなスパイクを最初に実行します。難しい部分が機能しない場合、簡単な部分のプロトタイプを作成しても無意味です。
ユーザーがスパイクしたい内容を正確に把握しており、そう明言している場合にのみ分解をスキップします。その場合は、ユーザーのアイデアを1つのスパイクとして扱います。
2. 調整（複数スパイクのアイデアの場合）
スパイクテーブルを提示します。質問：「この順序ですべて構築しますか？それとも調整しますか？」 コードを書き始める前に、ユーザーにスパイクの削除、並べ替え、再構成を任せます。
3. 調査（スパイクごとに、構築の前）
スパイクは調査不要というわけではありません — 適切なアプローチを選択するのに十分な調査を行い、その後構築します。スパイクごと：
-
説明。 2～3文：このスパイクの内容、重要性、主要なリスク。
-
競合アプローチの提示（実際に選択肢がある場合）：
アプローチ ツール/ライブラリ 長所 短所 ステータス ... ... ... ... メンテナンス中 / 非推奨 / ベータ版 -
1つを選択。 その理由を述べます。2つ以上が信頼できる場合は、スパイク内でクイックバリアントを構築します。
-
外部依存関係のない純粋なロジックの場合は調査をスキップします。
調査ステップにはHermesツールを使用します：
web_search("python websocket streaming libraries 2025")— 候補を見つけるweb_extract(urls=["https://websockets.readthedocs.io/..."])— 実際のドキュメントを読む（マークダウンを返す）terminal("pip show websockets | grep Version")— プロジェクトのvenvに何がインストールされているか確認する
ドキュメントページがないライブラリの場合、read_file を使用してクローンし、README.md / examples/ を読みます。Context7 MCP（ユーザーが設定している場合）も優れた情報源です — mcp_*_resolve-library-id その後 mcp_*_query-docs。
4. 構築
スパイクごとに1つのディレクトリ。スタンドアロンにします。
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ページ
- 1つのエンドポイントを持つ小さなWebサーバー
- 認識可能なアサーションで質問をテストする単体テスト
速度よりも深さが重要。 1回のハッピーパスの実行後に「動作します」と宣言しないでください。エッジケースをテストし、驚くべき発見を追及してください。判定は、調査が正直に行われた場合にのみ信頼できます。
避けること — スパイクが特に必要とする場合を除き、複雑なパッケージ管理、ビルドツール/バンドラー、Docker、envファイル、設定システム。すべてハードコード — それはスパイクです。
1つのスパイクを構築する — 典型的なツールシーケンス：
terminal("mkdir -p spikes/001-websocket-streaming")
write_file("spikes/001-websocket-streaming/README.md", "# 001: websocket-streaming\n\n...")
write_file("spikes/001-websocket-streaming/main.py", "...")
terminal("cd spikes/001-websocket-streaming && python3 main.py")
# 出力を観察し、反復する。
並列比較スパイク（002a / 002b） — 委任。 2つのアプローチを並行して実行でき、両方に実際のエンジニアリング（10行のプロトタイプではない）が必要な場合、delegate_task で作業を振り分けます：
delegate_task(tasks=[
{"goal": "002a-pdf-parse-pdfjs を構築: ...", "toolsets": ["terminal", "file", "web"]},
{"goal": "002b-pdf-parse-camelot を構築: ...", "toolsets": ["terminal", "file", "web"]},
])
各サブエージェントは独自の判定結果を返します。あなたが直接対決の比較を記述します。
5. 判定
各スパイクの README.md は次の内容で締めくくります：
## 判定: VALIDATED | PARTIAL | INVALIDATED
### うまくいったこと
- ...
### うまくいかなかったこと
- ...
### 驚き
- ...
### 実際の構築への推奨事項
- ...
VALIDATED = コアとなる質問に「はい」と証拠付きで回答された。 PARTIAL = 制約X、Y、Zの下で動作する — それらを文書化する。 INVALIDATED = この理由で動作しない。これは成功したスパイクです。
比較スパイク
2つのアプローチが同じ質問（002a / 002b）に答える場合、それらを連続して構築し、最後に直接対決の比較を行います：
## 直接対決: pdfjs vs camelot
| 次元 | pdfjs (002a) | camelot (002b) |
|-----------|--------------|----------------|
| 抽出品質 | 9/10 構造化 | 7/10 テーブル限定 |
| セットアップの複雑さ | npm install, 1行 | pip + ghostscript |
| 100ページPDFのパフォーマンス | 3秒 | 18秒 |
| 回転テキストの処理 | いいえ | はい |
**勝者:** 私たちのユースケースではpdfjs。後でテーブル優先の抽出が必要になった場合はcamelot。
フロンティアモード（次にどのスパイクを行うかの選択）
すでにスパイクが存在し、ユーザーが「次にどのスパイクをすべき？」と言った場合、既存のディレクトリを確認して以下を探します：
- 統合リスク — 2つの検証済みスパイクが同じリソースに触れているが、独立してテストされた
- データの受け渡し — スパイクAの出力はスパイクBの入力と互換性があると想定されたが、証明されていない
- ビジョンのギャップ — 想定されているが証明されていない能力
- 代替アプローチ — PARTIALまたはINVALIDATEDのスパイクに対する別の角度
2～4個の候補をGiven/When/Then形式で提案します。ユーザーに選択させます。
出力
- リポジトリルートに
spikes/（またはユーザーがGSD規約を使用している場合は.planning/spikes/）を作成 - スパイクごとに1つのディレクトリ：
NNN-descriptive-name/ - 各スパイクの
README.mdには、質問、アプローチ、結果、判定を記載 - コードは使い捨てにすること — 「本番用にクリーンアップ」に2日かかるスパイクは悪いスパイクです
帰属
GSD（Get Shit Done）プロジェクトの /gsd-spike ワークフローから改変 — MIT © 2025 Lex Christopherson (gsd-build/get-shit-done)。完全なGSDシステムは、永続的なスパイク状態、MANIFEST追跡、およびより広範な仕様駆動開発パイプラインとの統合を提供します。インストール：npx get-shit-done-cc --hermes --global。