菜单
再現可能な証拠で失敗を再現し、比較・切り分け・最小修正の検証まで進める。リグレッション調査、正常系と異常系の比較、変更前後のデバッグ痕跡を残したいとき。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | debug |
| description | 再現可能な証拠で失敗を再現し、比較・切り分け・最小修正の検証まで進める。リグレッション調査、正常系と異常系の比較、変更前後のデバッグ痕跡を残したいとき。 |
| license | Personal |
この skill は、勘ではなく証拠でデバッグを進めるための共通コアです。 ゴール駆動で使うため、最初に達成したいゴール、成功条件、確認手段を短く固定します。
コア workflow はできるだけ不変に保ち、modules/ 配下のドメイン別モジュールは薄く始めて、実際のデバッグセッションから学んだことだけを追記して育てます。
次のような場面で使います。
gh-pr-create - 修正と検証が終わった後に、証拠付きで PR へつなぐgh-pr-respond - レビューで追加説明が必要になったときに、before/after の根拠で返すknowledge-capture - デバッグで学んだ再利用可能な知見を整理するmodules/ から決めるdebug/<session>/ のような保存先を先に決める最初に読む module を決めるための短い決定表です。どれから証拠を取るべきか曖昧なときは、最も近いものから始め、必要なら evidence-manifest.md を併用します。
| 現象の形 | 最初に読む module | 理由 |
|---|---|---|
| UI、描画、editor、入力、focus、layout のずれ | gui.md | まず見た目と操作の証拠が主役になるため |
| HTTP、認証、service、transaction、cache のずれ | api-backend.md | request と状態境界の切り分けが主になるため |
| data drift、schema 破壊、join、null、aggregate の不具合 | data-etl.md | snapshot と分布比較が重要になるため |
| 機能は正しいが latency、throughput、memory が悪い | performance.md | 機能差分より計測結果が主役になるため |
| 共有順序、idempotency、retry、race、eventual consistency など分散/並行制御が主因らしい | distributed-concurrency.md | ordering と retry ポリシーを固定してから他要因を切り分けるため |
| AI 出力の揺らぎ、seed 変化、時刻依存、retry ノイズ、共有順序や state sync が主因ではない揺らぎ | nondeterminism.md | time と制御変数を握るのが最短だから |
| 個体差、fixture、電源、環境、発生時間、場所、周辺設備、仕様外使用で出たり出なかったりする | embedded-hardware.md | 物理条件や測定品質が owner かもしれないため |
| 何を記録し、どう比較するか自体が曖昧 | evidence-manifest.md | まず証拠パッケージの型を固定するため |
Step 1 で不具合を定義するとき、以下を素早くスキャンして見落としを防ぎます。
何が起きたか、何が起きるべきか、どこで起きるか、最小の再現刺激は何かを一文にまとめます。
報告が曖昧だったり、推測と事実が混ざっているときに使います。Why: 的が安定すると、寄り道の修正が減り、比較も崩れません。
コード変更前に、現在の挙動を否定できない形で残します。必要な中身はモジュールごとに変わりますが、基本は刺激、観測結果、環境またはモードです。
保存先は一箇所に寄せます。
debug/<session>/
manifest.(md|json)
before/
after/
少なくとも一度は再現できるときに使います。Why: baseline がないデバッグは、何が変わったかを証明しにくくなります。
同じリクエスト、同じ入力列、同じデータセット、同じ負荷、同じハード条件を、異常系と比較対象の両方へ流します。変えるのは比較軸を一つずつだけにします。
正常系、別モード、別環境、過去の既知良好サンプルがあるときに使います。Why: 同一刺激比較は、ノイズではなく本当の差を見つける最短ルートです。
選んだモジュールを使い、入力処理、validation、transaction、layout、cache、timing、concurrency、sensor chain などの境界で問題を切ります。期待と現実が最初にずれる境界を探します。
仮説を立て、1 つずつ検証します。複数の仮説を同時に変更すると、どの仮説が正しかったか判定できなくなります。
症状は見えているが、どの層が owner か分からないときに使います。Why: 境界起点で切ると、大きすぎる変更を避けて根本原因へ近づけます。
ずれを消す最小の場所を変えます。証拠が示していない refactor や予防線を、ついでに積み上げないようにします。
外科的対応を既定にし、今回の failure に直接効く変更だけを入れます。長い目で見て Happy にならない複雑化、広すぎる探索、token だけ消費する横展開は避けます。
応急処置と恒久対策を区別し、いま入れるのがどちらかを明示します。
所有境界が十分に見えたときに使います。Why: 小さな修正の方が検証範囲を締めやすく、新しい不具合も生みにくいです。
同じ刺激を流し、証拠パッケージを再構築し、影響面の既存 check を回します。最後に root cause、変更ファイル、実行コマンド、artifact path を引き継ぎます。
修正を入れ終えたときに使います。Why: 同じシナリオを再実行して初めて、単なる変更が検証済み修正になります。
デバッグ完了後に以下の形式で結果をまとめます。引き継ぎ、PR、ポストモーテムに再利用できます。
modules/ 配下は、コア workflow を置き換えるものではなく付録です。最初は薄く置き、実際のデバッグセッションで役立った内容だけを追記します。
| Module | 使う場面 | 現在の状態 |
|---|---|---|
gui.md | UI、描画、editor、入力、focus、layout の不具合 | 現時点の主力 |
api-backend.md | HTTP、認証、service、transaction、cache の不具合 | 薄い starter |
data-etl.md | pipeline、schema、join、分布、null 処理の不具合 | 薄い starter |
performance.md | latency、memory、throughput、hot path の不具合 | 薄い starter |
distributed-concurrency.md | ordering、retry、race、sync、eventual consistency の不具合 | 薄い starter |
embedded-hardware.md | sensor、waveform、calibration、fixture、環境条件の不具合 | 薄い starter |
nondeterminism.md | time、seed、retry、parallelism の横断課題 | 薄い starter |
evidence-manifest.md | 何をどう記録し比較するかの標準化 | 薄い starter |
現象が intermittent だからといって、最初から hardware と決めつけないでください。最初の手掛かりに最も合う evidence shape の module から入り、最初の比較結果を見てから広げます。
こんなときに使う: Ubuntu / Linux サーバーに SSH で接続し、sudo、systemd サービス、HTTP 監視を一連で安全に進めたいとき。 接続前に SSH_AUTH_SOCK を含む認証状態を固定し、認証で止まらずに サーバー接続・権限確認・サービス起動・停止・再起動・状態確認を一気に行いたいとき。
調査→修正→検証→ふりかえり/後続 Issue 化までを 1 つの改善ループで回したいときに使う。 実装前の再現確認や、review 指摘・検証結果をもとに次のアクションへつなぐ。
こんなときに使う: 現在の会話内容をもとに、実装・エージェント発注に直結する PRD を作りたいとき。 追加のインタビューはせず、すでに会話に出ている内容だけから構成する。 情報が不足している場合は捏造せず「未確定」として明示する。
こんなときに使う: ユーザーが「インタビューして」「質問して」「設計を詰めたい」などと言ったら使う。 計画や設計の重要な判断軸を洗い出し、具体例・反例・影響範囲まで深掘りして要件整理に落とす。
Copilot の custom skill / agent / repository instructions の作成・改善・構造確認を 1 つの入口にまとめる。複合スキルとして、対象に応じて適切な authoring ルートへ 分けつつ、実行時のモデル呼び出しを抑止してルーティングを優先する。試作から `plugins/*` 配布へ昇格するときの name / description 整備も扱う。skill / agent / repo-wide instructions / path-specific instructions を新規作成したいとき、既存定義を育てたいとき、公開前に責務や導線を確かめたいとき。
新しい custom agent を既存 agent 群と同じ型で立ち上げる。agent の新規追加、役割分離のための専門 agent 作成、既存群の隙間を埋めたいとき。