実装とリリースClaude Code and agents that support the skills CLI
Matt Pocock / diagnosing-bugs
エージェントの修正が的外れになりやすいのはなぜか
原因が分かるずっと前に、もっともらしい修正が手に入るからです。
押さえておく点
- 診断と修理は別の仕事です。混ぜると症状パッチが出荷されます。
- 自分の仮説を早く渡すのは、それを検証させるのではなく追認させる最短経路です。
- その原因を次に有力な原因と区別する根拠を求めてください。
- superpowers の systematic-debugging と重複します。両方試して片方に絞ってください。
01実務で何が変わるか
スタックトレースを渡せば、エージェントはほぼ必ずエラーが消える変更を出します。それは欠陥を直したことと同じではなく、差は 1 週間後に、より奇妙なエラーとして現れます。
変更の前に原因の明示を求めると、推論が検査可能になります。原因が間違っていればその場で分かり、回帰で気づくよりはるかに安く済みます。
02期待に届かない点
観察できないものは診断できません。ログがない、再現できない、環境に入れないという制約は、人間の場合とまったく同じように効きます。
些細なバグでは、直接直すより遅くなります。すでに半日溶かした種類の不具合に取っておいてください。
導入と最初の実行
- mattpocock/skills から skills CLI 経由で MIT ライセンスで導入します。
- 自分の仮説ではなく観察を渡します。期待した挙動、実際の挙動、再現手順。
- 原因の明示と根拠が出るまで、いかなる変更も受け入れないでください。
実際によくある質問
- 普通に修正を頼むのと何が違いますか
- コード変更の前に、根拠のある原因の明示を要求します。症状パッチが黙って混入せず可視化されます。
- 自分のバグ仮説は共有すべきですか
- 最初は控えてください。観察と再現手順を渡さないと、自分の仮説が追認されて返ってきます。
- systematic-debugging との比較は
- 狙いは同じで、あちらのほうが構造的です。どちらか一方に絞り、指示を一本化してください。
出典
このページの機械可読版