メニュー
エラー・バグ・問題を体系的に分析し修正方針を策定する。テスト失敗、ビルドエラー、実行時エラー、動作不良、バグ報告に対応し、根本原因を分析してから修正を行う。Do NOT use for 根本原因分析が不要な軽微な修正（typo、設定値変更、フォーマット修正など）。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Jules REST APIを使用してタスクを対話的に依頼・管理する。セッション作成・プラン承認・メッセージ送信・進捗監視をAPI経由で行い、Claudeと協調してタスクを完遂する。ベースブランチ指定とPR自動作成に対応。認証はJULES_API_KEY_OP_URI（1Passwordシークレット参照）またはJULES_API_KEYで行う。Do NOT use for 認証情報未設定の環境でのタスク実行（task-executingを使用すること）。
SDDワークフロー全体を統括するオーケストレーター。要件定義・設計・タスク計画・実装・逆順レビューの一連のフローを管理する。新規プロジェクトのSDD一括作成、複数フェーズにまたがるワークフロー管理、エラー・バグの体系的な分析と修正に使用する。Do NOT use for 個別フェーズのみの作業（requirements-defining、software-designing、task-planningを直接使用すること）。
設計書から実装タスクへの分解を行う。デフォルトで各タスクをGitHub Issueとして起票し（1タスク＝1 Issue、詳細はIssue本文に集約、ラベルでフェーズ・ステータス管理）、ユーザーがファイル管理を明示した場合のみdocs/sdd/tasks/にファイル生成する。AIエージェント向けの具体的な実装指示やTDD手順を定義する。タスク計画フェーズのみを単独で実行する際に使用する。Do NOT use for SDDワークフロー全体の管理（sdd-documentationを使用すること）。
SDDドキュメントの整合性チェック、実装同期確認、アーカイブ（CLAUDE.md同期含む）、ファイル最適化を行う。ドキュメント間の矛盾検出、実装との乖離確認、完了タスクの整理と仕様のCLAUDE.md転記、肥大化ファイルの分割が必要な場合に使用する。Do NOT use for ドキュメントの新規作成（requirements-defining、software-designing、task-planningを使用すること）。
IPA非機能要求グレード2018（可用性・性能拡張性・運用保守性・移行性・セキュリティ・システム環境）の記入済み要件を入力として、運用設計書を生成する。非機能要件定義が完了しているプロジェクトの運用設計フェーズで使用する。Do NOT use for 非機能要件の定義自体（requirements-definingを使用すること）。Do NOT use for 業界調査やヒアリングから始める運用設計（operations-designを使用すること）。
EARS記法を用いた要件定義書を作成・編集する。ユーザーストーリーの作成、受入基準の定義、非機能要件の整理が必要な場合に使用する。要件定義フェーズのみを単独で実行する際に使用する。Do NOT use for SDDワークフロー全体の管理（sdd-documentationを使用すること）。
| name | sdd-troubleshooting |
| description | エラー・バグ・問題を体系的に分析し修正方針を策定する。テスト失敗、ビルドエラー、実行時エラー、動作不良、バグ報告に対応し、根本原因を分析してから修正を行う。Do NOT use for 根本原因分析が不要な軽微な修正（typo、設定値変更、フォーマット修正など）。 |
| metadata | {"version":"1.0.0"} |
デバッグ・エラー修正・問題分析のための中核スキル。あらゆる問題に対して体系的に分析し、仕様に基づいた修正方針を策定します。
┌─────────────────────────────────────────────────────────────────┐
│ エラー・バグ発生時の鉄則 │
├─────────────────────────────────────────────────────────────────┤
│ 1. 修正コードを書く前に、必ず根本原因を特定する │
│ 2. 推測に基づく修正は禁止（「たぶんこれが原因」はNG） │
│ 3. 修正方針は必ずユーザー承認を得てから実装に進む │
│ 4. 原因不明のまま「とりあえず動くように」は禁止 │
└─────────────────────────────────────────────────────────────────┘
エラー/バグ発生
↓
1. 問題事象の確認（現象、再現手順、期待動作）
↓
2. ★ 並列調査判定 ★（原因候補が3つ以上 → Agent toolで並列調査）
↓
┌─ YES → Agent toolで並列調査（下記参照）
└─ NO → 単一セッションで分析続行
↓
3. 根本原因の分析（コードを追跡して原因を特定）
↓
4. 仕様との照合（docs/sdd/requirements/, docs/sdd/design/）
↓
5. 修正方針の策定（どう直すか、影響範囲は）
↓
6. ★ ユーザー承認 ★（必須ゲート - 承認なしで実装禁止）
↓
7. タスク分割 → GitHub Issue起票（デフォルト）/ docs/sdd/tasks/（オプション）
詳細な分析手法: references/analysis_guide_ja.md
以下のいずれかに該当する場合は、このスキルを使用する。
❌ エラーメッセージを見てなんとなく修正
❌ とりあえずtry-catchで囲む
❌ 似たエラーを以前直したから同じ修正
❌ 検索で見つけた解決策をそのまま適用
❌ 原因はわからないが動くようになった
✅ このスキルで根本原因を特定 → 修正方針を承認 → 実装
収集する情報:
| 項目 | 内容 |
|---|---|
| 現象 | 何が起きているか |
| 期待動作 | 本来どう動くべきか |
| 再現手順 | どうすれば再現できるか |
| 発生環境 | どの環境で起きるか |
| エラー情報 | エラーメッセージ、ログ、スタックトレース |
分析テクニック: references/analysis_guide_ja.md
検討項目:
修正方針をユーザーに提示し、承認を得てから次に進む。
修正方針について承認をお願いします。
【修正方針サマリー】
- 問題: [問題の概要]
- 原因: [原因の概要]
- 修正内容: [修正の概要]
- 影響範囲: [影響範囲の概要]
上記の修正方針で進めてよろしいでしょうか？
sdd:task + sdd:bugfix）。mcp__github__issue_write（create）を使用タスクテンプレート:
docs/sdd/troubleshooting/
└── [YYYY-MM-DD]-[issue-name]/
└── analysis.md
分析レポートテンプレート: assets/templates/analysis_report_template_ja.md
sdd-documentation
├── requirements-defining → docs/sdd/requirements/
├── software-designing → docs/sdd/design/
├── task-planning → GitHub Issue（デフォルト）/ docs/sdd/tasks/
├── task-executing → 実装コード
└── sdd-troubleshooting → 問題分析・修正タスク（このスキル）
連携するドキュメント:
sdd:task+sdd:bugfix / オプション: docs/sdd/tasks/）原因が不明な複雑なバグの場合、Agent toolを使用して複数の仮説を並列で調査する。各サブエージェントが異なる仮説を担当し、並列に調査を進めることで、より迅速に根本原因に到達する。
重要: ワークフローのステップ2で以下の条件を評価し、満たす場合は必ずAgent toolで並列調査すること。
調査は読み取り専用のためisolation: worktreeは不要。1つのメッセージで複数のAgent toolを同時に呼び出す。
【Agent tool 呼び出し1】
subagent_type: general-purpose
prompt: |
以下の仮説について調査してください。
問題: [問題の概要]
仮説1: データフロー・状態管理の問題
調査対象: src/state/, src/hooks/
調査手順:
1. 関連コードを読み取り
2. データフローを追跡
3. 問題の有無を判定
4. 証拠（該当コード箇所）を収集
結果を以下の形式で報告:
- 仮説の支持/棄却
- 根拠（具体的なコード箇所と説明）
- 追加発見事項
【Agent tool 呼び出し2】
subagent_type: general-purpose
prompt: |
仮説2: API通信・認証の問題
調査対象: src/api/, src/auth/
...（同様の構造）
【Agent tool 呼び出し3】
subagent_type: general-purpose
prompt: |
仮説3: 非同期処理・タイミングの問題
調査対象: src/services/, src/workers/
...（同様の構造）
注意: 相互反証が特に重要な場合は、エージェントチーム（CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS）の使用を検討。メンバー間で直接発見を共有・反証できる。
並列処理パターンの詳細: sdd-documentation/references/agent_teams_guide_ja.md
1. 各サブエージェントの調査結果を統合
2. 最も有力な根本原因を特定
3. 通常のフローに戻る:
- 仕様との照合
- 修正方針の策定
- ★ ユーザー承認 ★
- タスク分割
sdd-troubleshootingで修正タスクを追加した場合、TodoWriteにも同期します:
1. 修正タスクを作成
- Issueモード（デフォルト）: mcp__github__issue_write（create）でラベル sdd:task+sdd:bugfix 付きIssueを起票
- ファイルモード: docs/sdd/tasks/に作成
2. TodoWriteに修正タスクをpendingで追加:
todos = [
...既存のtodo...,
{ content: "[Phase-N/TASK-XXX](#20) [BugFix] 問題の修正", status: "pending", activeForm: "[TASK-XXX] 問題を修正中" }
]
修正タスクには[BugFix]プレフィックスを付けてTodoWriteに登録し、通常タスクと区別（Issueモードは末尾に (#Issue番号)）:
[Phase-2/TASK-010](#20) [BugFix] 認証トークンの有効期限チェック修正
| リソース | 内容 |
|---|---|
| references/analysis_guide_ja.md | 分析テクニック、問題分類、チェックリスト |
| assets/templates/analysis_report_template_ja.md | 分析レポートテンプレート |
| assets/templates/bugfix_task_template_ja.md | バグ修正タスクテンプレート |