メニュー
GitHub PRのレビューコメントのうち、Hide・解決済みでないものだけを抽出して対応する。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Commit, push, and create or update a PR
GitHub Actions の CI 失敗を、失敗ジョブの特定 → ログからの原因抽出 → 原因分類 → ローカル再現 → 修正 → 検証まで体系的に進めるスキル。特に、失敗ログのノイズに埋もれて原因が見えないとき、環境依存でフレーキーに落ちているときに役立つ。修正に人の判断が必要な場合は、対話モードでは確認して中断し、--non-interactive 指定時はPRにコメントを投稿して中断する。
`bundle exec erblint app` の既存違反をファイル単位で無効化する todo ファイル群 （`.erb_lint_todo.yml` / `.erb-lint-rubocop-todo.yml`）を生成・初期化する手順。手動起動専用 （`/erblint-todo-init`）。todo を作り直したいときなど、一回性のセットアップ作業でのみ使う。 rubocop 単体・haml-lint・herb-lint の運用には使わない。
プランモードで作成したプランファイル（Markdown）の内容に沿って実装を行う。実装フェーズを軽量なsonnetモデルで実行し、コスト・速度を最適化する。引数でプランファイルのパスを指定できる。省略時は直近のセッションログから対象プランを自動特定してユーザーに確認する。コミット・push・PR作成は、プランに明記されている場合のみ実施する。
APM パッケージ由来ルール（.claude/rules/*.md）と重複するプロジェクト固有ローカルルール （.apm/instructions/*.local.instructions.md）を検出し、ローカル側を削除・縮小する。未管理ルールの 新規移行は行わない（それは migrate-rules-to-apm の役割）。手動実行専用（自動トリガーしない）。
APM未管理の .claude/rules ルール（手動配置・レガシーな local/ サブディレクトリ配置）および ルートの CLAUDE.md を .apm/instructions/*.local.instructions.md に一括移行するスキル。@参照は 展開して本文に取り込み、参照元ファイルは他からの参照がなければ削除する。手動実行専用（自動トリガーしない）。
| name | pr-review-comments-resolve |
| description | GitHub PRのレビューコメントのうち、Hide・解決済みでないものだけを抽出して対応する。 |
| argument-hint | <PR番号 または PR URL> [--non-interactive] |
| disable-model-invocation | true |
| license | MIT |
引数としてPR番号またはPR URLを受け取る。省略された場合、手順1のスクリプトが現在のブランチに紐づくPRを自動検出する（gh pr viewベース）。ユーザーへの質問で立ち止まる必要はない。自動検出できなかった場合はスクリプトがエラー終了するので、その時点でPR番号またはPR URLをユーザーに尋ねる。
GitHub PRのレビューコメントに対応する。ここでいう「対応」は、コメントを読んで終わりではなく、 実際にコードを直し、コミットし、PRに反映するところまでを指す。
引数に --non-interactive が含まれる場合は非対話モードとして振る舞う（claude -p などユーザーへ対話的に承認を取れない実行を想定）。含まれなければ通常の対話モード。
CLAUDE_CODE_ENTRYPOINT など）で非対話かどうかを推測しない（確実に判定する公式手段がなく不安定なため）。--non-interactive はPR番号/URLとは独立した引数であり、順序は問わない。手順1のスクリプトに渡す位置引数はPR番号/URLのみなので、--non-interactive はスクリプトへ渡さず、このSKILL側で読み取って手順4の分岐に使う。両モードで異なるのは手順4（PR本文の更新）だけ。それ以外の手順（PR自動検出・修正・コミット・push）はどちらのモードでも同じく自動で進めてよい。
PRには「もう見なくていい」コメントが溜まっていることが多い：
見なくていいコメントまで拾うと、本人が意図的にHideしたものを蒸し返したり、無関係な修正が紛れ込んだりする。 この絞り込み（Hide/解決の判定とページング）は判断の要らない定型処理なので、手順1のスクリプトに切り出してある。
スクリプトはこの SKILL.md と同じディレクトリの scripts/fetch-unresolved-comments.sh にある。
bash "<この SKILL.md のあるディレクトリ>/scripts/fetch-unresolved-comments.sh" <PR番号 または PR URL>
引数を省略すると現在のブランチに紐づくPRを対象にする。owner/repoはPR URLから抽出するか、無ければ現在のリポジトリから自動検出する。
stdout に isResolved == false かつ isMinimized == false のコメントだけを整形済みJSON配列で返す（reviewThreads のページングも内部で処理済み）:
[{ "id": "...", "databaseId": 123, "path": "...", "line": 10, "body": "..." }, ...]
抽出できたら、対象件数と各コメントの要旨（ファイル・指摘内容）を短く報告してから着手する。 0件だった場合はそこで完了を伝えて終わる（無理に何かを直そうとしない）。
レビューコメント、特にbotによる自動レビューは、提案（suggestionブロックなど）をそのまま鵜呑みにできるとは限らない。
指摘が指しているファイル・シンボルが現在のコードにまだその形で存在するか、提案されている修正先が
実際に正しい移行先かを、そのつど調べる。具体的には：
grep/git logで参照元と移行先の実体を確認するsuggestion ブロックが付いている場合も、周辺の実装や命名規則と整合するか一度目で確認してから採用する（コピペで即採用しない）調査の結果、指摘が的外れ・スコープ外（例: 過去の設計判断の記録であって実害のあるリンク切れではない）と判断した場合は、 その理由を添えて対応をスキップしてよい。全部を無理やり直す必要はない。
手順2で全件スキップし、修正対象が0件になった場合はこの手順を省略し、次の「対応が終わったら」に進む。
git log）のスタイルに倣う手順3を省略した場合（追加コミットが0件）は、この手順も省略する。
追加コミットによってPRの変更内容が増えた場合、既存のPR本文に反映漏れが出ることがある。
base branchとの git diff/git log（base..HEAD）からPR全体の変更点を洗い出し、
本文に反映すべき内容があるか判断する。反映すべき内容がなければこの手順は何もせず終える。
反映すべき内容がある場合の扱いは実行モードで分岐する。
追記の粒度は、コミット単位（＝関心事）ごとに1〜2行の要約でよい。詳細な理由や調査過程まで書き込む必要はない。
タイトルは全体を的確に要約できていれば変更不要のことが多い。
対話モード: 反映すべき内容を更新前にユーザーに提示して承認を取り、承認後にPR本文を更新する（PR本文の更新は外向きの操作なので、承認なしに自動で書き換えない）。
非対話モード（--non-interactive）: 承認を取れないためPR本文は書き換えない。代わりに反映すべき内容をPRにコメントとして投稿する。コメント本文の冒頭に、これがPR本文への反映提案であり非対話実行のため自動投稿したものである旨の短い前置きを付ける。
gh pr comment <PR番号 または PR URL> --body "<提案本文>"