実装前の設計
エージェントは実装が速い反面、設計の劣化に気づきにくいという問題があります。その対策として、コードが存在する前に決定事項について合意しておくことで、各PRがすでに承認された内容と一致するため、レビューが迅速になります。各段階の下書きはあなたが行い、ユーザーがレビューして承認します。
1. 作業の規模を見積もり、段階を選択する
| 作業 | 段階 |
|---|---|
| 中規模機能、影響範囲の限られたリファクタリング | プログラム設計 → スライス |
| 大規模機能、横断的なリファクタリング | アーキテクチャ → プログラム設計 → スライス |
| 新規プロジェクト、マルチリポジトリ、または問題が不明確な場合 | プロダクト → アーキテクチャ → プログラム設計 → スライス |
選択した規模とその理由を1行で述べてください。ユーザーは段階を追加したりスキップしたりできます。
2. 最初にコンテキストを収集する
下書きを始める前に：docs/README.md とそれが指し示す生きたドキュメント、docs/designs/ にある開いている設計、関連するコードとその領域のgit履歴を読んでください。ツールやアプローチの選択については、（ドキュメント、ベンチマーク、既知の問題などを）調査し、ソース付きの具体的な選択肢を提示してください。仮定から設計を始めないでください。
3. 各段階を実行する
docs/designs/YYYY-MM-DD-<slug>.md という設計ファイルを template.md から作成してください（リポジトリにまだない場合は、グローバルルールに従って docs/ レイアウトを最初に設定してください）。各段階について、このスキルのフォルダ内にある該当する段階ファイルを読み、設計ファイルの該当セクションを下書きし、その後停止してください：
product.md: 問題、ユーザー、振る舞い、範囲外architecture.md: コンポーネント、契約、データモデル、制約program-design.md: 型、シグネチャ、ファイルレイアウト、呼び出しフローslices.md: 構築順序、リポジトリ、PR、各スライスのチェック
停止するときは、ユーザーに以下を提示してください：
- 役立つ場合は図と、短い要約（チャットに貼り付けたドキュメント全体ではありません）
- あなたが行った決定と、未解決の質問。番号を付けて、ユーザーが「2: はい」のように答えられるようにしてください
次の段階は、ユーザーがこの段階を承認するまで開始しないでください。ユーザーが何かを変更した場合は、チャットだけでなく設計ファイルも更新してください。
4. スライスごとに構築する
スライス計画が承認された後：
- 一度に1スライスずつ構築し、各スライスは合意されたチェックが成功し、その証拠を示した時点で終了します。
- スライスごとに1つのPR（またはユーザーがPRを使用しない場合はコミット1つ）を作成し、グローバルルールに従って説明します。
- 実装によって設計が誤っていることが明らかになった場合は、静かに設計から逸脱するのではなく、停止して設計への変更を提案してください。変更が合意されたら、設計ファイルを更新します。
- 設計ファイル内でスライスが完了したものにチェックを入れ、後のセッションでそこから再開できるようにします。
5. 完了
最後のスライスが完了したら、結果を生きたドキュメントに反映させ、それらが信頼できる情報源であり続けるようにします：
- リポジトリの
docs/product.md、docs/architecture.mdおよび関連するトピックドキュメント（このスキルの段階ファイルではありません）を更新して、現在のシステムを説明するようにします。グローバルルールのドキュメント作成ルールに従ってください。 - 新しく難解な用語やプロジェクト固有の用語を
docs/glossary.mdに追加します。 - 重要な決定事項はそれぞれ
docs/decisions/NNNN-<slug>.mdノートにします。 - 設計ファイルを完了としてマークし、
docs/README.mdに追加します。その後は書き換えないでください。 - ユーザーに、生きたドキュメントで何が変更されたかを示します。