steve-swanson/review-work

Review Work

このスキルはコードをレビューし、結果をローカルWebページに表示し、ユーザーが承認した修正のみを適用します。承認されたすべての修正は1つのブランチに統合され、1つのプルリクエスト（PR）として送信されます。

メインエージェント（このスキルを実行するチャット）が全体を指揮します。メインエージェントはスコープの設定、各ヘルパーエージェントのモデル選択、全レコードの保存、結果の確認を行います。ヘルパーエージェントは与えられたタスクを実行し、結果を報告します。

このスキルはplan-workおよびexecute-workと連携して動作します。それらを呼び出したり変更したりすることはありません。

ここで使用する用語

• レビューブランチ: レビュー対象のブランチ。PRはこのブランチにマージされます。必ずしもdevelopブランチであるとは限りません。
• レビューコミット: レビューされた正確なコミットSHA。すべての指摘事項はこれを参照します。
• 指摘事項: レビューにおける問題や質問で、R001のようなIDが付与されます。
• ページ: ユーザーが各指摘事項に対して修正する、修正しない、明確化するを選択するローカルWebページ。
• バッチ: 1回の送信クリックで送信される選択のセット。
• ワークツリー: 同一リポジトリの追加チェックアウトを、独自のフォルダに作成したもの。
• コーディネーターブランチ: すべての修正を収集する1つのブランチ（独自のワークツリーを持つ）。これがPRになります。Conventional Branchスタイルで命名し、<type>/<short-description>、小文字、ハイフン区切りとします。レビュー修正は通常fix/（例：fix/session-recovery）とします。すべての修正に適している場合はrefactor/、perf/、docs/、test/、chore/を使用します。ユーザーまたはリポジトリが別の命名規則（例えばAGENTS.mdで指定）を指定している場合は、それに従います。名前にintegrationを含めないでください。
• タスクブランチ: 1つのヘルパーが1つの修正を行うための、短期間のみ使用されるブランチとワークツリー。
• Fast-forwardマージ: ブランチを前方に進めるだけで、マージコミットを追加しないマージ（git merge --ff-only）。
• Run-owned: このレビュー実行によって作成されたもの。クリーンアップはrun-ownedのブランチとワークツリーのみを対象とします。名前が一致しても、所有権の証明にはなりません。

ユーザーが許可したこと

• このスキルを開始すると、レビューレコードとローカルページサービスの使用が許可されます。
• 別のリンクされたマシンにページを表示することを選択すると、そのマシン上で1つのページホストスレッドが許可されます。これはT3プロジェクトReview-work pages（存在しない場合は作成されます）内で動作し、review-work CLIのみを実行します。決してそのマシンのコードには触れません。レビューが完了したら、そのスレッドを終了し、Review-work pagesプロジェクトを削除すること（これによりそのチャットが削除されます）が許可されます。詳細はremote-page.mdを参照してください。他のプロジェクトを削除しないでください。このレビューチャットは決してそのプロジェクト内にはなく、残り続け、最終レポートを受け取ります。
• 修正するを送信する（ページ上、またはチャットでの明確な「修正して」の発言）と、タスクワークツリー、コミット、コーディネーターブランチへのマージ、安全なクリーンアップ、プッシュ、およびレビュー準備完了の1つのPRが許可されます。また、そのPRのマージを監視し、その後、レビューマシン上のこの実行の変更されていないマージ済みコーディネーターワークツリーとローカルブランチを削除することも許可されます。
• ユーザーが「ローカルのみ」または「PRなし」と言った場合は、それに従います。
• PRをマージしたり、自動マージを有効にしたり、デプロイしたりしないでください。

ステップ1: レビュー対象を確定する

1. リポジトリの指示、要件、ステータス、ブランチ、ワークツリーを読み取ります。未コミットの編集や他の実行はそのままにしておきます。
2. リポジトリパス、共有Gitフォルダ、ブランチ、ベース、レビューコミットSHA、ホスト（マシン名）、チャットIDを記録します。
3. git show、差分、またはクリーンな管理チェックアウトを使用して、コミットされたコードのみをレビューします。未コミットのファイルはレビューの対象外です。
4. スコープを選択します。
   • 機能ブランチ: ベースからの差分をレビューします。ベースはユーザー、プロジェクトルール、またはPRメタデータから取得します。それでも不明な場合は質問します。
   • develop: 現在のコード全体をレビューします。開始日や開始コミットを勝手に作成しないでください。
5. 「インラインですか、それともサブエージェントファンアウトですか？」 と質問します（ユーザーがすでに言及していない場合）。
   • インライン: メインエージェントが自分でレビューします。修正は引き続きヘルパーを使用します。
   • ファンアウト: ヘルパーが並行してレビューします。一度に使用する最大のヘルパー数を尋ね、有用な独立した領域に基づいて数を提案します。自動を提供します：容量が許す限り多くの有用なヘルパー。容量が不明な場合は、制限は4であると伝えます。残りはキューに入れます。
6. ワークツリーを作成する前に、現在のワークツリー、ローカルブランチ、管理対象アタッチメントのスナップショットを保存します。この実行が作成するすべてのワークツリー（レビュアー、修正者、ヘルパー、リトライ、およびその子、変更されていないものや放棄されたものも含む）のリストを保持します。cleanup.mdを参照してください。

ステップ2: レビューレコードを開始する

• このスキルのNode 24+およびscripts/review.mjsを使用します。コマンドはruntime.mdにあります。
• initを1回実行し、プロジェクトの外部に保持されるJSON入力ファイルを指定します。返されたレビューフォルダパスを保存して再利用します。再開時には、新しい実行を作成しないでください。
• レコードは<home>/.agents/state/review-work/に保存されます。ランタイムは、他のファイルよりも先にそこに.gitignoreを作成するため、Gitがそれらを拾うことはありません。
• リポジトリの識別子は、クリーンアップされたリモートURLと実際の共有Gitフォルダです。1つのクローンのリンクされたワークツリーは識別子を共有しますが、別々のクローンは共有しません。各実行には独自のIDもあるため、同時に実行されるレビューが混ざることはありません。
• メインエージェントとそのページサービスのみがレコードを書き込みます。データベース、サービス、または状態をワークツリーや.worktreeincludeにコピーしないでください。ヘルパーは結果を返し、メインエージェントがそれらを保存します。ヘルパーは大きなファイルを独自の一時フォルダに配置します。メインエージェントはそれらをインポートします。

ステップ3: モデルを選択し、レビューする

最初にrouting.mdを読んでください。

• メインエージェントは、すべてのレビューおよび修正タスクに対して、正確なモデルおよび努力レベルを選択します。ホストがそれらを提供していることを確認し、タスクを開始する前に選択内容を記録します。ヘルパーは決してJevを呼び出したり、ルート（モデル、努力レベル、オプション）を選択したりしません。メインが正確で固定された割り当てを指示しない限り、ヘルパーは自身のヘルパーを開始しません。
• チャットのモデルファミリーに従います：GPTチャットではGPTモデル。ClaudeチャットではClaude Opus、Sonnet、またはHaiku。
• 常に最新バージョン。 モデルはティア名（Astra、Sol、Terra、Opus、Sonnet、Haiku）で選択されます。各ティアについて、ランタイムはホストのモデルリストに最新バージョンのみを保持し、古いものを拒否します。記憶からバージョンを選択しないでください。ホストのモデルリストを推測よりも信頼してください。モデルIDを発明したり、黙ってプロバイダーを切り替えたりしないでください。ファミリーが不明であるか、必要なモデルがない場合は質問します。
• Jevは最初にモデルを選択し、次にそのモデルがサポートする努力レベルを選択できます。キーが必要です。自分でファイルを開くのではなく、ランタイムの資格情報検出を使用してキーを見つけてください。検出は最初に<home>/.config/jev/credentials.env（推奨名はTYPESAFE_API_KEY）をチェックします。使用可能なホームキーがない場合は、プロジェクトの実際のenv読み込み順序と設定されたアダプターをチェックし、それらのenvファイルパスを渡します。キーファイルやキー値を印刷、保存、またはsourceしないでください。完全な検索順序はrouting.mdにあります。
• 設定されたJev MCPアダプターは、同じ2つの選択を行うことができます。最初に実際のツールスキーマを読み取ってください。jev_routeツールが存在することを想定しないでください。アダプターがない場合は、ランタイムに組み込まれた直接トランスポートを使用します。
• 努力レベルの上限（すべてのモデルに適用）： レビューと計画はextra-highまで、maxまたはultraは不可。修正はHighまで。ランタイムは、Jevまたはメインからの上限を超えるルートを拒否します。
• Jevが存在しないか、使用できない回答を返した場合、メインエージェントが同じルールで決定します。固定のフォールバックテーブルはありません。
  • 読み取り専用のリスト作成作業：Lowで十分です。
  • アルゴリズムや難しい推論：Highまたはextra-high。
  • 不明な場合：High。
  • セキュリティレビューと計画（ログイン、権限、シークレット、暗号、テナント分離、信頼境界）：最新のGPT Astraまたは最新のClaude Opus、extra-high。 そのモデルにextra-highがない場合は、同じモデルを上限未満の最高レベル（少なくともHigh）で使用します。古いバージョンに切り替えないでください。ヘルパーが新しいセキュリティスコープを発見した場合、その部分を停止し、メインに報告します。 計画された実装は、以下の修正ルート（セキュリティ修正を含む）を使用します。
  • インラインレビューで、その一部がより高いルートを必要とする場合： ユーザーにこのチャットのモデルや努力レベルを変更するように依頼しないでください。このチャットは自身の努力レベルを確認または設定できません。その部分（例えばセキュリティチェック）を1つのレビューヘルパーに渡し、開始時にヘルパーの正確なモデルと努力レベルを設定します（Claude CodeではAgentツールのmodelとeffort、T3ではdelegate_taskオプション）。最初にルートを記録します。ヘルパーは指摘事項を返します。メインエージェントはそれらを保存します。ホストが必要なモデルと努力レベルでヘルパーを開始できない場合にのみ、ユーザーに質問します。その場合、ギャップを説明し、このチャットのモデルを維持するオプションを提供します。その選択をこのレビューのために一度記録し、再度質問しません。これにより、ファンアウトヘルパーのルールが緩和されることはありません。
• 動作とファイルごとにレビューを分割します。ファイル間のフローを追跡します。コードが壊れる方法を探します：誤った結果、ルール違反、データ損失、チェック漏れ、互換性の欠如。各懸念事項を要件と実際に実行されるコードに対して確認します。重複をマージします。
• カバレッジを記録します：チェックしたもの、スキップしたもの、完了できなかったもの（パス、SHA、理由、証拠を含む）。「指摘事項なし」はすべてのファイルがチェックされたことを意味しません。重要なカバレッジが説明されていない（チェック済み、スキップ済み、または未完了として記録されていない）限り、レビューを完了と見なさないでください。

ステップ4: 人が理解できる指摘事項を書く

ユーザーは指摘事項のテキストのみから判断するため、テキストは短く、正確で、平易でなければなりません。writing-findings.mdを読んでください。すべてのレビューヘルパーにそのパスを渡し、それに従うように指示します。

issue、question、suggestion、nitpickなどのConventional Commentsラベルを使用します。各指摘事項をblockingまたはnon-blockingとマークします。各指摘事項は4つの部分で構成されます。

• タイトル: 何が問題か、80文字以内の平易な文章で。例：「支払いの再試行で2つの請求書が作成される可能性があります」（「非冪等な請求書作成パス」ではない）。
• なぜ重要か（discussion）：誰が、または何が、いつ、どのくらいの頻度で影響を受けるか。
• 証拠（evidence、およびオプションのコードexcerpt）：path:line、コードパスまたは手順、およびどのように確認したか。
• 修正案（suggestion）：「Small fix」「Medium fix」「Large fix」のいずれかで始め、次に変更内容を記述します。

確信が持てない場合は、questionを書いてください。推測を確認済みのissueとして提示しないでください。各指摘事項に安定したID、パスと行、およびレビューされたSHAを付与します。

指摘事項を読み込む前に、writing-findings.mdの明確性チェックを各指摘事項に対して実行します。失敗したものは書き直し、すべての事実を保持します。

ステップ5: ページを表示し、決定を収集する

1. 指摘事項とカバレッジを読み込み、ページを起動します。1つのページがレビュー全体（後続のラウンドを含む）を処理します。

2. 各指摘事項について、ユーザーは修正する、修正しない、明確化するを選択し、任意の指摘事項にメモを追加できます。選択内容はドラフトとして保存されます。選択を切り替えてもメモは保持されます。

3. 送信のみがバッチを送信します。部分的なバッチでも問題ありません。未決定の指摘事項は開いたままになります。送信された選択はページ上でロックされます。変更はチャットで行われます。

4. まずハーネスを確認します。 このチャットは、シェルにT3CODE_THREAD_IDまたはT3CODE_CLI_PATHが設定されている場合、またはt3_environment_linksなどのT3ツールが利用可能な場合、T3 Codeで実行されています。そうでない場合:

   • このマシンにページを表示し、deliveryMode: "terminal"とします。
   • 以下のページホスト選択をスキップし、別のマシンを提供しません。remote-page.mdを読まないでください。
   • 項目5のプレーンターミナル用の文言を使用します。

   T3では、チャットの起点からページを表示する場所を選択します。 これはインライン/ファンアウトの選択とは別に保ちます。

   • このチャットですでに行われた明示的なページホストの選択を尊重します。再開時にはそれを再利用します。ユーザーがそれを変更した場合、またはそのホストが利用できない場合にのみ、再度質問します。
   • チャットがレビューマシン上でローカルに開始された場合は、質問せずにそのマシンにページを表示します。これは、ユーザーの声明または開始デバイスを識別するホスト提供のクライアント起点メタデータから確認します。エージェントのホスト名、作業ディレクトリ、実行環境、またはcreationSource（web、mobile、mcp）だけでは、ユーザーがどこでチャットを開始したかは証明できません。
   • チャットがリモートで開始された場合、またはその起点が不明な場合は、ページを表示する場所を一度質問します。ユーザーがローカルかどうかについて別の質問はせず、直接ページホストを尋ねます。t3_environment_linksを呼び出し、このマシンに加えてフルアクセス権を持つすべての到達可能なリンクマシンを、実際のラベルを使用して提供します。OSのためにマシンを省略しないでください。ホストを黙って隠すのではなく、既知の機能/アクセス障害を説明します。質問ツールがすべての選択肢を収められない場合は、適格なすべてのホストを質問にリストし、ホスト名を受け入れます。
   • ユーザーのマシンが既知で適格な場合は、それを推奨します。スクリーンロックの制限について説明するのは、それが選択に影響する場合のみです：T3のストリーミングブラウザは、レビューマシンの画面がロックされると停止します。選択されたホストと起点の証拠（またはunknown）をレビューノートに保存します。
   • 別のマシン上: remote-page.mdに従います。ページはそこでユーザーのブラウザで開き、送信は選択内容をこのチャットに返送します。フルアクセス権を持つT3リンクが必要です。このマシンがロックされている間も機能します。

5. 常にホストとページリンクを提供します。

   • T3で、このマシン上: T3ブラウザがページを開くことができます。「送信すると、この会話が自動的に再開されます。」 と表示します。ページはローカルのt3 thread sendコマンドを使用します。パブリックWebhookやトンネルは必要ありません。
   • T3で、別のマシン上: どのマシンがページを表示しているかを示し、「送信すると、選択内容がこのチャットに送り返されます。」 と表示します。
   • プレーンターミナルでは、 以下のように表示します：
     1. レビューページを開きます。
     2. 各指摘事項について選択し、必要に応じてメモを追加し、送信をクリックします。
     3. このチャットに戻ります。

...（以下略）