$shibayu36->blog;

クラスター株式会社のソフトウェアエンジニアです。エンジニアリングや読書などについて書いています。

github-pr-review-operationスキルをvercel-labs/skillsでコマンド一発でインストールできるようにした

以前、Claude CodeやClaude Code ActionでPRレビューを行うときに便利なgithub-pr-review-operationというスキルを作った話を書いた。

blog.shibayu36.org

前回の記事では.claude/skills/配下にSKILL.mdを直接配置する方法を紹介した。しかし手動でファイルをコピーする必要があって面倒だったので、これをGitHubで公開し、vercel-labs/skillsを使ってコマンド一発でインストールできるようにした。

インストール方法

shibayu36/agent-skillsにスキルを公開している。以下のコマンドでClaude Codeにインストールできる。

npx skills add shibayu36/agent-skills --skill github-pr-review-operation --agent claude-code

--agentオプションで対象のエージェントを指定でき、複数指定も可能。たとえばClaude CodeとCodex両方に入れたければ--agent claude-code --agent codexとする。また--globalフラグを付ければグローバルに、付けなければプロジェクト単位でインストールされる。

スキルの中身は前回の記事と同じなので、何ができるかは前回の記事を参照してほしい。

Tips: Agent Skillsの配布にvercel-labs/skillsが便利

Agent Skillsの配布にはClaude Codeのpluginsの仕組みを使う方法もある。しかし、これだとClaude Codeのみでしか使えない。じゃあどうしようと迷っていたら、vercel-labs/skillsがその要求にマッチしたものだった。

vercel-labs/skillsでインストールできるように公開する方法は簡単で、GitHubリポジトリを作り、skills/スキル名/SKILL.mdという構造でファイルを置くだけでいい。これだけで以下のようにnpx skills addコマンドでインストールできるようになる。

npx skills add shibayu36/agent-skills # 全部インストール
npx skills add shibayu36/agent-skills --skill github-pr-review-operation --agent claude-code --agent codex # 特定のスキルをClaude CodeとCodexにインストール
npx skills add shibayu36/agent-skills --skill github-pr-review-operation --agent claude-code --agent codex --global # プロジェクト配下ではなくグローバルにインストール

さらにプロジェクト配下にインストールするとlockファイルができ、Agent Skillsがアップデートすべきかのチェックもできる。

skills-lock.json:

{
  "version": 1,
  "skills": {
    "github-pr-review-operation": {
      "source": "shibayu36/agent-skills",
      "sourceType": "github",
      "computedHash": "8ecf437065d23d751f17475fb4588fe92b60c34ee87e73c92432cf72dd1502bd"
    }
  }
}
npx skills check # アップデートがあるSkillを表示
npx skills update # 全部アップデート

この仕組みはプライベートリポジトリでも動くため、社内でスキルを共有するのにも使える。チームで作ったレビュー用スキルなどまとめておくと便利そうだ。

AIによる実装の品質が微妙で毎回自分で指摘しまくる必要があったので、確認前に自動で品質を上げさせるようにした

Claude Codeに実装させた後、毎回自分でコードレビューして突っ込みを入れるのが大変だった。そこで、実装後に自動でセルフレビューと修正をする仕組みを作ったので紹介する。

課題: Claude Codeで出力されたコードの品質が自分の基準を満たさない

Claude Codeで一気に実装ができるようになった反面、出力されたコードの品質が自分の基準を満たさないことが多かった。そのため、変更のたびに毎回ツッコミを入れていて、かなりの手間がかかっていた。プランモードで事前にちゃんと設計したとしても、コードレベルでは満足いかないことが多かった。

じゃあサブエージェントやCodex CLIで先にレビューして直し切ってもらってから確認すれば良いのでは?と思ってやってみた。しかし、AIのレビュー指摘には的外れなものや過剰なものも混じるため、全部対応させるとかえってコードが散らかってしまうこともあった。

どうしたものかと思っていたところ、kawarimidollさんの202602個人的claude code設定の記事で解決の糸口を見つけた。レビューをさせた後にその指摘が適切かを判定させてから修正させるという考え方だ。この考え方を取り入れて、自分でもセルフレビューの仕組みを作ってみた。

/self-reviewで並列レビュー→批判的精査→修正を自動で回す

作ったのは /self-review参考)というスラッシュコマンドだ。実行すると、特性の違う3つのreviewerエージェントが並列でコードレビューし、全レビューが完了したら /fix-review-comments参考)スキルが各指摘を批判的に評価し、妥当な指摘のみを修正する。実行の流れは以下の図のとおり。

reviewerエージェントは以下の3つを用意している。

  • reviewer参考): 品質・セキュリティ・パフォーマンスなど多角的にレビューするエージェント。kawarimidollさんの記事のreviewerエージェントを参考にした
  • codex-reviewer参考): Codex CLIの codex review コマンドを使ってレビューするエージェント。Claude以外のモデルの視点でもレビューできるのが良い
  • simplify-reviewer参考): 可読性・一貫性・保守性に特化したreviewerエージェント。AI生成コード特有の「やりすぎ」(過剰な抽象化、不要な複雑さなど)を検出する。Anthropic公式のcode-simplifierを参考にした

3つのreviewerエージェントの指摘は重複することもあるが、それは問題ない。複数のreviewerエージェントが同じ箇所を指摘していれば、その指摘の優先度が高いと判断できるからだ。

ポイントは /fix-review-comments が「この指摘は本当に直すべきか?」を批判的に判断してくれるところだ。対応しなかった指摘にはその理由も付けてくれる。こちらもkawarimidollさんの/addressコマンドを参考にした。

実際に動かすと指摘の取捨選択まで自動でやってくれる

実際のセッションの様子を紹介する。/self-review を実行すると、まず3つのレビュアが並列で起動し、それぞれの結果が返ってくる。

> /self-review

⏺ 3 agents finished
   ├─ reviewer (詳細レビュー) · 3 tool uses
   ├─ codex-reviewer (Codexレビュー)
   └─ simplify-reviewer (可読性レビュー)

⏺ 全レビュー完了!結果をまとめると:
  reviewer: 5件
  codex-reviewer: 1件
  simplify-reviewer: 4件

この例では合計10件の指摘が出た。ここから /fix-review-comments が各指摘を批判的に評価し、対応すべきものだけをピックアップする。

対応する指摘:
  1. reviewer #1: やりとり回数カウント不明確 → 妥当。明記すべき
  2. reviewer #4: 判定基準の具体化 → 妥当。目安を示すとAIの判断が安定する
  3. simplify #1: ルールが3箇所に分散 → 部分的に妥当。2箇所に集約
  4. simplify #4: 表現不統一 → 妥当。統一する
  5. reviewer #5 / simplify #3: セクション配置位置 → 妥当。移動する

対応しない指摘:
  - reviewer #2: バグ案内のみで終了するパス →
    要件で意図的に設計済み
  - reviewer #3: 曖昧な場合のステップ4の説明 →
    既存の記述で包含されている
  - codex #1: 2回目以降のバグ判明 →
    要件のOut of scopeで明確に除外されている
  - simplify #2: 箇条書きの長さ →
    判断分岐と直結する動作指定なのでここに残す方が実用的

10件中6件が対応、4件が却下された。却下された指摘にはそれぞれ理由が付いている。たとえば「要件で意図的に設計済み」「既存の記述で包含されている」など、プロジェクトの文脈を踏まえた判断をしてくれる。この取捨選択があるから安心して自動修正に任せられる。

まとめ

普段の使い方はシンプルで、Claude Codeに実装させた後、ほぼ毎回 /self-review を実行している。直し切ってもらってから、自分がコードを読んでレビューしている。

Claude Codeの出力品質に毎回突っ込むのが大変だったが、セルフレビューループの仕組みを作ったことで、自分がコードを読む前にある程度品質が底上げされるようになった。設定ファイルは全てconfig-fileリポジトリにあるので、同じ課題を感じている人は試してみてほしい。

参考

tmuxのselect-layout -Eでペイン分割を常に等分にする

tmuxでペイン分割を繰り返すと、1/2、1/4、1/4のように不均等な分割になってしまう。3分割や4分割を等分でシュッとやりたいなと思い調べたところ、select-layout -Eが超便利だったのでメモしておく。

.tmux.confの設定

自分は元々emacs風のキーバインドでprefix + 2で上下分割、prefix + 3で左右分割を設定していたが、そこにselect-layout -Eを足すだけで等分リサイズされるようになった。さらにペイン終了時にも等分リサイズされるようにhookを設定した。

# 上下分割 + 等分リサイズ
bind 2 split-window -vc "#{pane_current_path}" \; select-layout -E
# 左右分割 + 等分リサイズ
bind 3 split-window -hc "#{pane_current_path}" \; select-layout -E
# ペイン終了時にも等分リサイズ
set-hook -g pane-exited 'select-layout -E'

これだけで、prefix + 3をすればs左右に自然に等分で分割が増えていくし、prefix + 2なら上下に等分で増えていく。ペインを閉じた時も自動で等分にリサイズされる。

select-layout -Eとは

ポイントはselect-layout -Eの影響範囲だ。tmuxにはレイアウトを均等にする機能としてselect-layout even-horizontalのようなものもあるが、これはウィンドウ全体のペインを並べ替えてしまう。

一方select-layout -Eは、現在のペインが属する分割グループの兄弟ペインだけを均等にする。そのためネストした分割構造を壊さずに、その階層のペインだけを等分にできる。例えば左右3分割の中の1つを上下分割しているような場合でも、上下分割の等分リサイズが他の左右分割に影響しない。