diagnosing-bugs (Matt Pocock)

レビュー

Mac テストマシン上で Codex CLI 0.166（gpt-6-astra、低推論）、実行ごとに新規の一時プロジェクトと一時 HOME/TMPDIR/キャッシュを使用、スキルをインストール（スキルあり群）、スキルなし（対照群）、またはスキルの中核要件をプロンプト末尾に付けた一文に圧縮（一文プロンプト群）、タスクごとに各群 2 実行、ネットワーク無効、/tmp への書き込みはブロック。プロンプトはスキル名に一切言及しません。採点はプログラム的（隠しテスト／仕込み問題の検出／制約チェック／該当する場合はレンダリング+OCR）で、実行ごとに 0〜5 点。スコアはどの LLM 判定者も決めていません。

3群の比較

Codex CLI で 18 実行を計測し、LLM 判定なしのルールベースのチェックで採点。合計 22.9 / 30、判定は 状況次第。

判定：状況次第（22.9 / 30）。 出典：mattpocock/skills、skills/engineering/diagnosing-bugs、コミット 4ae2317 に固定。インストール：npx skills@latest add mattpocock/skills --skill diagnosing-bugs。ライセンス： MIT（リポジトリの LICENSE）。

概要

Matt Pocock の skills リポジトリ（engineering）の diagnosing-bugs スキル。難しいバグのための規律です。フェーズ 1 は「厳密な pass/fail フィードバックループを構築する」（失敗するテスト、curl スクリプト、CLI diff、ヘッドレスブラウザ、トレースの再実行）。その後、順位付けした仮説を 1 つずつ検証し、計装、回帰テスト、クリーンアップを行います。約 1,000 語の Markdown、hitl-loop.template.sh ヘルパーテンプレート 1 つ、出力を見せる前にシークレットを伏せるルール。'diagnose'、'debug this'、'something is broken/failing' でトリガーされます。

テスト方法

Mac テストマシン上で Codex CLI 0.166（gpt-6-astra、低推論）、実行ごとに新規の一時プロジェクトと一時 HOME/TMPDIR/キャッシュを使用、スキルをインストール（スキルあり群）、スキルなし（対照群）、またはスキルの中核要件をプロンプト末尾に付けた一文に圧縮（一文プロンプト群）、タスクごとに各群 2 実行、ネットワーク無効、/tmp への書き込みはブロック。プロンプトはスキル名に一切言及しません。

1. 小さな関数のオフバイワン — movavg.py の moving_average が誤った数値を返します：moving_average([2, 4, 6, 8, 10], 3) は [2, 3, 4, 6, 8] になるべきなのに、後半の値が間違っています。原因を見つけて修正してください。テスト：python3 -m unittest。
2. 複数ファイルにまたがる日付バグ — 週次レポートのヘッダーが年始前後に誤った日付を表示します。例：header('2026-W01') は 'Week 2026-W01: Dec 29 - Jan 04, 2026' になるべき。原因を見つけて修正してください。
3. 順序依存のテスト失敗 — tests/test_settings.py のテストは単体では通りますが、ファイル全体を実行すると test_b が失敗し、設定が以前の呼び出しのタグを引き継いでいるようです。診断して修正してください。

採点はプログラム的（隠しテスト／仕込み問題の検出／制約チェック／該当する場合はレンダリング+OCR）で、実行ごとに 0〜5 点。スコアはどの LLM 判定者も決めていません。

結果

第 3 群に与えた一文プロンプト："まず、この特定のバグで赤になる、高速で決定的な pass/fail フィードバックループを構築する（失敗するテストが最良）。次に順位付けした仮説を立て、修正前に証拠をもって 1 つずつ検証し、ループを再実行して修正を確認する。"

平均スコア：スキルなし 4.31 vs スキルあり 4.58（差分 +0.28）。1 実行あたりのトークン：77k vs 133k（1.71 倍）。時間：38s vs 51s。一文プロンプト群：4.72（一文プロンプトに対するスキルの上乗せ：-0.14。一文プロンプト自身のスキルなしに対する上乗せ：+0.42）。一文プロンプトのトークンは 1 実行あたり 126k、つまりスキルのコストは一文プロンプトの 1.05 倍。

何が起きたか

• 最終的な正しさは 3 群すべてで同じでした。隠しテストは 18/18 実行で合格し、すべての差分は小差分の制限内に収まりました。この 3 つの仕込みバグ（オフバイワン、複数ファイルにまたがる日付ロジック、順序依存のテスト汚染）は、素の Codex が修正できる程度に簡単です。
• 動いたのは「コードを編集する前にテストを実行したか」というプロセスチェック、つまり再現を先に行うかどうかだけでした。スキルなしは 1/6 実行、スキルの最初のルールの一文版は 4/6、スキルありは 4/6。つまり一文で効果のすべてを再現しました。
• スキルは、どのプロンプトも言及しなかったにもかかわらず、スキルあり群 6/6 実行で読み込まれました（'debug this' でトリガー）。エージェントの作業量は増えました：1 実行あたり 18 コマンド（スキルなしは 8、一文プロンプトは 13）。
• コスト：スキルありは 1 実行あたり 133k トークン（スキルなし 77k、1.71 倍）、一文プロンプトは 126k（1.05 倍）。一文プロンプト群自体が対照群の 1.64 倍かかったのは、最初にループを構築するよう指示するとステップが増えるためです。
• スキルありの 1 実行（shared-state タスク）はバグを修正して隠しテストに合格しましたが、回答が私たちの根本原因チェック（原因が名指しされているかを確認）に合致しませんでした。どの群でもこれを逃したのはその実行だけです。

評価項目別スコア

このテストの限界

• コードを読めば見つかる、小さな単一ファイルの Python バグ 3 つ。このスキルは難しいバグ（フレーキー、性能回帰、ハーネスが必要なバグ）向けに作られており、そのいずれもテストしていません。
• スキルのその他のツール（HTTP/ブラウザループ、トレース再生、二分探索、計装タグ）は、駆動するアプリのないネットワーク無効サンドボックスでは実行できません。
• 「編集前にテストを実行したか」チェックは、イベントログにおける最初のテストコマンドと最初の書き込みの順序を比較するもので、再現の質は判定しません。
• タスク・群ごとに n=2。約 1 ポイント未満の差はノイズです。
• ルールベースの採点はチェックが捉えられる範囲を測るもので、センスや、その結果が最善かどうかは判定できません。

セキュリティ

security.md を参照。スキャン：CRITICAL 0 / HIGH 0 / MEDIUM 0。判定：実行しても安全（ネットワーク無効のサンドボックス）。クリーンなスキャン結果はスキルの安全性を証明しません。

結論

このスキルの中心的な考えは良い習慣で、指示すれば Codex はそれに従います。ただしその一文でも、ほぼ同じコストで同じ「再現を先に」という振る舞いと同じ合格率が得られ、簡単なバグではどちらでもエージェントは修正できます。難しいフレーキーなバグをデバッグし、完全な規律を求めるならインストールしておいてください。小さなバグでは、その最初のルールをプロンプトに書くだけで効果が得られます。