菜单
Systematic debugging approach for errors, test failures, and unexpected behavior. Use when encountering bugs, test failures, errors, or when debugging is needed. Prevents common anti-patterns like random fixes, skipping root cause analysis, and thrashing.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
Recovers web content when searches fail with 403, 429, 422 errors, blocked sites, or empty results. Runs bundled Tavily/Jina extraction scripts, then falls back to manual strategies.
Detects natural language handoff requests and generates structured context summaries for seamless thread continuation. Use when user says "handoff", "new thread", "continue in fresh thread", or similar phrases.
Generates git commit messages following conventional commit standards with collaborative attribution. Use when user requests commit message creation, drafting, or help with formatting.
基于 SOC 职业分类
| name | systematic-debugging |
| description | Systematic debugging approach for errors, test failures, and unexpected behavior. Use when encountering bugs, test failures, errors, or when debugging is needed. Prevents common anti-patterns like random fixes, skipping root cause analysis, and thrashing. |
A systematic approach to debugging that ensures you understand the root cause before attempting fixes. This reduces thrashing, prevents new bugs, and saves time.
Use this skill when you encounter:
This skill provides structure to prevent:
"This test is failing: AssertionError: Expected 200 but got 500"
"help me debug this failing test suite"
"Why is the user auth test suddenly broken?"
"I'm getting TypeError: Cannot read property 'x' of undefined"
"This worked yesterday but now throws an error"
"Something's broken after my refactor"
"The CI pipeline is failing randomly"
"Build works locally but fails in production"
"Getting intermittent failures in our deployment"
Gather information about the problem:
Can you trigger the issue reliably?
Where exactly does the problem occur?
Address the root cause, not the symptom:
Confirm it actually works:
If you catch yourself thinking any of these, STOP and return to step 1:
| Thought | What To Do Instead |
|---|---|
| "Quick fix for now, investigate later" | Investigate now. Quick fixes create new bugs. |
| "Just try changing X and see if it works" | Form a hypothesis first. Test one variable at a time. |
| "Add multiple changes, run tests" | One change at a time. Otherwise you can't isolate what worked. |
| "Skip the test, I'll manually verify" | Write the test. Untested fixes don't stick. |
| "It's probably X, let me fix that" | Verify X is the root cause before fixing. |
| "One more fix attempt" (after 2+ failures) | Stop. 3+ failed fixes usually means architectural problem. |
Pattern indicating deeper problem:
Stop and question fundamentals:
This is not a failed hypothesis—this is likely a wrong architecture.
When debugging across layers (CI → build → deploy, API → service → database):
Add diagnostic logging at each boundary before fixing:
# At each component boundary:
# - Log what data enters the component
# - Log what data exits the component
# - Verify environment/config propagation
# - Check state at each layer
# Run once to identify WHERE it breaks
# THEN analyze evidence to identify failing component
# THEN investigate that specific component
Example (multi-layer system):
# Layer 1: Workflow
echo "=== Secrets available in workflow: ==="
echo "IDENTITY: ${IDENTITY:+SET}${IDENTITY:-UNSET}"
# Layer 2: Build script
echo "=== Env vars in build script: ==="
env | grep IDENTITY || echo "IDENTITY not in environment"
# Layer 3: Signing script
echo "=== Keychain state: ==="
security list-keychains
security find-identity -v
# This reveals: Which layer fails
| Pitfall | Why It's Problematic | Better Approach |
|---|---|---|
| Fixing without understanding | You treat symptoms, not causes | Always identify root cause first |
| Multiple changes at once | Can't isolate what worked | One variable at a time |
| Assuming without verifying | Wastes time on wrong fixes | Verify hypotheses with data |
| Skipping tests | Fixes don't stick | Write tests before fixing |
| Ignoring error messages | Solutions often in the error | Read errors completely |
| Rushing under pressure | Guarantees rework | Systematic is faster than thrashing |
✅ You understand exactly WHAT is broken and WHY ✅ You can reproduce the issue consistently ✅ Your fix addresses root cause, not symptom ✅ Tests pass and issue is resolved ✅ No new bugs introduced ✅ You've prevented similar issues
This skill works alongside other Base plugin capabilities:
Systematic debugging is faster than random fixes.
From real debugging sessions:
Core principle: Understand before you fix.
Rationale: This skill provides systematic debugging structure while remaining pragmatic. Use when helpful, adapt to the situation, skip when the issue is straightforward.