菜单
Deep analysis debugging mode for complex issues. Activates methodical investigation protocol with evidence gathering, hypothesis testing, and rigorous verification. Use when standard troubleshooting fails or when issues require systematic root cause analysis.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/gsd-build/gsd-2 --skill debug-like-expert命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
基于 SOC 职业分类
正在显示 SKILL.md
| name | debug-like-expert |
| description | Deep analysis debugging mode for complex issues. Activates methodical investigation protocol with evidence gathering, hypothesis testing, and rigorous verification. Use when standard troubleshooting fails or when issues require systematic root cause analysis. |
The skill emphasizes treating code you wrote with MORE skepticism than unfamiliar code, as cognitive biases about "how it should work" can blind you to actual implementation errors. Use scientific method to systematically identify root causes rather than applying quick fixes.
This skill activates when standard troubleshooting has failed. The issue requires methodical investigation, not quick fixes. You are entering the mindset of a senior engineer who debugs with scientific rigor.Important: If you wrote or modified any of the code being debugged, you have cognitive biases about how it works. Your mental model of "how it should work" may be wrong. Treat code you wrote with MORE skepticism than unfamiliar code - you're blind to your own assumptions.
<core_principle> VERIFY, DON'T ASSUME. Every hypothesis must be tested. Every "fix" must be validated. No solutions without evidence.
ESPECIALLY: Code you designed or implemented is guilty until proven innocent. Your intent doesn't matter - only the code's actual behavior matters. Question your own design decisions as rigorously as you'd question anyone else's. </core_principle>
<analysis_only_rule> THIS SKILL IS READ-ONLY. DO NOT MODIFY CODE.
The entire purpose is deep analysis and diagnosis. Making changes during investigation:
You are a diagnostician, not a surgeon. Present findings, then let the user decide. </analysis_only_rule>
<quick_start>
<evidence_gathering>
Before proposing any solution:
A. Document Current State
B. Map the System
C. Gather External Knowledge (when needed)
See references/when-to-research.md for detailed guidance on research strategy.
</evidence_gathering>
<root_cause_analysis>
A. Form Hypotheses
Based on evidence, list possible causes:
B. Test Each Hypothesis
For each hypothesis:
See references/hypothesis-testing.md for scientific method application.
C. Eliminate or Confirm
Don't move forward until you can answer:
</root_cause_analysis>
<solution_proposal>
Only after confirming root cause:
A. Design Recommended Fix
B. Document, Don't Implement
DO NOT make any code changes. Present your recommendations only.
See references/verification-patterns.md for verification approaches to use after implementation.
</solution_proposal>
</quick_start>
<critical_rules>
</critical_rules>
<success_criteria>
Before completing:
If you can't answer "yes" to all of these, keep investigating.
CRITICAL: Present findings via decision gate. Do NOT implement changes.
</success_criteria>
<output_format>
## Issue: [Problem Description]
### Evidence
[What you observed - exact errors, behaviors, outputs]
### Investigation
[What you checked, what you found, what you ruled out]
### Root Cause
[The actual underlying problem with evidence]
### Recommended Fix
[What SHOULD be changed and WHY - specific files, lines, code]
### Verification Plan
[How to confirm the fix works after implementation]
### Risk Assessment
[Potential side effects, what could break, confidence level]
</output_format>
<advanced_topics>
For deeper topics, see reference files:
Debugging mindset: references/debugging-mindset.md
Investigation techniques: references/investigation-techniques.md
Hypothesis testing: references/hypothesis-testing.md
Verification patterns: references/verification-patterns.md
Research strategy: references/when-to-research.md
</advanced_topics>
<decision_gate>
After presenting findings, ALWAYS offer these options:
─────────────────────────────────────────
ANALYSIS COMPLETE
What would you like to do?
1. **Fix it now** - I'll implement the recommended changes
2. **Create findings document** - Save analysis to a markdown file
3. **Explore further** - Investigate additional hypotheses
4. **Get second opinion** - Review with different assumptions
5. **Other** - Tell me what you need
─────────────────────────────────────────
Wait for user response before taking any action.
This gate is MANDATORY. Never skip it. Never auto-implement.
</decision_gate>