implement-publish

実装と公開

仕様に基づいて実装し、独立したローカルレビューを経て、プルリクエストを1件だけ公開します。公開とは、レビュー済みブランチをプッシュし、そのプルリクエストを作成または更新することを意味し、マージやデプロイは行いません。公開後のレビューは review-code-publish が担当します。

ユーザーの指示、指定された実装スキル、リポジトリの慣例の範囲内で、実装方法、調査、作業順序、ツール、追加検証を選択できます。

提出内容を確定する

変更が対応するフォージ、ソースリポジトリとターゲットリポジトリ、ベースブランチ、およびすべての課題、チケット、記述された仕様を確定します。リクエスト、ブランチ、コミットから推測されるものも含めます。docs/agents/issue-tracker.md など、リポジトリのトラッカー設定がある場合は使用します。外部への書き込みを行う前に重大な曖昧さを解消し、その間も独立して進められるローカル作業は続行します。

review-code スキルがインストールされていない場合は、実装を始める前に missing-dependency: review-code と報告します。

プルリクエストのヘッドに適したブランチで作業し、ベースブランチでは作業しません。課題のステータス、ラベル、担当者には手を加えません。

実装し、証拠を記録する

要求された動作を実装してコミットします。影響を受ける動作とその依存先について、リポジトリで文書化されているチェックを実行します。変更のリスクに応じて追加のチェックや受け入れ確認を選び、影響範囲が不確かな場合は、より広範囲に検証します。

review-code の references/rubric.md 内にある「Supplied checks」セクションに、簡潔な証拠の要約を記録します。このセクションの形式と再利用ルールは review-code が管理します。各受け入れ確認について、基準、方法、結果を記載し、必要な作業のうち未実施のものがあれば、その理由も記載します。変更後は、引き続き有効な証拠と差し替えられた証拠を更新します。要約を埋めることだけを目的にチェックを再実行してはいけません。

ローカルでレビューする

ゲートを通過するまでは、すべてローカルに留めます。

実装に関するやり取りを見ていない、コンテキストが新しいレビュアーを使用し、review-code の検証担当を呼び出せるようにします。呼び出し元が指定したレビュアーのティアを尊重し、すべての継続レビューで選択したティアを維持します。

レビューをディスパッチまたは継続する前に、自分がアクティブな状態を保ったまま完了結果を受け取れる経路を選びます。フォアグラウンドで結果を受け取るか、ディスパッチ後にサポートされている待機操作を行います。受領確認やエージェント ID は完了を意味しません。そのような経路がない場合は、何もディスパッチせず、フェーズ、不足している操作、保留中の作業を示して review-wait-unavailable を報告します。経路を確保するためにグローバルなランタイム設定を変更してはいけません。

レビュアーには、ローカルの base-to-head 範囲に対して mode: one-shot で review-code を呼び出すよう指示します。リポジトリ、明示的な base とコミット済みの head、すべての仕様ソース、ならびに不足点を含むエビデンスの概要を提示します。実装の根拠や正しさに関する主張は含めず、観察事項と成果物を示します。完了ステータス、カバレッジ、および record.json、payload.json、batch.json、report.md のパスを必須とします。

report.md を読み、受け入れる前にゲートに基づいてレコードを検証します。受け入れた各レコードの絶対パスを順番どおりに保持します。コードと仕様に照らして指摘事項を評価し、妥当な不具合は修正、検証し、コミットします。指摘を退けるのはエビデンスがある場合に限ります。異議のある must-fix がある場合は、レビューが解決するまで先に進めません。

修正後や新しい情報が得られた後は、コードを変更していない場合も含め、完了済みのレビュアーを再開するか、別の独立したレビュアーを使ってレビューを継続します。最新の受け入れ済みレコードを prior_record として指定し、変更されていない base と仕様ソース、以前にレビューしたコミット SHA と最終コミット SHA、修正した指摘 ID、保持または無効化の理由を添えた更新済みエビデンスを提示します。

レビュー範囲、指摘の分類、引き継がれる確認事項、未解決の質問、検証の計上は review-code が管理します。検証の許容量は継続レビュー間で共有されます。ワーカーの変更、作業の失敗、修復のいずれも新たな許容量を与えず、レビュアーを交代しても保留中の作業を回避できません。review-code-record/1 より前のレコードは prior_record にできません。その場合は prior_record を指定せず、base-to-head のレビュー全体を依頼し、カバレッジに以前のレコードを記載させます。

ゲート

返された各レコードを、レビュー対象のコミット済み head、順番どおりに受け入れたすべてのレコード、およびそのレコード自身に対して検証します。

python3 <skill root>/scripts/render_review.py --check --head <committed head> --lineage <each accepted record> --lineage <candidate record> <private-dir>

<skill root> は、レコードの record.paths.skill_root です。終了コードが 0 以外の場合は、レポートがない、レコードが無効、別の head を対象にしている、または継続レビューが以前に受け入れたレコードから分岐していることを意味します。そのレコードを破棄し、最新の受け入れ済みレコードから続行します。

終了コード 0 は、head と履歴に一致する使用可能な成果物があることを示しますが、承認を意味するものではありません。最終レコードのチェックで、push するコミットが指定され、status Approved と coverage complete が出力された場合にのみ公開します。つまり、必須のレビュー作業、エビデンス、検証がすべて完了している必要があります。

Needs Information、Changes Requested、Incomplete のいずれの場合も公開してはいけません。レビュアーが必要とする情報を解決し、レビューを続行します。質問に未回答のまま公開が許可されることはありません。承認後も consider の指摘は残すことができます。その後にコミットがあれば、レビューが必要です。ゲートを満たせない場合は、その理由を報告し、公開前に停止します。

公開

レビュー済みのヘッドをプッシュします。ソースとターゲットのリポジトリおよびブランチが一致するオープンなプルリクエストを探し、その本文を更新するか、新規作成します。レビュー済みのヘッドを対象とする一致したオープンなプルリクエストが正確に1件あることを確認します。

リポジトリのタイトルと本文の慣例に従います。それ以外の場合は、1分以内に読める概要を作成し、空のセクションを省いて ## Why、## Scope、## Tradeoffs、## Blast Radius、## Verification を含めます。すべての仕様ソースと課題を、それぞれの実際の関係に応じてリンクします。部分的な実装の場合は残作業を明記し、完了した課題にはフォージの課題クローズ構文を使うか、その構文がないことを記します。各検証結果について、ヘッド、入力状態、未確認事項を保持します。容量の大きい証拠はリンクし、パフォーマンスに関する主張には変更前と変更後の測定値を示します。

外部への書き込みは、それぞれ1回だけ試みます。結果が不明確な場合は、再試行を1回行う前に対象を読み込みます。その後も失敗が解決しない場合は、書き込みを再試行せず、未解決の失敗として報告します。

最後に、プルリクエストの URL、ヘッドコミット、ブランチ、仕様ソース、レビュー結果、残っている任意の指摘や質問、失敗した事項を記載します。