build-loop-claude-code

Claude Code Build Loop

品質ゲートを設けた機能開発：単に「コンパイルできる」だけではリリースしません。すべての変更を段階ごとにビルドし、レビューし、エンドツーエンドでテストして、ユーザーに「完了しました」と伝える前に修正します。

作業の起点

• プランファイルがある場合（ロードマップ、リファクタリング計画、または - [ ] チェックボックス付きのタスクリスト。リポジトリを検索してください）：最初の未完了タスクに取り組みます。タスクには意図的に順序が付けられているため、先のタスクに飛ばしてはいけません。プランが仕様書を参照している場合は、現在のタスクに関連するセクションだけを読んでください。
• プランがない場合（または依頼がプランの対象外の場合）： ユーザーのプロンプトに基づいて作業します。検証可能な目標として言い換え、成功基準を2〜4個示し、構築を始める前に1回のメッセージでスコープを確認してください。

ループ

タスクごと（または依頼された機能ごと）に実行します。すべてのステップに合格するまで先に進まないでください。

1. 構築。 タスクで指定された内容を正確に実装します。要件を満たす最もシンプルな実装を選び、変更は必要最小限にとどめ、推測でスコープを広げないでください。既存のプロジェクト規約に従います。

2. レビュー。 変更したコードに対して /review を実行します。変更が認証、支払い、ユーザー入力、またはデータアクセスに関わる場合は、/security-review も実行します。対象範囲内の指摘事項（バグ、セキュリティ上の問題、エッジケース、パフォーマンス、変更したファイルのスタイル）をすべて修正します。プロジェクトにデザインシステムの仕様（デザイントークンファイル、DESIGN.md、テーマ設定）がある場合は、UI の変更がそれに準拠しているか確認します。トークンを迂回するハードコードされた色、タイポグラフィ、余白は使いません。未変更のコードに既存の問題があれば、黙って修正せず、報告時に記載します。問題がなくなるまで /review を再実行します。指摘がタスクまたは仕様と矛盾する場合は、仕様を優先し、相違点を報告してください。

3. エンドツーエンドでテスト。 タスクの検証手順（または成功基準）を実行します。テストスイート全体を実行し、以前合格していたテストがすべて引き続き合格することを確認します。新しいロジックにはテストを追加します。次に、ユーザーが使うのと同じように機能を実際に試します。アプリを起動し、空、読み込み中、エラーの各状態を含めて、実際の操作フローを一通り確認します。

4. 修正。 テストで見つかった問題は、ループに戻して修正 → /review → 再テストの順に対応します。失敗しているタスクを完了扱いにしてはいけません。アプリが壊れた状態で次のタスクを始めてはいけません。

5. 続行。 タスクに - [x] を付け、プラン内の進捗・ステータス行を更新してから、依頼されたスコープが完了するまで次のタスクに進みます。

6. 報告。 完了したら、実装した内容とプランの進捗、修正したレビュー指摘事項と保留にした事項、検証方法（テストと実行したフロー）、次にユーザーの対応が必要なことを伝えます。不安定な箇所や一部しか検証できていない点があれば、正直に報告してください。

ルール

• レビューを省略した作業、またはテストしていない作業は未完了です。
• プラン上の決定を蒸し返さないでください。タスクが不適切に思える場合は、推測せず、具体的な質問を1つしてください。
• どのタスクにも含まれていない作業が見つかった場合は、その内容を提示してタスクを提案してください。黙ってスコープを広げてはいけません。