walk-pr について
walk-pr は、PR や大規模な差分を段階的に確認するレビュー用スキルです。サブ変更セットとレビュー項目を一つずつ提示し、コメントの整理と確認を経て PR レビューを投稿します。
主な機能
- 01PR または差分入力の推定
- 02PR の概要提示
- 03サブ変更セットごとのレビュー
- 04レビュー項目の個別提示
- 05投稿前のコメント整理と確認
活用シーン
- 01未把握の PR のレビュー
- 02大規模な差分の段階的な確認
- 03要点を絞った PR レビューの準備と投稿
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ doodledood/ manifest-dev --skill walk-prインストール後、Claude Code で/walk-prを入力して読み込まれたか確認します。
同梱ファイルassets/canvas-reference.htmlreferences/CANVAS_MODE.md
詳細
PR または大規模な差分を、まとまりのあるファイル群であるサブ変更セット(SC)を一つずつ、さらにその中のレビュー項目を一つずつ確認できるよう、ユーザーを案内します。
入力 = PR 番号、PR URL、差分範囲、または何も指定しない(現在のブランチの PR を推定し、見つからない場合はリポジトリの実際のリモート追跡デフォルトブランチとの差分を使用します)。
読者モデル。 レビュアーはリポジトリには精通していますが、この PR の背景情報はまったく持っていません。コードベースの用語は共有されていますが、PR で導入される用語は共有されていません。新しい型、モード、モジュール、ドメイン用語は、後続の内容で使う前に明示的に紹介する必要があります。
注意の契約。 このスキルのどのモードも、同じ契約に従います。まず全体像を示し、一度に一つのアイデアだけを扱い、詳しい説明、コード、差分、長文はレビュアーが求めたときに限って提示します。チャットでは、以下の「SC を一つ、項目を一つ」の規律を守ります。キャンバスでは、すべてのテキストをタップした先に置いたビジュアルマップを使います。提示方法を選ぶ際に避けるべき失敗は、テキストの壁です。現在のアイデアに必要な量を超えてレビュアーに提示してはいけません。
全体像から始めます。 変更概要の前にPR の導入説明を提示します。ワークフロー用語で問題を説明する段落を一つ記載し、重要な場合に限り、概念用語集(型シグネチャではなく、ワークフローレベルの定義)、コンポーネントの概略図、または読み進めるためのヒントを加えます。その後、変更を重要なものと土台・データに分類し、最もシグナルの強いものから並べた概要を提示します。差分が単純な場合は、これらを省略します。
サブ変更セットごとに、必要に応じて詳しく説明します。 各 SC で常に見えるのは、ユーザーにどのような変化があるかを示す一文の動作概要と、動作をどのように確認するかを示す一文の検証プローブです。それ以外の内容、つまり境界の概要、項目、差分は、レビュアーが必要な SC だけ展開する詳細情報です。
詳細説明では、境界を先に示します。 差分の前にレビュアーが全体を把握できるよう、モジュール境界の視点から簡潔な境界の概要を提示します。対象は、変更の要となる要素に限ります。新規・変更された型、モジュール境界のシグネチャ、依存関係の変化、契約の変更を扱い、項目を網羅的に列挙しません。差分のハンクは、既定の説明ではなく、ファイルごとに必要に応じて提示する証拠です。その後で項目を扱います。
項目の形式。 レビュー項目(検証プローブ、トレードオフ、推奨事項)は一つずつ提示します。項目ごとに、補足資料を開かなくてもレビュアーが一つの判断を下せるようにします。コードベースで使われている用語で具体的な懸念を示し、その後に推奨事項を述べます。節を入れ子にせず、理由を文中に挟まず、考えた過程を語りません。理由、コード抜粋、代替案は見出しではなく、補足資料(後続のメッセージまたは必要に応じて呼び出すプローブ)に記載します。次に進む前にユーザーの回答を待ちます。項目をまとめて「これらすべてについてどう思いますか?」と尋ねるのは、このスキルが防ごうとする失敗例です。反論を受けても、証拠が引き続き判断を裏付ける場合は、見解を保ちます。
トリアージしてから投稿します。 項目ごとの回答と自由記述のメモを含め、ユーザーの回答を項目ごとに記録します。一巡したら、記録したすべての内容を次の三種類に分類します。合意済みの判断は下書きコメントにします。質問は、コメント案を確定する前に回答する必要があります。コード、リポジトリの ADR、PR が実装する設計ドキュメントを確認して回答します(設計ドキュメントを取得してください。設計と実装の差異は、重要なレビュー対象です)。調査によって、コメント案が覆ったり内容が変わったりすることはよくあります。見送りは何も生成しません。次に、提案するコメントをレビュアーに一つずつ確認します。まとめて承認する表は、この一巡で防ごうとしている情報過多を再び招きます。各コメントは、特定のコード箇所に関する場合は行に紐づけ、それ以外はファイル単位または PR 全体に紐づけます。すべての項目が確定したら、利用可能な GitHub のレビュー機能を使って、一回の PR レビューとして投稿します。レビューの投稿をもって、この一巡は完了です。
--canvas. references/CANVAS_MODE.md を読み込みます。HTML アーティファクトは、ウォークスルーの画面としてチャットに取って代わります。これはドキュメントではなく、図です。PR のシステムマップを 1 つ表示し、段階的なストーリー、ピン留めされたレビューのトピック、どこでもコメントできる機能、必要に応じて開くドロワー内の差分を備えています。最初に一度だけ生成され、すぐに開きます。ユーザーは自分のペースで操作し、レビュー内容をまとめたバンドルをチャットに戻します。そこで、上記のトリアージが引き継がれます。