implement-plan

実装計画

引き継ぎ

herdr 内（HERDR_ENV=1）では、自分が実装担当者であるか、ここで実装するよう指示されている場合を除き、計画を新しいエージェントに引き継ぎます（orchestrate-agents を参照）。

1. worktree を作成します（use-worktrees を参照）。計画と ADR がコミットされていない場合は、それらを worktree にコピーします。
2. 現在の herdr ワークスペース内の新しいペインで worktree を開き、自分のワーカーとしてタグ付けします（use-worktrees を参照）。そこで自分と同じ種類のエージェントを起動します。計画のパス、不足しているコンテキスト、および「あなたは実装担当者です。このチェックアウトで implement-plan を使用してください。引き継ぎはしないでください。」を伝えます。
3. ブロックされた場合、または質問された場合にのみ介入します。
4. すべてのタスクの実装と検証が完了したと報告されたら、同じ worktree 上の専用タグ付きペインで、同じ手順でレビュアーを起動します。計画のパス、実装担当者のペイン、および「あなたはレビュアーです。implement-plan の Review round に従い、実装担当者と直接やり取りして指摘を解決してください。ファイルは編集しないでください。」を伝えます。
5. レビューが完了したら、レビュアーを終了してペインを閉じます。解決していない意見の相違があれば、ユーザーに伝えます。
6. 実装担当者から PR の報告があったら、ブランチが完全にプッシュされていることを確認し、エージェントを終了してペインを閉じ、worktree を削除し（use-worktrees を参照）、PR を報告します。

それ以外の場合は、自分で実装します。

実装

1. 計画とその ADR を読みます。不明な点や誤りと思われる点があれば、作業を始める前に質問します。
2. タスクを順番に進めます。余分なレイヤー、オプション、起こり得ないケースへの防御コードを加えず、各タスクを満たす最もシンプルなものを作ります。
3. 複雑なタスクや並行して進められるタスクは、サブエージェントに引き継ぎます。
4. 重要な動作を保護する場合に限り、テストを追加または更新します（awesome-tests を参照）。
5. すべてのタスクを自分で検証します。計画に記載されたチェックを実行し、UI があるものは agent-browser を使って実際のブラウザーで確認します。チェックに必要なサービスやテストデータを用意し、テストをユーザーに任せないでください。
6. 計画ファイルを最新の状態に保ちます。計画から逸脱した場合は、計画を更新するか、判断が変わった場合は新しい ADR を作成します。
7. すべてのタスクが完了したら、レビューを受けます。計画を引き継いだ場合は、準備ができたと伝えてレビュアーを待ちます。それ以外の場合は、自分でレビュアーを起動します（専用の herdr ペイン、または herdr 外のサブエージェント）。
8. 変更内容、検証方法、レビューでの変更点を記載したプルリクエストを作成し、コミットしてプッシュします。
9. 開発サーバーを停止し、ブラウザーを閉じます。worktree は作成した人に引き継ぎます。

PR のリンク、検証内容、レビュー結果、未解決事項を報告します。

レビュープロセス

すべての実装に対し、作成者には見えにくい問題を見つけるため、実装に関与していないエージェントが一度レビューします。コードをむやみに増やすことが目的ではありません。

• レビュアー： 計画、ADR、差分全体、およびそれが組み込まれるコードを読みます（code-review を参照）。チェックを実行し、ユーザーの立場で問題を起こそうとします。実際に起こる可能性の高い問題と、取り除ける複雑さだけを報告し、それぞれに具体的な失敗シナリオ（または取り除ける複雑さ）と修正方法を示します。まれなエッジケース、推測に基づく堅牢化、スタイルの好みは指摘しません。
• 実装担当者： 各指摘を吟味し、安易に受け入れないでください。実際の問題は最もシンプルな方法で修正します。問題に見合わない複雑さを増やす修正は、理由を添えて却下します。
• 指摘は直接やり取りして解決します。未解決の指摘はユーザーに伝えます。大幅な修正が行われた場合に限り、再レビューを実施します。