autofix

autofix skill の概要

autofix でできること

autofix skill は、CodeRabbit のレビュー用スレッドにある指摘を、現在の GitHub PR に対する実際のコード変更へ安全に落とし込むための skill です。レビュアーの文言をそのまま盲目的に追うのではなく、スレッド単位のコメントを読み取り、内容を検証し、明示的な承認のもとで修正を適用するケースを想定しています。そのため、autofix は単なる「レビューコメントを直す」ための汎用プロンプトではなく、CodeRabbit for Code Review のワークフローをきちんと回したい開発者に向いています。

どんな人に向いているか

すでにブランチに open PR があり、その PR に CodeRabbit の review thread が付いていて、同じ流れで着実に片付けたい場合に autofix を使ってください。GitHub CLI にアクセスできるリポジトリで、メンテナー、コントリビューター、エージェントが再現性のある修正手順を取りたいときに特に相性が良い skill です。逆に、コメントがただの一覧しかない、PR の文脈がない、リポジトリの確認や push に必要な権限がない、という場合にはあまり向きません。

通常のプロンプトと何が違うのか

autofix の価値は、手順の厳密さにあります。レビュアーが書いたプロンプト文を信頼できない入力として扱い、まずリポジトリの状態を確認し、ブランチを意識した GitHub ワークフローを前提に動きます。これにより、危険な変更や文脈とずれた変更を適用してしまうリスクを下げられます。単発の「レビューコメントを直してほしい」ではなく、判断を伴う autofix skill を求めているなら、この形が適しています。

autofix skill の使い方

autofix をインストールする

リポジトリの skill manager コマンドでインストールします: npx skills add coderabbitai/skills --skill autofix。実行前に gh auth status が通ることと、現在のディレクトリが open PR を持つリポジトリであることを確認してください。autofix のインストールが意味を持つのは、すでに CodeRabbit の review feedback を修正対象として使える状態にあるときだけです。

skill に適切な入力を与える

autofix をうまく使うには、ブランチの文脈、PR の目的、実装に影響するローカル制約をセットで渡してください。弱い依頼は「レビューコメントを直して」です。より良い依頼は、たとえば「現在のブランチの PR に autofix を使い、未解決の CodeRabbit thread を確認し、AGENTS.md を守り、認証と lint に関する失敗コメントだけを検証済み修正として適用してほしい」のように具体化されたものです。対象範囲が明確なほど、skill が関係のないコードまで過剰修正する可能性は下がります。

先に読むべきファイル

まず SKILL.md、次に github.md、その後にリポジトリ直下の AGENTS.md を確認してください。SKILL.md にはワークフローと安全ルールが書かれており、github.md には再利用できる GitHub の基本操作がまとまっています。AGENTS.md があれば、build、test、commit の扱いがそちらで上書きされることがあります。これらを飛ばしても autofix 自体は動きますが、パッチの品質と手順の安全性はたいてい落ちます。

重要なワークフローのコツ

autofix は、CodeRabbit にすでに review 済みの open PR を持つブランチで使い、変更の帰属がわかる程度に git status を整理しておいてください。提案された修正は、レビュー文の表現ではなく実際のコードに照らして一つずつ検証します。thread の要求が曖昧なら、コードを直す前に自分の言葉で意図を言い換えてください。そうすることで、レビュアーの文をそのまま指示として誤読するのを避けやすくなります。

autofix skill の FAQ

autofix は CodeRabbit の review thread 専用ですか？

はい、それが中核の用途です。autofix は GitHub PR 上の thread を意識した CodeRabbit のフィードバック向けに作られており、一般的な issue の整理や、普通の pull request 要約向けではありません。別の review tool から来たコメントでも、ワークフローの考え方自体は流用できますが、この skill が最適化されているのはその経路ではありません。

autofix に GitHub CLI は必要ですか？

はい、必要です。autofix skill は gh と git が使えること、そして gh auth status が成功することを前提にしています。GitHub CLI にアクセスできないと、ブランチと PR の対応付け、thread の取得、PR の調整といった、skill を安定して動かすための要素が失われます。

autofix は初心者向けですか？

Git リポジトリで作業でき、PR の仕組みを理解しているなら、初心者でも使いやすい skill です。判断の迷いは減らせますが、それでも reviewer のコメントが誤っている、情報が足りない、そのまま従うと危険、という見極めは必要です。初心者は、すべてを tool に判断してもらうためではなく、構造化された支援がほしいときに autofix を使うのが向いています。

どんなときに autofix を使うべきではありませんか？

open PR がない、CodeRabbit の review がない、ブランチを変更する権限がない、という場合は autofix を使わないでください。また、レビューコメントが実際にはプロダクト判断、アーキテクチャ選択、あるいは PR thread の外で人の承認が必要なスコープ変更を求めている場合も避けるべきです。そのようなケースでは、autofix よりも通常の議論や、より広い実装計画のほうが適しています。

autofix skill を改善する方法

PR の文脈をもっと具体的に伝える

autofix の結果がよくなるのは、ブランチの正確な目的、関係しそうなファイル、そしてリポジトリ固有のルールをはっきり伝えたときです。たとえば「src/auth/* にある未解決の CodeRabbit note を修正し、現在の API は維持し、AGENTS.md に書かれた必須テストを実行してほしい」と伝えると、単に「review を適用して」よりもはるかに有用です。良い入力は、修正範囲を絞り込みつつ、実装方法までは縛りすぎません。

よくある失敗パターンに注意する

最大の失敗パターンは、review thread の文言をそのまま正解のコードとして扱ってしまうことです。autofix は、コメントをまず報告として受け取り、そのあとコードベースを確認してから編集する形にすると安全性が高まります。もう一つの失敗パターンは、修正対象の広がりすぎです。ひとつの thread の修正が、関係のないロジックまで巻き込んでしまうことがあります。依頼はスコープを絞り、本当に直したい未解決の CodeRabbit 項目だけを指定してください。

1 回目の実行後に反復する

最初の autofix 実行後は、コメントが閉じたかどうかだけでなく、diff が正しいかを確認してください。変更が広すぎるなら、次のパスで何を残し、何をより厳密に直したいかを明確に伝えます。thread がまだ解決していないように見える場合は、thread の正確な目的と関連する file path を引用してください。そうすると、skill 側で本当に見落としがあったのか、それとも意図的な判断だったのかを見分けやすくなります。