review

review skill の概要

review skill でできること

review は、コードがマージされる前に base branch との差分を確認するための pre-landing PR review skill です。一般的なプロンプト以上のレビュー精度が必要なレビュワー向けに作られており、SQL の安全性、trust-boundary の逸脱、条件付き副作用、shell injection、enum の網羅性など、具体的な構造リスクに重点を置いています。

どんな人に向いているか

コードを着地させる直前に確認したいとき、review this PR に対応したいとき、または repo をまたいで一貫した review for PR Review ワークフローを使いたいときに向いています。特に、ノイズの多い見た目だけの指摘ではなく、実際の不具合を素早く拾う必要がある agent に有用です。

何が違うのか

この skill は、レビューの順番と重要度についてかなり意見がはっきりしています。まず重大な安全性チェックを優先し、そのあとで低重要度の問題を扱います。さらに、testing、security、performance、maintainability などの領域に対して specialist review path も用意されています。そのため、広く「diff を見て」と指示するよりも、review guide のほうが実務的で、次に何をすべきかが明確です。

向いているケースと限界

この skill が最も強いのは、明確な git diff と意味のある base branch があるコード変更です。一方で、高レベルな設計レビュー、コピーの文言修正、あるいは単に褒めてほしい、要約だけ欲しいといったケースにはあまり向きません。軽い意見が欲しいだけで、修正起点のレビューまでは必要ないなら、一般的なプロンプトで十分なこともあります。

review skill の使い方

インストールして起動する

npx skills add garrytan/gstack --skill review でインストールします。この skill は、「review this PR」「code review」「check my diff」「pre-landing review」といったフレーズで起動するよう設計されています。できるだけ、変更内容と比較対象を入力に含めてください。

実際のレビュー対象を明示する

良い review usage は、曖昧な依頼ではなく、diff を意識した依頼から始まります。たとえば、repo、branch、意図を含めると精度が上がります。

• “Review this PR against origin/main; focus on safety, merge risk, and anything that would block landing.”
• “Review the diff in packages/billing for SQL injection, race conditions, and API contract breaks.”

最初に読むべきファイル

実際に review install を確認するなら、まず SKILL.md を読み、次に checklist.md、design-checklist.md、greptile-triage.md を確認してください。ワークフローを調整する場合は、TODOS-format.md と specialists/ フォルダも見て、どの issue が main checklist ではなく subagent に振り分けられるのかを把握するとよいです。

skill が想定しているワークフローを使う

この repo は、まず重大な安全性チェック、次に情報提供レベルの issue を見るという 2 パスのレビューを前提にしています。強いプロンプトにするなら、単に「バグを見つけて」ではなく、file/line の参照と修正案まで含めた実行可能な出力を求めてください。変更箇所が分かっているなら、関連する specialist path を優先できるよう、その領域も明示してください。

review skill の FAQ

review は通常のプロンプトより優れているか？

はい、再現性のある PR review 行動が必要なら優れています。通常のプロンプトだと、スコープのルール、エスカレーション順序、specialist への振り分けを見落としやすくなります。review skill はそうした要素をワークフローに組み込んでいるため、最初に何を見るべきかの迷いが減ります。

review skill は初心者でも使いやすいか？

概ね使いやすいです。少なくとも、branch や PR を説明できるなら問題ありません。初心者にとっては、ガイド付きの checklist が助けになりますが、それでも実際の diff と、意図した挙動と regression を見分けるための十分なコンテキストは必要です。

どんなときに review を使わないほうがいいか？

コード変更がない質問、ブレインストーミング、具体的な変更セットのない抽象的なアーキテクチャ議論には使わないでください。また、単に軽く妥当性を確認したいだけで、line-level の指摘が不要なら、この skill は最適ではありません。

review for PR Review では何が返ってくるか？

重要度を優先した、簡潔で修正指向のコメントが返ってくることを期待してください。この skill は、リリース阻害要因を見つけるためのものであり、repo 全体を言い換えたり、お祝いの要約を出したりするためのものではありません。

review skill を改善する方法

入力をもっと具体的にする

最も強い review skill の入力は、base branch、リスクの高い subsystem、求める基準を明示しています。「my PR を見て」ではなく、review feature/payment-retry against origin/main; prioritize data safety, idempotency, and any behavior change that could break clients. のように書いてください。

判断を変えるコンテキストを入れる

変更が意図的にリスクを伴うなら、その点を先に伝えてください。project policy で許容されているパターンがあるなら、それも最初に書いてください。そうすることで false positive を減らし、既知の判断を蒸し返すのではなく、実際のトレードオフにレビューを集中させやすくなります。

必要な出力形式を指定する

landing を意識した出力が欲しいなら、file:line、severity、具体的な修正案つきで findings を求めてください。ブロッカーだけ欲しいなら、その旨を明示してください。specialist coverage が必要なら、それもはっきり依頼してください。そうしないと、レビューが first pass で止まってしまうことがあります。

最初のレビュー後にもう一度回す

まず最初のレビューで明らかな問題を直し、その更新後 diff に対して review を再実行してください。品質向上の効果が大きいのは、たいてい scope を明確にし、比較 branch を絞り込み、もっとも重視する risk area を skill に正確に渡すことです。