家
体系的なデバッグセッション — 現象の再現、原因の特定、診断、修正を行います。エラーメッセージやスタックトレース、あるいは「ステージング環境では動作するが本番環境では動作しない」「デプロイ後に何かが壊れた」といったケース、または動作が期待通りではなく原因が明らかでない場合に、このセッションを開始します。
...すべて拡張します概要debug
「debug 」スキルは、ソフトウェアの動作が不正、不明瞭、または退行している場合に、構造化されたdebuggingワークフローを通じてユーザーを導くように設計されています。 このスキルは、エラーメッセージ、スタックトレース、または予期しない動作によって、即座に診断できない問題が示唆されるような状況での利用を想定しています。「debugging」プロセスを明確なフェーズに整理することで、ユーザーが推測に頼るのではなく、体系的な方法で症状の観察から根本原因の特定へと進むことを支援します。
このスキルは、「再現」「特定」「診断」「修正」という4つのステップからなる方法論に従います。再現フェーズでは、期待される動作と実際の動作を明確にし、問題を再現するための確実な手順を確立することに重点を置きます。特定フェーズでは、デプロイ、設定の更新、依存関係の変更などの最近の変更点を確認するとともに、ログやエラー出力を分析することで、影響を受けているコンポーネントを絞り込みます。 診断段階では、仮説の立案と検証、実行パスの追跡、そして表面的な症状ではなく根本原因の特定に重点が置かれます。最後に、修正段階では、副作用を考慮しつつ是正措置を提案し、リグレッションを防ぐための予防的なテストを推奨することに焦点を当てます。
このスキルは、主に本番環境や開発環境の問題を日常的にトラブルシューティングする開発者、DevOpsエンジニア、QAテスター、サイト信頼性エンジニアを対象としています。特に、デプロイによるリグレッション、環境固有のバグ（例：ステージング環境と本番環境の違い）、あるいは最近の変更後に発生した原因不明の障害といったシナリオで役立ちます。 規律あるdebugging構造を徹底することで、試行錯誤debuggingを減らし、インシデント解決ワークフローの一貫性を向上させます。
よくある質問
このdebuggingスキルを使用するには、どのような情報を提供すればよいですか？
エラーメッセージ、スタックトレース、予期しない動作の説明、再現手順、あるいは最近の変更やログなどのコンテキストを提供してください。情報が正確であればあるほど、debuggingプロセスはより効果的になります。
このスキルは、外部ツールやコネクタへのアクセスを必要としますか？
監視システム、ソース管理、プロジェクト追跡ツールなど、接続済みのコネクタが利用可能な場合は、オプションとしてそれらを活用できます。ただし、提供された説明、ログ、およびコンテキストのみでも機能します。
このスキルはどのような問題には適していませんか？
純粋に理論的な質問や一般的な説明を目的としたものではありません。具体的には、観察可能な不正な動作を伴う具体的なソフトウェアの問題の診断と解決に焦点を当てています。
/debug
If you see unfamiliar placeholders or need to check which tools are connected, see CONNECTORS.md.
Run a structured debugging session to find and fix issues systematically.
Usage
/debug $ARGUMENTSHow It Works
┌─────────────────────────────────────────────────────────────────┐│ DEBUG │├─────────────────────────────────────────────────────────────────┤│ Step 1: REPRODUCE ││ ✓ Understand the expected vs. actual behavior ││ ✓ Identify exact reproduction steps ││ ✓ Determine scope (when did it start? who is affected?) ││ ││ Step 2: ISOLATE ││ ✓ Narrow down the component, service, or code path ││ ✓ Check recent changes (deploys, config changes, dependencies) ││ ✓ Review logs and error messages ││ ││ Step 3: DIAGNOSE ││ ✓ Form hypotheses and test them ││ ✓ Trace the code path ││ ✓ Identify root cause (not just symptoms) ││ ││ Step 4: FIX ││ ✓ Propose a fix with explanation ││ ✓ Consider side effects and edge cases ││ ✓ Suggest tests to prevent regression │└─────────────────────────────────────────────────────────────────┘What I Need From You
Tell me about the problem. Any of these help:
- Error message or stack trace
- Steps to reproduce
- What changed recently
- Logs or screenshots
- Expected vs. actual behavior
Output
## Debug Report: [Issue Summary]### Reproduction- **Expected**: [What should happen]- **Actual**: [What happens instead]- **Steps**: [How to reproduce]### Root Cause[Explanation of why the bug occurs]### Fix[Code changes or configuration fixes needed]### Prevention- [Test to add]- [Guard to put in place]
If Connectors Available
If ~~monitoring is connected:
- Pull logs, error rates, and metrics around the time of the issue
- Show recent deploys and config changes that may correlate
If ~~source control is connected:
- Identify recent commits and PRs that touched affected code paths
- Check if the issue correlates with a specific change
If ~~project tracker is connected:
- Search for related bug reports or known issues
- Create a ticket for the fix once identified
Tips
- Share error messages exactly — Don't paraphrase. The exact text matters.
- Mention what changed — Recent deploys, dependency updates, and config changes are top suspects.
- Include context — "This works in staging but not prod" or "Only affects large payloads" narrows things fast.
debugをインストール
スキルファイルをダウンロードし、.claude/skills/ ディレクトリに解凍してください。
ZIPをダウンロードリポジトリをクローンし、スキルファイルをプロジェクトにコピーしてください。
git clone https://github.com/anthropics/knowledge-work-plugins/blob/main/engineering/skills/debug/SKILL.md # Copy SKILL.md to your .claude/skills/ directory
コピー
