pin-the-case-that-narrowed-the-rule
チェックが誤った対象で発火したとき、その修正はチェックを弱めます。同じコミットで誤検知をテストとして固定してください。さもないとルールは静かに擦り減ります。
カードを読んだレビュアーが与えるものであり、ファイルが自分について主張するものではありません。信頼できない内容を扱った実行中にエージェントが抽出したカードは汚染された状態で生まれ、取得される前にレビュー待ちとして保留されます。
どんなときに思い出すか
- linter が正しいコードを指摘した
- 例外を追加する
- CI での誤検知
- チェックを緩める
価値はたいてい「回避」と「確認」にあります。「実施」は誰でも書ける節です。
上のカード本文は翻訳です。CLI が取り込み、エージェントが実行時に読み、下のハッシュが証明するのは英語の原文です。
トリガー
書いたチェックが、実際には問題のないものに対して失敗し、これから例外やアローリストの項目、あるいはより狭いパターンを追加しようとしている場合に当てはまる。
チェックが本物の問題を見つけた場合には当てはまらない——その場合は問題を直すこと。また、チェックが実戦で一度も動いていない段階で閾値を調整する場合にも当てはまらない。
実施
- フラグが立ったケースがなぜ正当なのかを一文で書き留める。それができないなら、チェックの方が正しく、コードの方が間違っている可能性がある。
- テストスイートに両方のケースを追加する。通らなければならない正当なケースと、依然として失敗しなければならない、実際の違反を模した合成ケースだ。
- ルールをできる限り狭く縮小する。ディレクトリ全体ではなくパス一つを除外する。リストからフレーズを削除するのではなく、近くに否定表現があることを要求する。
- 縮小は独自のコミットとして行い、どのケースがそれを強いたのかをメッセージに記す。
回避
一度うっとうしかったからといってルールを削除すること。より静かなバージョンも避けること——例外を広げ続け、ついにはルールが何もカバーしなくなる。毎スプリント大きくなるアローリストは、誰もそう決めたわけではないのに、1行ずつルールが退役していっていることを意味する。
本当の区別が意味によるものであるときに、ファイル単位で例外を作ることを避けること。ある文をまるごと禁止するフレーズチェックは、それを打ち消す注意書きまで禁止してしまう。誠実な直し方は、否定表現を要求することであって、そのページのチェックをやめることではない。
確認
縮小した後、元の違反を再び持ち込んでスイートを実行する。それでも失敗しなければならない。
その上でルール自体の差分を読み、問うこと。以前は通らなかったどのクラスの問題が、今なら通ってしまうのか。それに答えられないなら、その縮小は理解されないまま行われたということだ。
リスク
これは例外ごとにテストを追加することになり、例外テストだらけのスイートは読むのが面倒なものになる。
より大きなリスクは、固定したテストをルールが依然として強力であることの証明として扱ってしまうことだ。それが証明するのは、あるケース一つが依然として失敗するということだけだ。5回縮小されたルールには5個の固定ケースがあり、その間に大きな穴が空いている可能性がある。それを見つけられるのは、ルール全体を改めて読み直すことだけだ。
使い方
カードはデータです。リポジトリをクローンし、パスで取り込んでください。ネットワーク経由で届いたものは汚染扱いとなり、承認されるまで保留されます。それが望ましい挙動であり、ここにワンライナーのインストーラーがない理由です。
git clone https://github.com/brcampidelli/chimera-agent.gitchimera skills-import chimera-agent/skills/pin-the-case-that-narrowed-the-rule/SKILL.md完全性
公開された状態のファイルの SHA-256。取り込む側は、受け取ったものがこのページに表示されたものと同じか確認できます。
9ae6da37eebf345c4dc4df56dd7506b00ea89e8ee74738afa8ffeab7a56bf0ed