Claude Code の最初のタスク：プロジェクトの理解から検証可能な変更のコミットまで

初回タスクは少数のファイルで完結し、明確な検証シグナルがあるべきです。例えば、再現手順のあるバグの修正、既存関数へのテスト追加、ドキュメントの一部更新などです。「プロジェクト全体を最適化」でツールの能力を試さないでください。

プロジェクトのルートディレクトリでセッションを起動し、まず Git ワークスペースの現状を確認します。Claude Code は読み取り、編集、コマンド実行が可能ですが、コミットされていない変更とユーザーの既存の修正は保護する必要があります。

まずエントリポイント、依存関係、テスト方法、タスクに関連する既存のパターンを尋ねます。Claude Code は必要に応じてファイルを読み込むので、リポジトリ全体をプロンプトに貼り付ける必要はありません。

具体的なファイルと関数を引用し、不確実な点を説明するよう求めます。これにより、変更前に誤解を修正でき、境界のない探索がコンテキストを占有するのを減らせます。

タスクが複数ファイル、インターフェースの選択、あるいは不慣れなモジュールに関わる場合、Plan モードで探索と編集を分けます。計画では修正対象ファイル、データフロー、リスク、テスト、明確な非対象事項を列挙します。

タイポ修正やログ追加といった単点タスクでは、計画のコストがメリットを上回る可能性があるため、直接実行して構いません。重要なのは計画の強度をリスクに合わせることです。

Claude は「完了したように見える」時点で停止します。再現手順、境界ケース、検証コマンドを一緒に提示することで、同一ラウンド内で実装・チェック実行・失敗に応じた修正が可能になります。

検証条件は観察可能であるべきです：テスト合格、ビルドの終了コードがゼロ、APIが期待するステータスを返す、あるいはスクリーンショットと参照画像の主要な差異が解消されること。

タスク完了後、コミットを直接求める前に Git の差分を確認します。元の未コミット変更の上書き、無関係なフォーマット、新規生成された鍵やビルド成果物がないか確認します。

Claude にまず差分を要約させ、その後新しいコンテキストやサブエージェントで正確性、リグレッション、見落としのみをチェックさせることができます。独立したレビューアーは「何か発見すること」を目的として要件と無関係なリファクタリングを提案すべきではありません。

方向が誤っていることに気付いたら Esc で中断し、制約を補足します。連続2回の修正でも改善しない場合、通常はコンテキストが誤った経路で汚染されていることを示し、/clear の後により精密な最初のプロンプトでやり直すのが適切です。

各プロンプトはチェックポイントを形成し、/rewind で会話を復元するか Claude でツールが生成したファイル状態を編集できます。ただし Bash コマンドや外部プロセスによる変更はファイルチェックポイントの保障範囲外であり、Git が引き続き最終のセーフティネットとなります。