証明されたテクニック、強力なツール、そしてあらゆる技術スタックで機能する体系的なアプローチを使用して、フラストレーションのたまるデバッグセッションをシステマティックな問題解決に変えましょう。
スキルZIPをダウンロード
Claudeでアップロード
設定 → 機能 → スキル → スキルをアップロードへ移動
オンにして利用開始
テストする
「debugging-strategies」を使用しています。 私の API が断続的に 500 エラーを返します。ログには 'connection refused' と表示されますが、時々だけです。
期待される結果:
これは間欠的な接続問題のようです。システマティックなデバッグを適用しましょう：
**1. 情報収集:** どのリクエストが失敗するか、タイミングパターン、正常時と失敗時のリクエストを比較して確認します。
**2. 仮説を立てる:** 接続プールの枯渇、DNS 解決の遅延、ロードバランサの問題、またはタイムアウト設定が考えられます。
**3. 二分探索:** トラフィックの多い期間と相関があるかを確認することから始めます。接続プールのメトリクスを確認します。
**4. 次のステップ:** コード内の接続リークを確認し、タイムアウト設定を見直し、エラー発生期間中のロードバランサログを調べます。
「debugging-strategies」を使用しています。 Node.js アプリのメモリがクラッシュするまで増え続けます。メモリリークをどう見つけますか？
期待される結果:
メモリプロファイリングを使用してリークを見つけましょう：
**1. メモリトラッキングを有効化:** v8.writeHeapSnapshot() を使用して定期的なヒープスナップショットを追加するか、clinic.js を使用します
**2. モニタリングしながら再現:** アプリを実行し、ヒープ使用量を監視しながら疑わしい操作をトリガーします
**3. スナップショットを比較:** 疑わしい操作の前後にスナップショットを取得し、増加するオブジェクト数を確認します
**4. 一般的な原因:** 削除されていないイベントリスナー、参照を保持するクロージャ、または増え続けるキャッシュを確認します
セキュリティ監査
安全Security scanner flagged 48 potential issues in markdown documentation. After evaluation, all findings are false positives. The flagged patterns are code examples and documentation within markdown files, not executable code. External commands shown are educational CLI examples (git bisect, etc.). Network references are localhost debugging endpoints. This is a legitimate debugging education skill with no security concerns.
品質スコア
作れるもの
本番環境インシデントのデバッグ
システマティックなアプローチを使用して本番環境のバグを調査・診断し、変更を加えずに安全に証拠を収集し、迅速な解決のための根本原因を特定します。
パフォーマンスボトルネックの修正
アプリケーションをプロファイリングして遅い操作を特定し、メモリ使用パターンを分析し、推測ではなく実際のパフォーマンスデータに基づいてコードを最適化します。
捉えにくいバグの追跡
二分探索、微分デバッグ、トレース分析を適用して、特定の条件下でのみ発生するバグや本番環境でのみ現れるバグを見つけます。
これらのプロンプトを試す
このエラーが発生しています：[ERROR_MESSAGE]。エラーは [WHAT_TRIGGERS_IT] ときに発生します。根本原因を見つけるためにシステマティックなデバッグステップを適用するのを手伝ってもらえますか？
私の [APPLICATION/COMPONENT] の動作が遅いです。[OPERATION] の完了に [TIME] かかります。[WHAT_YOU_TRIED] を試しました。プロファイリングツールを使用してボトルネックを見つけるのを手伝ってください。
[FREQUENCY] で発生するバグがありますが、確実に再現できません。[WHAT_IT_AFFECTS] に影響しているようです。これを追跡するためにどのような戦略が使えますか？
本番環境の問題を安全にデバッグするのを手伝ってください。[WHERE_YOU_CAN_SEE_IT] で [ERROR/SYMPTOM] が見えます。最初に何を確認すべきか、そして状況を悪化させないためにどうすればよいですか？
ベストプラクティス
- 問題を理解していることを確認するため、修正を試みる前に常にローカルで問題を再現する
- デバッグ中は一度に 1 つだけ変更し、何が実際に問題を修正するかを特定する
- 将来のデバッグセッションを支援するため、調査結果と仮説をその場で文書化する
- バージョン管理履歴（git bisect）を使用して、回帰がいつ導入されたかを特定する
回避
- 何が問題を修正したかを追跡せずに複数の変更を一度に行う
- 単純なタイプミスや設定問題である可能性があるのに、問題が複雑だと仮定する
- エラーメッセージとスタックトレースを無視する - これらには通常貴重な手がかりが含まれている
- 適切なモニタリングやロールバック計画なしに本番環境でデバッグする