implement-pr

PR を実装する

変更を最後まで担当し、すべてのチェックが通ったレビュー可能な PR にします。完了とは、コードが完成した状態ではなく、マージ可能な PR ができている状態です。

1. 関連する作業を引き受ける

関連する GitHub issue をそれぞれ gh issue view <number> --json title,body,labels,state,comments で読みます。

実装前に、関連するチケットや作業項目のすべてについて、担当者を登録します。トラッカーの担当者フィールドを使い、現在認証されているユーザーをその項目に割り当てます。割り当てができない場合は、トラッカーで明示的に用意されている担当者指定または作業中を示す仕組みを使います。

2. 仕様を明確にする

git fetch origin <base-branch> を実行し、最新のベースブランチから計画を始めます。編集前に、依頼内容、関連チケットや仕様、リポジトリの指示、関連するコードを読みます。作業契約とタスクのチェックリストを、Git の管理対象外ファイルに短く記録します（git check-ignore -q .claude/tasks.md を単独のコマンドとして実行し、終了コードが 0 の場合は .claude/tasks.md に記録します）。項目を完了するたびにチェックを入れ、追加の項目が見つかったら追記します。コンテキストを圧縮した後は、要約ではなくこのファイルを読み直します。すでにコードがある場合（イテレーションループの後に実行された場合）は、既存の差分をもとに作業契約を記述します。作業契約には、次の 5 つの要素を含めます。

• 成果： 実現すべき、観察可能な動作。
• 維持事項： 変更せずに保つべき動作とインターフェース。パフォーマンス改善が目的の場合は、パフォーマンスも含めます。
• 範囲： 依頼によって変更が許可されているファイル、パッケージ、システム。
• 検証根拠： 成果と維持事項を証明する、対象を絞ったチェック。パフォーマンス改善が目的の場合は、ベンチマークも含めます。
• 完了条件： 完了とみなす PR、必須の CI、求められるレビュー状態。

リポジトリや外部に関する不明点は、確認するか、手軽な実験で解決します。既存のパターンに沿うデフォルトを選びます。

3. 必要最小限の完全な変更を実装する

リポジトリの規約に従い、既存の適切な仕組みを再利用します。作業契約で必要とされる動作だけを追加します。変更する最も低い境界から最上位の利用側まで、型を正確に保ちます。

作業契約の未解決事項を解決するために必要な内容を読み、その後編集します。読み進めても計画が変わらなくなったら、調査を終えて実装を始めます。

安定した動作境界に対象を絞ってテストを追加します。削除した動作を記録するだけのテスト、型チェックの重複、実装の詳細を言い換えるだけのテストは追加しません。

視覚的またはインタラクティブな変更では、ブラウザー、Android エミュレーター、または iOS シミュレーターを使い、影響する状態とレスポンシブな動作を確認します。PR に必要な証拠を取得します。

4. 検証する

レビューに出す前に、リポジトリで文書化されている、対象パッケージのテスト、型チェック、リント、ビルドの各コマンドをすべて実行します。集約 check スクリプトから漏れているテストスイートも含めます。PR 用にコマンドと結果を記録します。レビュー後または CI の修正後は、修正の影響を受けるチェックだけを再実行します。CI でマトリックス全体が実行されます。

5. レビューを慎重に行う

レビューの負荷は差分の規模に応じて変わります。各レビュアーは新しいバックグラウンドサブエージェントで、差分コマンド、コントラクトファイルのパス、および担当する観点に必要な情報だけを受け取ります。$spec-reviewには、関連するチケットも渡します。各サブエージェントの完了通知を、作業を再開する合図とします。

基本手順。 git fetch origin <base-branch>をもう一度実行し、origin/<base-branch>との差分を取ります。ワークツリーのローカルベースブランチはリモートより遅れているため、無関係なコミットが差分に含まれてしまいます。レビューする差分はgit diff origin/<base-branch>...HEADです。

深度。 git diff --shortstat origin/<base-branch>...HEADで差分の規模を確認します。

• 軽微： 削除、名前変更、設定の調整、コピーやドキュメントの修正など、動作を追加しない変更が約50行未満の場合です。$bug-reviewのみを実行します。
• 完全： それ以外のすべての場合、および規模にかかわらず、認証、権限、金銭、永続化データやマイグレーション、並行処理、公開インターフェースに触れる差分の場合です。$bug-review、$spec-review、$simplicity-reviewを実行します。

指摘は仮説として扱います。

1. 各指摘をコントラクトと現在のコードに照らして検証します。
2. スコープ内で妥当な指摘はすべて修正します。スコープ外となるのは、差分で変更されていないコードに限られます。差分で追加された行の不具合はスコープ内です。
3. 誤検知とスコープ外の指摘を記録し、変更はそのままにします。
4. 修正によって影響を受けたチェックを再実行します。
5. 修正の根拠となった指摘を出したレビュアーに限り、修正箇所（git diff <reviewed-sha>..HEAD）と、判定を添えた以前の指摘を渡して再依頼します。新たな指摘がなくなるまで、各レビュアーのラウンド上限内で繰り返します。

ラウンド上限。 $bug-reviewと$spec-reviewは3ラウンドです。ただし、セキュリティに関する指摘（認証、権限、データ漏えい、インジェクション）を修正する場合は5ラウンドです。$simplicity-reviewは1ラウンドです。

完了条件：すべての指摘について、判定（修正済み、誤検知、またはスコープ外）がコントラクトファイルに記録されていること。

6. PRを作成して対応を続ける

変更全体をコミットしてプッシュし、$file-prスキルを使ってPRを作成します。

必須のCIとレビュー自動化がすべて成功するまで、$babysit-prスキルを使って対応を続けます。レビューのフィードバックに対処し、各修正によって影響を受ける検証を再実行します。

PRがマージ可能になるか、外部要因によるブロッカーが残るまで作業を続け、PRのURLを出力します。