効果を実測する

hotspot ランキングは予測です ——「ここを直せば一番効く」という。実際に直して複雑度がどれだけ動いたかを測るまで、その主張は検証されていません。

dowsing diff がその隙間を埋めます。

dowsing diff origin/main

📉 複雑度の実測（base → head）:
  cognitive -41 / cyclomatic -22 / LoC -111

負の値が改善です。改善しなかった場合も、そのまま報告します。

何をしているか

変更されたファイルごとに、両方のリビジョンからソースを読み直し（作業ツリーではなく git から直接）、それぞれ解析して引き算します。

ここには有用な帰結があります。誰が変更したかを問わないのです。手で書いたコミットでも、エージェントのリファクタでも、自動の codemod でも、CI 上の PR でも、同じように測れます。有効化する設定も、呼び出すモデルもありません。

dowsing は直しません

以前のバージョンには dowsing fix があり、修正を Claude Code に委任し、検証し、差分を測っていました。動きはしましたが、通常の呼び出し経路は エージェント → dowsing であり、その内側で dowsing がさらに別のエージェントを起動するのは関係が逆立ちしています。外側のエージェントのほうが会話の文脈もレビューのループもユーザーも持っていて、変更を加えるには圧倒的に有利な位置にいます。

そこで「直す」を捨てて「測る」を残しました。引き換えに、測ることは安くなり、回数が増えました —— dowsing 自身が起こした変更のときだけでなく、毎 PR で回るようになったからです。

プルリクエストで

dowsing diff origin/main --markdown

Markdown 出力には、PR が触れた場所のリスクと複雑度の差分が入っていて、そのままコメントとして貼れます。

指標	base	head	差分
cognitive	180	139	-41
cyclomatic	96	74	-22
LoC	620	509	-111

すぐ使えるワークフローが templates/github-actions/ にあります。fetch-depth: 0 を忘れないでください —— shallow clone では比較対象の履歴がありません。

これが答えないこと

• 変更の良し悪しは判定しません。 複雑度が増えることは自動的に悪ではありません（本物の新機能は分岐を増やします）。この数値はレビュアのための文脈であって、ゲートではありません。
• 解析対象のファイルしか見えません。 生成物・vendored でない .ts / .tsx のみです。
• 品質スコアではありません。 ビルドを落とす閾値が要るなら dowsing check を使ってください。