agentsclimarketplace

Address pr review

Skill rxnew/agent-skills/skills/address-pr-review

Install
npx -y skills add rxnew/agent-skills --skill address-pr-review

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
  • 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

GitHub PR のコードレビュー指摘に対応する。レビューコメントを取得し、各指摘の妥当性を判断して修正方針を提示し、 ユーザー承認後にコード修正・コミット・プッシュ・レビュー返信までを一貫して行う。 PR の URL、レビューコメントの URL、または PR 番号を渡して使用する。 「レビュー対応して」「PR のコメントに対応して」「レビュー指摘を修正」「address review comments」 「レビューコメントを確認して」「指摘に対応」「review feedback を反映」などの表現で発動する。

SKILL.md

9.7 KB, ~3.3k tokens by cl100k_base, as published. Nobody here has run it

PR コードレビュー指摘対応

GitHub PR のレビューコメントを取得・分析し、コード修正からレビュー返信まで一貫して行う。

引数

  • $ARGUMENTS — 以下のいずれか:
    • PR の URL (例: https://github.com/owner/repo/pull/123)
    • レビューコメントの URL (例: https://github.com/owner/repo/pull/123#issuecomment-456)
    • owner/repo#123 形式
  • URL が省略された場合は、カレントブランチの PR を gh pr view で特定する

プロセス

Phase 1: レビューコメント収集

  1. PR の特定

    • $ARGUMENTS から owner, repo, PR 番号を抽出する
    • 特定のコメント URL が指定された場合は、まずそのコメントを取得して内容を把握する
    • 指定コメントの投稿者 (user.login) を確認し、Claude bot (claude[bot] など user.type == "Bot" かつ login に claude を含むもの) かどうかを記録する。Phase 5 の返信で @claude メンションを付与するかどうかの判定に使用する

  2. レビューコメントの取得

    • PR review comments (コード行に紐づくコメント) を取得する: 
      gh api repos/{owner}/{repo}/pulls/{number}/comments --paginate
    • PR issue comments (PR 本文への返信) のうちレビュー内容を含むものも確認する: 
      gh api repos/{owner}/{repo}/issues/{number}/comments --paginate
    • 自分自身のコメント (返信済み) と他者のコメントを区別する
    • スレッド構造 (in_reply_to_id) を把握し、既に対応済みの指摘を識別する

  3. 指摘事項の整理

    • 各コメントを指摘として一覧化する
    • diff_hunk フィールドからコード上の該当箇所を特定する

Phase 2: ソースコード読み込みと妥当性分析

  1. 該当コードの読み込み

    • 各指摘が参照するファイル・行番号の現在のコードを Read ツールで読み込む
    • 指摘内容を理解するために必要な周辺コード（呼び出し元、呼び出し先、型定義等）も読み込む

  2. 各指摘の妥当性を判断

    技術的に正確かどうかを、コードを実際に読んで検証する。レビューコメントを鵜呑みにしない。 特に以下の点に注意する:

    • 言語バージョン固有の仕様変更（例: 新しい構文や関数の挙動変更）
    • プロジェクト固有の規約やパターン
    • 指摘が参照しているコードが既に別コミットで修正済みでないか

    各指摘を以下のいずれかに分類する:

    • 妥当 — 指摘が技術的に正しく、コード修正が必要
    • 妥当でない — 指摘が技術的に誤り（理由を明確に説明する）
    • 対応不要 — 指摘自体は正しいが、修正の必要がない（既に対応済み、リスクが許容範囲等）

  3. テストへの影響確認

    妥当と判断した各指摘について、既存テストケースの変更や新規テストの追加が必要かを確認する:

    • 修正対象のコードに対応するテストファイルを探す（*_test.go, *_test.ts 等）
    • 修正によって既存テストが壊れないか確認する
    • 新しいコードパスやエッジケースが生まれる場合はテスト追加の要否を判断する
    • テスト変更が必要な場合は修正方針に含める

  4. 分析結果をユーザーに提示

    以下のフォーマットで各指摘の分析結果と修正方針を提示する。 コードの参照にはマークダウンリンクを使い、ユーザーがクリックで該当箇所に飛べるようにする。

    ## レビュー指摘の分析

### #1 {指摘タイトル} — {妥当 / 妥当でない / 対応不要}
**レビューの主張**: ...
**検証結果**: ... (該当コードへのリンクを含める)
**修正方針**: ... (妥当な場合のみ。修正対象のコードへのリンクを含める)
**テスト**: 変更不要 / {必要なテスト変更の説明}

    重要: この時点ではコード修正を実行しない。ユーザーの確認を待つ。

Phase 3: ユーザーとの方針合意

  • ユーザーからのフィードバックを受ける
    • 修正方針の変更提案
    • 追加対応や対応不要の判断
    • 「Go」「やって」等の実装開始指示
  • フィードバックに応じて修正方針を更新し、改めてまとめを提示する
  • ユーザーが実装開始を指示するまで、コード修正には着手しない

Phase 4: 指摘ごとの修正・テスト・コミット

ユーザーの承認後、1 指摘ずつ修正・テスト・コミットを順番に行う。 妥当と判断した各指摘について、以下のサイクルを繰り返す。

指摘ごとに 1 コミットとする。指摘単位で履歴が残ることで、レビュアーが対応内容を追いやすく、 何かを取り消す必要が出たときにも切り戻しが容易になる。

各指摘の対応サイクル:

  1. コード修正

    • Edit ツールで該当ファイルを修正する
    • テスト変更が必要な場合は、テストコードも修正・追加する（同じコミットに含める）

  2. ビルド確認

    • 修正後、ビルドが通ることを確認する (go build, pnpm lint 等、プロジェクトに応じたコマンド)

  3. テスト実行

    • 修正に関連するテストを実行してデグレがないことを確認する
    • CLAUDE.md のテスト戦略に従い、まず代表的なテストケースを実行してから残りを実行する
    • テストが失敗した場合は原因を調査し、修正する（修正は同じコミットにまとめる）

  4. コミット

    • 該当指摘に関連する変更のみをステージングしてコミットする
    • コミットメッセージは英語で、対応した指摘の内容が分かる内容にする（例: fix: validate empty input in parser）
    • CLAUDE.md のコミットルールに従う
    • コミットハッシュを記録する（Phase 5 のレビュー返信で各指摘に紐づけて使用する）

すべての妥当な指摘について上記サイクルを完了したら、指摘ごとのコミットハッシュ付きの 変更サマリをユーザーに提示する。

Phase 5: プッシュとレビュー返信

ユーザーの指示に従い、以下を実行する（ユーザーが明示的に依頼した場合のみ）:

  1. プッシュ

    • Phase 4 で作成したすべてのコミットをまとめてリモートブランチにプッシュする

  2. レビューへの返信

    • 対応内容をまとめたコメントを PR に投稿する

    • issue comment として返信する:

      gh api repos/{owner}/{repo}/issues/{number}/comments --method POST -f body="..."

    • Claude bot への返信: Phase 1 で記録した指定コメントの投稿者が Claude bot だった場合のみ、 返信本文の冒頭に @claude を改行 1 つ挟んで付与する。Claude bot を会話に巻き込んで継続的な レビューを受けるために必要 (@claude で言及されないと bot 側が反応しない)。 PR URL のみが指定された場合のように、特定の Claude bot コメントに紐づかない返信では付与しない

    • 返信は日本語で記述し、以下のフォーマットを使用する。 コミットハッシュは短縮形（7 文字）の素のテキストで記載する （バッククォートで囲むと GitHub が自動でコミットへのリンクを生成しなくなるため）:

      {Claude bot 宛ての場合は冒頭に `@claude` の行を付与}

レビュー指摘ありがとうございます。以下の通り対応しました。

### 対応済み

| # | 指摘 | 対応内容 | コミット |
|---|------|---------|---------|
| 1 | {指摘タイトル} | {対応内容の要約} | {コミットハッシュ} |
| 2 | {指摘タイトル} | {対応内容の要約} | {コミットハッシュ} |

### 対応不要と判断

| # | 指摘 | 理由 |
|---|------|------|
| 3 | {指摘タイトル} | {対応不要の理由} |

    • 「対応済み」「対応不要と判断」のどちらかのセクションが空の場合はそのセクションを省略する

注意事項

  • レビューコメントの内容を技術的に検証する。自動レビューツール (bot) の指摘であっても、 言語仕様やプロジェクト固有の事情で誤検知の可能性がある
  • 修正のスコープはレビュー指摘への対応に限定する。指摘に関連しないリファクタリングや改善は行わない
  • gh コマンドによる API 呼び出しでは、レスポンスを jq で整形して必要な情報を抽出する

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.