flriancu/claude-code-setup

要件キックオフ

ユーザーは決定事項を事前に明示的かつ低コストで確定し、レビューされたステップに沿って構築を進めます。ワンショットでの構築は推測を組み込むことになり、後でそれを修正する手間が生じます。また、何も文書化せずに長く沈黙して考えることも同様にユーザーを苛立たせます（「ワンショットは不要、なぜ長い思考が必要？フェーズのあるドキュメントをドラフトしよう」）。したがって、質問と計画を迅速に文書化し、ユーザーに舵取りを任せます。

1. 情報収集（簡潔に）

• 提供されたものを読み取る：ファイル、フォルダ、リンク、画像、以前のチャットやメモ、リポジトリのREADME。既に決定済みの事項を把握し、再度質問しないようにします。
• 入力がまだ不足している場合（「リンクは後で」「写真は後で届く」など）でも、質問は開始し、どの質問がそれに依存するかをマークします。
• まだコードを書いたりファイルを変更したりしないでください。長時間熟考しないでください。質問自体が思考ツールです。

2. 番号付き質問をする

• 1つの番号付きリストで、トピックが多い場合はトピックごとにグループ化します。各質問は1行で、選択肢と推奨するデフォルトを示します。例： 3. インストール場所：C: または D:？推奨：D:。C: はほぼ満杯のため。
• ユーザーは番号で簡潔に回答します（「1. 両方 2. 最新に更新 3. ok」）。各回答を注意深くマッピングしてください。「ok」や「同意」はデフォルトを受け入れることを意味します。「前者」「後者」は選択肢の順序を指します。番号をスキップした場合は「あなたの判断、何を選んだか教えてください」を意味します。
• この取り組みに重要な事項をカバーします：目標と対象者；スコープと明示的な非目標；入力と出力（形式、場所）；制約（プラットフォーム、許可または禁止されるツール、ライセンス、オフライン使用、ハードウェア）；品質基準と受け入れテスト（「どうやって動作確認するか」）；障害時の振る舞い（各パーツが任意の時点で失敗した場合の動作：クラッシュ、接続断、停電、複数ノードのうち1台がダウンした場合）；忠実性（決して変更してはならないもの）；配置場所（リポジトリ、パス、リモート）；納品（誰が何をどの頻度で受け取るか）。
• 回答によって新たな質問が生じた場合にのみ、2回目の短い質問ラウンドを実行します。残りの未確定事項に安全なデフォルトがある場合は質問をやめ、代わりにそれらのデフォルトを列挙します。

3. 契約書を作成する：REQUIREMENTS.md

プロジェクトルートに配置し、プロジェクトが新しい場合はフォルダを作成します。プレーンで短く、日付を入れます：

# <プロジェクト> 要件

合意日 <YYYY-MM-DD>。このファイルは契約書です。変更は日付とともにここに記録されます。

## 目標
## 対象者と用途
## スコープ
## 非目標
## 決定事項
- D-01 <決定内容> (<日付>)
## 機能要件
- FR-01 ...
## 制約および非機能要件
- NFR-01 ...
## 検証
要件ごとに1行：どのように検証され、証拠がどこにあるか。
| ID | 方法（テスト / 検査 / 分析 / デモンストレーション） | 証拠（テストケース、スクリプト、ファイル） |
## 未解決の質問

安定したID（D-xx、FR-xx、NFR-xx）により、後の作業、コミット、レポートで引用できるようになります。ユーザーの回答はユーザー自身の言葉で記録し、より強くしたり弱くしたりするように言い換えないでください。

すべての要件に検証方法と証拠の場所を設定します。4つの方法は要件工学（ISO/IEC/IEEE 29148）の標準的なものです。テストを優先します。要件が検査や分析でのみ確認できる場合（「OSスレッドを直接呼び出さない」「ノードあたりのスケジューリングオーバーヘッドが100マイクロ秒未満」）、そのチェックをスクリプトとして書き、出力をエビデンスとして保存します。これにより、再議論ではなく再実行で証明できます。

4. 計画を書く：フェーズ

要件の隣にPLAN.mdとして配置するか、小規模プロジェクトの場合は「フェーズ」セクションとして記述します。フェーズ0は通常、セットアップか、最もリスクの高い仮定を最初に証明するパイロットです。各フェーズについて、目標、手順、成果物、検証方法、対応する要件IDを記載します。フェーズは一度のレビューで確認できる程度に小さく保ち、計画は途中で調整されることを明記します。

その後停止します。2つのファイルを数行で報告し、最初のフェーズを推奨します。

5. リクエストに応じて1フェーズずつ実行する

• ユーザーが指定したフェーズのみを実行します（「フェーズ0を実行」「フェーズ0と1を実行」「go」）。
• 各フェーズの終了時に、実行した内容、動作確認のエビデンス（実行したコマンド、出力、テスト結果）、計画からの逸脱とその理由、次に行うことを報告します。計画上でそのフェーズを完了とマークします。
• 「進捗確認」は次の意味です：現在のフェーズ、何が完了したか、何が実行中か、何がブロックされているか。
• スコープを変更する新しい要望は、構築する前に日付とともにREQUIREMENTS.mdに追加します。決定を撤回した場合は撤回として記録し、古い行はそのまま残します。
• 途中で見つかったバグは、ユーザーが指示した場合に修正します。それ以外の場合はリストアップします。
• 最後のフェーズが完了したとき、またはユーザーから要請があったとき、ギャップチェックを実行します：要件とコード、テスト、ドキュメント、エビデンスを突き合わせます。各ギャップを要件IDとともに報告し、リクエストに応じて1つずつ修正し、エビデンススクリプトを再実行します。
• 各ステップごとにコミットやプッシュは行いません。フェーズが完了した時点でコミットを提案し、プッシュは求められた場合のみ行います。

バリエーション

• コードを伴わない意思決定（購入、ツール選定）：同じ質問を行い、その後、2つのファイルの代わりに合意された基準に対する短い比較表を作成します。
• 他者のコンテンツ（著者の書籍、クライアントのデータ、録音）：最初に忠実性要件を追加します。コンテンツ内で何も黙って変更されないようにします。すべての変更は提案され、マークされ、承認のために報告されます。