build-loop-cursor

Cursor Build Loop

品質ゲート付きの機能開発：「コンパイルできた」だけでは出荷しません。すべての変更をビルドし、レビューし、エンドツーエンドでテストして、問題を修正してからユーザーに「完了」と伝えます。

作業の進め方

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

ループ

タスクごと（またはプロンプトで依頼された機能ごと）に実行します。すべての手順を完了するまで先に進んではいけません。

1. **実装。**タスクで指定された内容をそのまま実装します。要件を満たす最もシンプルな実装とし、変更は必要最小限に抑え、推測に基づいてスコープを広げません。既存プロジェクトの規約に合わせます。

2. **レビュー。**変更に対して Cursor の /review を実行します。スコープ内の指摘事項（バグ、セキュリティ上の問題、エッジケース、パフォーマンス、変更したファイルのスタイル）をすべて修正します。プロジェクトにデザインシステムの仕様（デザイントークンファイル、DESIGN.md、テーマ設定）がある場合は、UI の変更が仕様に準拠しているか確認します。トークンを迂回するハードコードされた色、タイポグラフィ、余白を使ってはいけません。変更していないコードに既存の問題が見つかった場合は、黙って修正せず、報告に記載します。問題がなくなるまで /review を再実行します。指摘がタスクや仕様と矛盾する場合は、仕様を優先し、その不一致を報告します。

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

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

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

6. **報告。**完了したら、実装した内容と計画の進捗、修正したレビュー指摘と保留事項、検証方法（テストと確認したフロー）、次にユーザー側で対応が必要なことを伝えます。不安定な部分や検証が部分的な箇所があれば、正直に伝えます。

ルール

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