💬 コミュニケーションコミュニティ 🟢 非エンジニアでもOK 👤 管理職・人事・カスタマー対応

💬 Phase Gated Debugging

phase-gated-debugging

??グの原因が特定されるまでコード編集をブロックし、5段階のプロトコルでデバッグを支援することで、早まった修正を防止するためのSkillです。

⚡ ⏱ クレーム返信ドラフト 15分 → 2分

📺 まず動画で見る(YouTube)

※ jpskill.com 編集部が参考用に選んだ動画です。動画の内容と Skill の挙動は厳密には一致しないことがあります。

📜 元の英語説明(参考)

Use when debugging any bug. Enforces a 5-phase protocol where code edits are blocked until root cause is confirmed. Prevents premature fix attempts.

🇯🇵 日本人クリエイター向け解説

一言でいうと

??グの原因が特定されるまでコード編集をブロックし、5段階のプロトコルでデバッグを支援することで、早まった修正を防止するためのSkillです。

※ jpskill.com 編集部が日本のビジネス現場向けに補足した解説です。Skill本体の挙動とは独立した参考情報です。

⬇ このSkillをダウンロード(.skill) 元のソースを見る ↗

⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。

🎯 このSkillでできること

下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。

📦 インストール方法 (3ステップ)

1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
3. 展開してできたフォルダを、ホームフォルダの .claude/skills/ に置く
- · macOS / Linux: ~/.claude/skills/
- · Windows: %USERPROFILE%\.claude\skills\

Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。

詳しい使い方ガイドを見る →

最終更新: 2026-05-17
取得日時: 2026-05-17
同梱ファイル: 1

💬 こう話しかけるだけ — サンプルプロンプト

› Phase Gated Debugging で、お客様への返信文を作って
› Phase Gated Debugging を使って、社内向けアナウンスを書いて
› Phase Gated Debugging で、メールテンプレートを整備して

これをClaude Code に貼るだけで、このSkillが自動発動します。

📖 Claude が読む原文 SKILL.md(中身を展開)

この本文は AI(Claude)が読むための原文(英語または中国語)です。日本語訳は順次追加中。

Phase-Gated Debugging

Overview

AI coding agents see an error and immediately edit code. They guess at fixes, get it wrong, and spiral. This skill enforces a strict 5-phase protocol where you CANNOT edit source code until the root cause is identified and confirmed.

Based on claude-debug (full plugin with PreToolUse hook enforcement).

When to Use

Use this skill when:

a bug keeps getting "fixed" without resolving the underlying issue
you need to slow an agent down and force disciplined debugging before code edits
the failure is intermittent, a regression, performance-related, or otherwise hard to isolate
you want an explicit user confirmation checkpoint before any fix is applied

The Protocol

Phase 1: REPRODUCE

Run the failing command/test. Capture the exact error. Run 2-3 times for consistency.

Do NOT read source code
Do NOT hypothesize
Do NOT edit any files

Phase 2: ISOLATE

Read code. Add diagnostic logging marked // DEBUG. Re-run with diagnostics. Binary search to narrow down.

Only // DEBUG marked logging is allowed
Do NOT fix the bug even if you see it

Phase 3: ROOT CAUSE

Analyze WHY at the isolated location. Use "5 Whys" technique. Remove debug logging.

State: "This is my root cause analysis: [explanation]. Do you agree, or should I investigate further?"

WAIT for user confirmation. Do NOT proceed without it.

Phase 4: FIX

Remove all // DEBUG lines. Apply minimal change addressing confirmed root cause.

Only edit files related to root cause
Do NOT refactor unrelated code

Phase 5: VERIFY

Run original failing test — must pass. Run related tests. For intermittent bugs, run 5+ times. If verification fails: root cause was wrong, go back to Phase 2.

Bug-Type Strategies

Type	Technique
Crash/Panic	Stack trace backward — trace the bad value to its source
Wrong Output	Binary search — log midpoint, halve search space each iteration
Intermittent	Compare passing vs failing run logs — find ordering divergence
Regression	`git bisect` — find the offending commit
Performance	Timing at stage boundaries — find the bottleneck

Key Rules

NEVER edit source code in phases 1-3 (except // DEBUG in phase 2)
NEVER proceed past phase 3 without user confirmation
ALWAYS reproduce before investigating
ALWAYS verify after fixing

Limitations

Use this skill only when the task clearly matches the scope described above.
Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.