Spike

アプローチを抽象的に比較することはできません。それぞれを実装し、実際のコードでどう感じるか確認してから判断します。これにより推測を排除し、証拠に置き換えます。

なぜこれがうまくいくか

設計についての議論は仮定の段階で立ち往生します。各アプローチを実装することで推測を排除できます。正確な行数、実際の依存関係の変化、隠れた制約を明らかにする実際のリント/コンパイルエラー、そしてコードを読むときの実感を得られます。

アクティベーション時

1. 選択 — N個のアプローチを選びます。
2. 準備 — ベースブランチと変更するファイルを特定します。
3. 実装 — アプローチごとに1つのブランチを作成し、完全に動作させます。
4. 検証 — 各ブランチがコンパイルされ、リントに合格することを確認します。
5. 比較 — 判別的な観点から並べて比較する表を作成します。

フェーズ1：選択

正確にN個のアプローチを特定します。情報源には /synthesize の出力、/brainstorm のランキング、ユーザー指定のリスト、または自由形式の説明が含まれます。

ユーザーがどのアプローチを実装するか指定していない場合は、AskUserQuestion で確認します。

各アプローチについて、ブランチ名（spike/<descriptive-name>）、実装するオプション、1行の要約を定義します。実装前に計画を提示します。

ブレインストーミングのオプションの中には相補的なものがあります。競合するのではなく、相互に強化する場合は、1つのブランチに組み合わせます。

フェーズ2：準備

1. ブランチ全体で変更されるすべてのファイルを読みます。1回読み込むだけで — すべてのブランチの同じ開始地点です。
2. ベースブランチをメモします — すべてのスパイクブランチはここからフォークします。
3. 検証コマンドを特定します（make format lint、cargo clippy、npm run lint など）。不明な場合は確認します。

フェーズ3：実装

ブランチを順序立てて進めます（同じファイルを変更します）。各ブランチについて、ベースブランチをチェックアウトし、spike/<name> を作成し、完全に実装します。

完全に実装するとは、すべてのコード変更、インポートと呼び出し箇所の更新、ドキュメントコメントの更新を意味します。スタブやTODOはなく、チームがこのアプローチを選んだ場合にマージできるほど完全な実装が必要です。

エラーが発生したら対処します。リント失敗とコンパイルエラーは予期されたものです。これらは隠れた制約を明らかにします。修正してメモを取り、比較の際に記録します。

すべてのブランチで同じ労力を費やします。1つのブランチをより洗練させるために余分な時間を使うと、比較に偏りが生じます。

フェーズ4：検証

各ブランチを実装した後、検証コマンドを実行します。失敗を修正します（修正はデータです）。クリーンになるまで再実行してからコミットします。すべてのブランチが次へ進む前にコンパイルされ、リントに合格している必要があります。

フェーズ5：比較

並べて比較する表を提示します。判別的な観点を選びます。すべてのブランチが観点で同じスコアを得ている場合は、それを削除します。適切な観点は一般的なチェックリストではなく、問題領域から導き出されます。

勝者を選ばないでください。比較表が成果物です。ユーザーは完全な全体像を持つようになります。次の質問をします：

"これらをどうしたいですか？"

アンチパターン

• 実装の代わりにスタブを使う — 「TODO: これを実装する」はスパイクではありません。ポイントは実際のコードを感じることです。
• 検証をスキップする — コンパイルされないブランチは公平に比較できません。
• 汎用的な比較観点を使う — 「複雑さ：中」は役に立ちません。具体的で測定可能な観点を使用します。
• 勝者を選ぶ — 人間に判断させます。実装にかかる労力の障壁を除去しました。今は彼らの判断を適用させます。
• ベースへの復帰を忘れる — 各ブランチは同じベースからフォークします。常にブランチ間でベースをチェックアウトしてください。

デフォルト

• -n が指定されていない場合は N = 4
• ブランチプリフィックス：spike/
• N > 6 の場合は、実装時間が過剰になる可能性があることを警告しますが、従います

---

ユーザーは比較するアプローチを持っています。N個のスパイクブランチを実装します。フェーズ1：アプローチの選択から始めます。