下载技能 ZIP
在 Claude 中上传
前往 设置 → 功能 → 技能 → 上传技能
开启并开始使用
测试它
正在使用“debugging”。 Debug this: My function sometimes returns undefined even though the data exists
预期结果:
- Phase 1: Root Cause Investigation - examining error patterns and tracing data flow
- Phase 2: Pattern Analysis - comparing with working implementations
- Phase 3: Hypothesis Testing - testing theory about timing or null states
- Phase 4: Implementation - creating failing test, fixing at source, verifying
正在使用“debugging”。 The test is failing but I cannot see why. Can you debug this?
预期结果:
- Phase 1: Complete error message and stack trace analysis
- Phase 2: Compare failing test with similar passing tests
- Phase 3: Form hypothesis about what differs
- Phase 4: Create minimal failing test, identify root cause, verify fix
正在使用“debugging”。 Debug this production issue: Users are reporting 500 errors intermittently
预期结果:
- Phase 1: Gather error patterns - when does it happen, what errors appear
- Phase 2: Look for common factors in failing requests
- Phase 3: Hypothesis about resource limits, race conditions, or external dependencies
- Phase 4: Implement monitoring, fix at source, add regression test
安全审计
安全This is a pure prompt-based documentation skill containing only markdown guidance for a four-phase debugging methodology. No executable code, scripts, network calls, or file system access exist. All 24 static findings are false positives: metadata URL fields misidentified as network threats, debugging terminology ('trace', 'test', 'echo') misidentified as command execution, and markdown code examples misidentified as shell scripts.
风险因素
🌐 网络访问 (1)
📁 文件系统访问 (1)
质量评分
你能构建什么
修復重複出現的錯誤
透過識別實際根本原因來調查為何錯誤在多次修復嘗試後持續重現
分析測試失敗
使用資料流分析和可運作程式碼比較將測試失敗追蹤到其來源
偵錯生產環境問題
在時間壓力下對生產系統中的異常行為應用系統化調查
试试这些提示
Debug this error: [paste error message]. Apply the four-phase debugging framework. Show your root cause investigation before proposing any fix.
I tried [previous fix approaches] but the issue persists. Use the debugging skill and return to Phase 1. What am I missing?
Debug this issue in our API → Service → Database system. The error occurs at [location]. Trace the data flow to find where bad data originates.
We have attempted 3+ fixes that each revealed new problems. Apply Phase 4.5 - question architecture. Is this pattern sound or should we discuss refactoring?
最佳实践
- 在任何修復前務必完成階段 1 - 理解「為什麼」比快速解決方案更重要
- 在假設測試期間一次只改變一件事以隔離真正有效的方法
- 在 3 次以上修復嘗試失敗後,質疑架構而非繼續修補
避免
- 同時嘗試多個修復 - 這使得無法得知是什麼解決了問題
- 修復症狀(錯誤出現的地方)而非根本原因(錯誤資料的起源)
- 在時間壓力下跳過錯誤訊息分析 - 堆疊追蹤通常包含確切的解決方案