prototype-question

プロトタイプ

Matt Pocock のコミット 3cca18b368ae95cdbdebbff572ccafa662551015 における prototype スキル（MIT）を基にしています。観測可能な不確実性に基づく振り分けは、Cursor のコミット 93b00b89ef425a9c1bac0d0b317dfc49c930ac99 における poteto-mode プロトタイプ用プレイブック（MIT、Copyright (c) 2026 Cursor）を基にしています。

プロトタイプとは、記述された1つの問いに答えるための、使い捨てのコードです。shape-design からスパイクを委任された場合は、証拠と判定をそのワークフローに返します。結果として得られる本番環境向けの判断は shape-design が担います。選択された UI バリアントは、本番環境への実装が承認されたことを意味しません。判定を保持し、通常の設計引き継ぎ手順で返してください。

成果物の分類と承認の境界については、planning-contract スキル（契約バージョン：1）を読み込んでください。インストールされていない場合は、継承したルールや独自に作ったルールに基づいて先に進まず、作業を停止して planning-contract のインストールを依頼してください。依存関係が自動的に解決されると決めつけてはいけません。調査レポートを長期保存する場合は、プロジェクトの調査ディレクトリ（project/research/、旧形式は docs/research/）に調査証拠として保存し、所管する設計からリンクしてください。仕様ディレクトリには保存しないでください。調査の承認は、プロトタイプのコードを残すことも、製品を実装することも許可しません。

観測可能な不確実性と、ユーザーが決定すべき事項を分けてください。動作、タイミング、レイアウト、互換性、出力、パフォーマンスに関する問いは、観測可能な不確実性です。ユーザーに尋ねるのではなく、プローブを作成して実行し、答えを出してください。製品の意図や好み、ユーザーが決めるべきトレードオフ、取り消せない決定については、引き続きユーザーに確認してください。

成果物を選ぶ

• ロジック／状態： references/logic.md を読み、難しいケースを試し、各操作の後に状態全体を表示する最小限の実行可能なハーネスを作成します。
• UI： references/ui.md を読み、1つのルートまたは成果物から比較できる、意味のある違いがある複数のバリアントを作成します。複数のバリアントを作るのは、選択肢が実際にどれも実現可能な場合だけです。通常の問いにはプローブを1つ用意すれば十分です。
• 実現可能性： そのアプローチが機能するかどうかを判断するために必要な、リスクのある接続部分だけを構築します。

問いが曖昧な場合は、確認してください。ユーザーに確認できない場合は、文脈から推測し、その仮定を目立つように明記してください。

制約

1. ファイルと UI に PROTOTYPE と表示します。
2. 恒久的なアーキテクチャを作り上げず、プロトタイプが参考にするコードの近くに置きます。
3. わかりやすい実行コマンドを1つ用意するか、単独で完結するファイルにします。
4. 永続化が問いの対象でない限り、状態はメモリ内に保持します。
5. 本番向けの抽象化、広範なエラー処理、仕上げの作業は省きます。
6. 結果を確認できるよう、入力、出力、関連する状態を明示します。
7. プロトタイプのコードを、黙って本番用に昇格させてはいけません。

実験を終える

以下を報告します。

• 問い；
• 観測した証拠；
• 答えと確信度；
• その答えが覆る条件；および
• 本番環境への推奨事項（ある場合）。

長期保存する場合は、判定をイシューまたは設計資料に残してください。ユーザーが明示的に残すことを選び、実験用の成果物として明確に分離されている場合を除き、メインの変更からプロトタイプを削除してください。