receiving-code-review

エージェントにレビューの指摘を直させると、確認せずに全部直してしまうときです。

このスキルが解こうとしている問題は、コードではなく受け答えの型です。本文の最初の 1 行がそれを言い切っています。

コードレビューは技術的な評価であって、感情の演技ではない。

型は 6 段階

1. READ反応せずに指摘を最後まで読む
2. UNDERSTAND要求を自分の言葉で言い直す。できなければ聞く
3. VERIFYコードベースの実物と突き合わせる
4. EVALUATEこのコードベースにとって技術的に妥当か
5. RESPOND技術的な確認、または理由を付けた反論
6. IMPLEMENT1 件ずつ直して、その都度テストする

効くのは VERIFY と EVALUATE です。ここが抜けると、レビュアーが文脈を知らずに書いた指摘をそのまま入れてしまいます。

禁止する返答を名指ししている

このスキルの特徴は、言ってはいけない言葉を列挙しているところです。

• 「おっしゃるとおりです」
• 「良い指摘ですね」
• 「すぐ実装します」（検証の前に言うもの）

代わりに求めているのは、要求の言い直し、確認の質問、理由を付けた反論、あるいは黙って直すことです。本文の言い方は「行動が語る」。

感謝の表現も禁止している

「ありがとうございます、直します」も対象です。理由は「コードそのものが指摘を受け取ったことを示す」から。

やりすぎに見えるかもしれませんが、同意の言葉が検証の代わりになってしまうのを防ぐ狙いは分かります。

不明な項目が 1 つでもあれば全部止める

ここが実務で一番効きます。

不明な項目があるなら、何も実装しないで止まる。理由: 項目は互いに関係している可能性がある。部分的な理解は誤った実装になる。

「1〜6 を直して」と言われて 4 と 5 が分からないとき、1、2、3、6 を先に直してから 4、5 を聞くのは誤りと明示しています。先に直した部分が、4 と 5 の答えによって無駄になるからです。

相手によって扱いを変える

外部の指摘に対する 5 つの確認はこれです。

1. このコードベースにとって技術的に正しいか
2. 既存の機能を壊さないか
3. いまの実装にした理由があるか
4. すべての環境・バージョンで動くか
5. レビュアーは全体の文脈を理解しているか

検証できないときは「できない」と言わせる

「〜が無いと確認できません。調べますか、聞きますか、そのまま進めますか」の形です。

YAGNI の確認

「ちゃんと実装してください」という指摘が来たら、まずそのコードが使われているかを grep させます。使われていなければ「この endpoint は呼ばれていません。消しますか」と返す。

これは順序が正しいです。使われていない機能を「ちゃんと」作るのは、負債を丁寧に増やす作業です。

指摘を出す側には使えない

これは受ける側のスキルです。見直しを頼む側は、同じ公開元の requesting-code-review です。公開元は違いますが、code-review も規約と仕様の 2 軸に分けて指摘を出す設計になっています。

「早く直してほしい」だけの場面には重い

typo の指摘に 6 段階の型を通すのは過剰です。このスキルが効くのは指摘が複数あって、そのうち一部が怪しいときです。

反論の材料が無い環境では半分になる

VERIFY はコードベースと突き合わせる段階なので、手元にコードが無い状態（差分だけを見ている）では機能しません。

文章の表現まで統制されるのが嫌なら合わない

「ありがとうございます」を禁止するところまで含めて 1 つの型です。チームの文化と合わないなら、依頼文で「検証の手順だけ使って、返答の言葉づかいは指定しない」と外せます。

解析で見つかった記述

SKILL.md の解析では、ファイル書き込みとシェルコマンドの実行の記述が見つかっています。外部通信の記述は見つかっていません。同梱ファイルは 0 件です。

シェルとして見つかったのは末尾の gh コマンド

GitHub のインラインコメントに返信する部分で gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies を叩く指示があります。GitHub への書き込みですが、gh の中で起きるので通信としては拾えていません。

解析結果は「そう書かれている」ことの列挙で、挙動の保証ではありません（スキルを入れる前に確認すること）。

gh を入れていない環境では、この部分だけが動きません。返信を手でやるなら支障はありません。

「人間のパートナー」という前提で書かれている

本文には your human partner（一緒に作業している人）という語が繰り返し出てきます。「外部の指摘と衝突したらパートナーに相談して止まる」という指示があります。

反論が正しいとは限らない

このスキルは「技術的な理由があれば押し返す」型なので、エージェントが誤った理由で押し返すこともあります。押し返してきたときは、その理由自体を確認してください。

本文にも「押し返して間違っていたら、事実として訂正して先に進む」形が書かれています。

指摘を全部直させたいときはどうすればいいですか

依頼文で「検証は省いて、指摘のとおりに直して」と指定すれば通ります。ただしそう指定するなら、このスキルを使う意味はほぼありません。このスキルの中心は検証の段階です。

「ありがとう」を禁止するのは行き過ぎではないですか

行き過ぎに見えます。実際、表現の制約と検証の手順は別のことです。

ただし狙いは分かります。同意の言葉を先に出すと、検証しないまま実装に入る流れができるからです。言葉を封じることで手順を守らせる作りになっています。

表現だけ外したいなら、依頼文で「言葉づかいの指定は使わない。検証の 6 段階だけ守って」と書けます。

1 件ずつ直すのは遅くないですか

遅くなります。ただしまとめて直してテストしないほうが結果的に遅いという判断です。本文は「blocking な問題 → 簡単な修正 → 複雑な修正」の順で、1 件ごとにテストし、最後に回帰を確認する順序を指定しています。

急ぐなら、簡単な修正（typo や import）だけまとめる形に依頼文で調整してください。

レビューをする側のスキルと一緒に使えますか

使えます。同じ公開元なら requesting-code-review が見直し役を出す側です。別の公開元の組み合わせなら、出す側で code-review が規約と仕様に分けた指摘を出し、受ける側でこのスキルが検証する形です。

ただし公開元が違うので、前提の初期設定はそれぞれ必要です。code-review の側は課題管理システムの設定が前提になっています。