菜单
バグ調査を場当たり的でなく体系的に進める。再現→仮説→検証→修正→回帰テストの順序を守り、仮説と事実を分けて記録する。「バグ調査して」「なぜか動かない」「デバッグ手伝って」などで起動。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | backend-debug-session |
| description | バグ調査を場当たり的でなく体系的に進める。再現→仮説→検証→修正→回帰テストの順序を守り、仮説と事実を分けて記録する。「バグ調査して」「なぜか動かない」「デバッグ手伝って」などで起動。 |
バグ調査を 場当たり的に修正しない。仮説駆動で進める。
ユーザーに以下を確認:
再現手順を 機械的に実行可能な形 で書き出す:
1. <setup>
2. <action>
3. 期待: ...
4. 実際: ...
再現しない場合:
を疑う。再現しないまま先に進まない。
少なくとも 3 つ の仮説を出す（1 つだけだと確証バイアスに陥る）:
仮説 A: <原因候補>
- 根拠: <コード / ログ / 挙動の事実>
- 検証方法: <どうすれば真偽が分かるか>
- 優先度: 高（根拠が強い）/ 中 / 低
仮説 B: ...
仮説 C: ...
優先度の高い仮説から 最小コストで検証:
git log / git blame で最近の変更を確認git bisect で退行コミット特定検証結果を 事実 として記録。仮説欄と混ぜない。
修正前に 失敗するテスト を書く。これが再発防止の要。
backend-test-writer の原則に従ってプロジェクト既存パターンで書くdocs/work/YYYYMMDD_<bug>_postmortem.md に残す（重大な障害の場合）:
# バグ調査記録: <概要>
## 症状
<ユーザーから見た症状>
## 再現手順
1. ...
## 原因
<根本原因。コード引用可>
## なぜ起きたか（5 Why）
1. なぜ X が起きた？ → Y
2. なぜ Y が起きた？ → Z
...
## 修正
- <変更内容の要点>
- 再発防止テスト: <path>
## 類似箇所の点検
- <同じパターンの疑いがあるコードを grep で列挙>
## 参考
- 関連 commit: <hash>
- 関連 issue / PR: <url>
catch (e) {} で握りつぶすdocs/spec/ の仕様書を元に、docs/work/YYYYMMDD_<feature>.md として実装計画書を作成する。Phase 分解・影響範囲・テスト戦略・リスクを構造化し、実装前にユーザー承認を取る。「実装計画立てて」「work 書いて」「どう進めるか計画して」などで起動。
差分や指定コードを構造化されたレビュー観点（正確性・設計・テスト・可読性・セキュリティ）で読み、優先度付きで指摘する。修正は提案するが勝手に書き換えない。「レビューして」「コードレビュー」「セカンドオピニオン」などで起動。
未知のコードベースを最短で把握するための構造化探索を行う。言語・ビルドツール・アーキテクチャ・テスト方針・主要なエントリポイントを短時間でレポート化する。「このプロジェクト教えて」「コードベース調べて」「初見で入ったから概要ほしい」などで起動。
未コミットの変更を依存関係と関心事に基づいて適切な粒度のコミットに分割する。自動生成物・手動実装・テスト・ドキュメントを分離し、レビューしやすい履歴を作る。「コミット分けて」「良い粒度でコミット」「この変更コミットにして」などで起動。
汎用的な開発オーケストレーター。docs/spec/ の仕様と docs/work/ の実装計画書を軸に、Phase 分解と PDCA サイクルで実装を進める。自分は実装せず、各 Phase を Task で専門 agent / Explore / Plan に委託する。「開発進めて」「実装オーケストレートして」「機能実装して」などで起動。
実 DB を起動して Handler → Usecase → Service → Repository を貫通させる integration test を書く。fixture 分離、TestMain/global setup、トランザクション単位のロールバックによるテスト間隔離、API エンドポイントを HTTP 経由で叩く E2E 的検証を扱う。単体テスト(mock 前提)は対象外で `backend-test-writer` に委譲する。「integration test 書いて」「E2E テスト追加して」「DB 込みのテスト書いて」などで起動。