[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6G8W6RG1S32K0ADEZ2MPEWM":3,"skill-same:01M6G8W6RG1S32K0ADEZ2MPEWM":80},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":58,"commitSha":59,"skillDirectory":60,"forksCount":61,"repositoryHtmlUrl":62,"repositoryHomepageUrl":6,"ownerHtmlUrl":63,"ownerBlogUrl":6,"ownerDescription":64,"updatedAt":65,"install":66,"resources":79},"01M6G8W6RG1S32K0ADEZ2MPEWM","systematic-debugging",null,"Use when encountering any bug, test failure, or unexpected behavior. 4-phase root cause investigation — NO fixes without understanding the problem first.","zapabob\u002FSkills","zapabob","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F130830376?v=4","01M6DBMYZAGRTFQDSQYW3W764P","峯岸 亮","01M6DBMZ3GKDSJ01NZ9XTZD7JD",2,"MIT","https:\u002F\u002Fgithub.com\u002Fzapabob\u002FSkills\u002Fblob\u002Fmain\u002Farchive\u002Fskill-md-reviewed\u002Fsha256\u002F6e\u002F6e407367f02896f83a6281f9f06832f82d0b3f44c3d6804c1aa01851dcf3fc7f\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"systematic debugging","debugging","systematic","behavior","test-driven-development","problem","plans","problem-solving","root-cause","bug","superpowers","use","writing","hermes agent","hermes","subagent","investigation","first","development","test","2026-11-10 10:12:30",false,"---\r\nname: systematic-debugging\r\ndescription: Use when encountering any bug, test failure, or unexpected behavior. 4-phase root cause investigation — NO fixes without understanding the problem first.\r\nversion: 1.1.0\r\nauthor: Hermes Agent (adapted from obra\u002Fsuperpowers)\r\nlicense: MIT\r\nmetadata:\r\n  hermes:\r\n    tags: [debugging, troubleshooting, problem-solving, root-cause, investigation]\r\n    related_skills: [test-driven-development, writing-plans, subagent-driven-development]\r\n---\r\n\r\n# Systematic Debugging\r\n\r\n## Overview\r\n\r\nRandom fixes waste time and create new bugs. Quick patches mask underlying issues.\r\n\r\n**Core principle:** ALWAYS find root cause before attempting fixes. Symptom fixes are failure.\r\n\r\n**Violating the letter of this process is violating the spirit of debugging.**\r\n\r\n## The Iron Law\r\n\r\n```\r\nNO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST\r\n```\r\n\r\nIf you haven't completed Phase 1, you cannot propose fixes.\r\n\r\n## When to Use\r\n\r\nUse for ANY technical issue:\r\n- Test failures\r\n- Bugs in production\r\n- Unexpected behavior\r\n- Performance problems\r\n- Build failures\r\n- Integration issues\r\n\r\n**Use this ESPECIALLY when:**\r\n- Under time pressure (emergencies make guessing tempting)\r\n- \"Just one quick fix\" seems obvious\r\n- You've already tried multiple fixes\r\n- Previous fix didn't work\r\n- You don't fully understand the issue\r\n\r\n**Don't skip when:**\r\n- Issue seems simple (simple bugs have root causes too)\r\n- You're in a hurry (rushing guarantees rework)\r\n- Someone wants it fixed NOW (systematic is faster than thrashing)\r\n\r\n## The Four Phases\r\n\r\nYou MUST complete each phase before proceeding to the next.\r\n\r\n---\r\n\r\n## Phase 1: Root Cause Investigation\r\n\r\n**BEFORE attempting ANY fix:**\r\n\r\n### 1. Read Error Messages Carefully\r\n\r\n- Don't skip past errors or warnings\r\n- They often contain the exact solution\r\n- Read stack traces completely\r\n- Note line numbers, file paths, error codes\r\n\r\n**Action:** Use `read_file` on the relevant source files. Use `search_files` to find the error string in the codebase.\r\n\r\n### 2. Reproduce Consistently\r\n\r\n- Can you trigger it reliably?\r\n- What are the exact steps?\r\n- Does it happen every time?\r\n- If not reproducible → gather more data, don't guess\r\n\r\n**Action:** Use the `terminal` tool to run the failing test or trigger the bug:\r\n\r\n```bash\r\n# Run specific failing test\r\npytest tests\u002Ftest_module.py::test_name -v\r\n\r\n# Run with verbose output\r\npytest tests\u002Ftest_module.py -v --tb=long\r\n```\r\n\r\n### 3. Check Recent Changes\r\n\r\n- What changed that could cause this?\r\n- Git diff, recent commits\r\n- New dependencies, config changes\r\n\r\n**Action:**\r\n\r\n```bash\r\n# Recent commits\r\ngit log --oneline -10\r\n\r\n# Uncommitted changes\r\ngit diff\r\n\r\n# Changes in specific file\r\ngit log -p --follow src\u002Fproblematic_file.py | head -100\r\n```\r\n\r\n### 4. Gather Evidence in Multi-Component Systems\r\n\r\n**WHEN system has multiple components (API → service → database, CI → build → deploy):**\r\n\r\n**BEFORE proposing fixes, add diagnostic instrumentation:**\r\n\r\nFor EACH component boundary:\r\n- Log what data enters the component\r\n- Log what data exits the component\r\n- Verify environment\u002Fconfig propagation\r\n- Check state at each layer\r\n\r\nRun once to gather evidence showing WHERE it breaks.\r\nTHEN analyze evidence to identify the failing component.\r\nTHEN investigate that specific component.\r\n\r\n### 5. Trace Data Flow\r\n\r\n**WHEN error is deep in the call stack:**\r\n\r\n- Where does the bad value originate?\r\n- What called this function with the bad value?\r\n- Keep tracing upstream until you find the source\r\n- Fix at the source, not at the symptom\r\n\r\n**Action:** Use `search_files` to trace references:\r\n\r\n```python\r\n# Find where the function is called\r\nsearch_files(\"function_name(\", path=\"src\u002F\", file_glob=\"*.py\")\r\n\r\n# Find where the variable is set\r\nsearch_files(\"variable_name\\\\s*=\", path=\"src\u002F\", file_glob=\"*.py\")\r\n```\r\n\r\n### Phase 1 Completion Checklist\r\n\r\n- [ ] Error messages fully read and understood\r\n- [ ] Issue reproduced consistently\r\n- [ ] Recent changes identified and reviewed\r\n- [ ] Evidence gathered (logs, state, data flow)\r\n- [ ] Problem isolated to specific component\u002Fcode\r\n- [ ] Root cause hypothesis formed\r\n\r\n**STOP:** Do not proceed to Phase 2 until you understand WHY it's happening.\r\n\r\n---\r\n\r\n## Phase 2: Pattern Analysis\r\n\r\n**Find the pattern before fixing:**\r\n\r\n### 1. Find Working Examples\r\n\r\n- Locate similar working code in the same codebase\r\n- What works that's similar to what's broken?\r\n\r\n**Action:** Use `search_files` to find comparable patterns:\r\n\r\n```python\r\nsearch_files(\"similar_pattern\", path=\"src\u002F\", file_glob=\"*.py\")\r\n```\r\n\r\n### 2. Compare Against References\r\n\r\n- If implementing a pattern, read the reference implementation COMPLETELY\r\n- Don't skim — read every line\r\n- Understand the pattern fully before applying\r\n\r\n### 3. Identify Differences\r\n\r\n- What's different between working and broken?\r\n- List every difference, however small\r\n- Don't assume \"that can't matter\"\r\n\r\n### 4. Understand Dependencies\r\n\r\n- What other components does this need?\r\n- What settings, config, environment?\r\n- What assumptions does it make?\r\n\r\n---\r\n\r\n## Phase 3: Hypothesis and Testing\r\n\r\n**Scientific method:**\r\n\r\n### 1. Form a Single Hypothesis\r\n\r\n- State clearly: \"I think X is the root cause because Y\"\r\n- Write it down\r\n- Be specific, not vague\r\n\r\n### 2. Test Minimally\r\n\r\n- Make the SMALLEST possible change to test the hypothesis\r\n- One variable at a time\r\n- Don't fix multiple things at once\r\n\r\n### 3. Verify Before Continuing\r\n\r\n- Did it work? → Phase 4\r\n- Didn't work? → Form NEW hypothesis\r\n- DON'T add more fixes on top\r\n\r\n### 4. When You Don't Know\r\n\r\n- Say \"I don't understand X\"\r\n- Don't pretend to know\r\n- Ask the user for help\r\n- Research more\r\n\r\n---\r\n\r\n## Phase 4: Implementation\r\n\r\n**Fix the root cause, not the symptom:**\r\n\r\n### 1. Create Failing Test Case\r\n\r\n- Simplest possible reproduction\r\n- Automated test if possible\r\n- MUST have before fixing\r\n- Use the `test-driven-development` skill\r\n\r\n### 2. Implement Single Fix\r\n\r\n- Address the root cause identified\r\n- ONE change at a time\r\n- No \"while I'm here\" improvements\r\n- No bundled refactoring\r\n\r\n### 3. Verify Fix\r\n\r\n```bash\r\n# Run the specific regression test\r\npytest tests\u002Ftest_module.py::test_regression -v\r\n\r\n# Run full suite — no regressions\r\npytest tests\u002F -q\r\n```\r\n\r\n### 4. If Fix Doesn't Work — The Rule of Three\r\n\r\n- **STOP.**\r\n- Count: How many fixes have you tried?\r\n- If \u003C 3: Return to Phase 1, re-analyze with new information\r\n- **If ≥ 3: STOP and question the architecture (step 5 below)**\r\n- DON'T attempt Fix #4 without architectural discussion\r\n\r\n### 5. If 3+ Fixes Failed: Question Architecture\r\n\r\n**Pattern indicating an architectural problem:**\r\n- Each fix reveals new shared state\u002Fcoupling in a different place\r\n- Fixes require \"massive refactoring\" to implement\r\n- Each fix creates new symptoms elsewhere\r\n\r\n**STOP and question fundamentals:**\r\n- Is this pattern fundamentally sound?\r\n- Are we \"sticking with it through sheer inertia\"?\r\n- Should we refactor the architecture vs. continue fixing symptoms?\r\n\r\n**Discuss with the user before attempting more fixes.**\r\n\r\nThis is NOT a failed hypothesis — this is a wrong architecture.\r\n\r\n---\r\n\r\n## Red Flags — STOP and Follow Process\r\n\r\nIf you catch yourself thinking:\r\n- \"Quick fix for now, investigate later\"\r\n- \"Just try changing X and see if it works\"\r\n- \"Add multiple changes, run tests\"\r\n- \"Skip the test, I'll manually verify\"\r\n- \"It's probably X, let me fix that\"\r\n- \"I don't fully understand but this might work\"\r\n- \"Pattern says X but I'll adapt it differently\"\r\n- \"Here are the main problems: [lists fixes without investigation]\"\r\n- Proposing solutions before tracing data flow\r\n- **\"One more fix attempt\" (when already tried 2+)**\r\n- **Each fix reveals a new problem in a different place**\r\n\r\n**ALL of these mean: STOP. Return to Phase 1.**\r\n\r\n**If 3+ fixes failed:** Question the architecture (Phase 4 step 5).\r\n\r\n## Common Rationalizations\r\n\r\n| Excuse | Reality |\r\n|--------|---------|\r\n| \"Issue is simple, don't need process\" | Simple issues have root causes too. Process is fast for simple bugs. |\r\n| \"Emergency, no time for process\" | Systematic debugging is FASTER than guess-and-check thrashing. |\r\n| \"Just try this first, then investigate\" | First fix sets the pattern. Do it right from the start. |\r\n| \"I'll write test after confirming fix works\" | Untested fixes don't stick. Test first proves it. |\r\n| \"Multiple fixes at once saves time\" | Can't isolate what worked. Causes new bugs. |\r\n| \"Reference too long, I'll adapt the pattern\" | Partial understanding guarantees bugs. Read it completely. |\r\n| \"I see the problem, let me fix it\" | Seeing symptoms ≠ understanding root cause. |\r\n| \"One more fix attempt\" (after 2+ failures) | 3+ failures = architectural problem. Question the pattern, don't fix again. |\r\n\r\n## Quick Reference\r\n\r\n| Phase | Key Activities | Success Criteria |\r\n|-------|---------------|------------------|\r\n| **1. Root Cause** | Read errors, reproduce, check changes, gather evidence, trace data flow | Understand WHAT and WHY |\r\n| **2. Pattern** | Find working examples, compare, identify differences | Know what's different |\r\n| **3. Hypothesis** | Form theory, test minimally, one variable at a time | Confirmed or new hypothesis |\r\n| **4. Implementation** | Create regression test, fix root cause, verify | Bug resolved, all tests pass |\r\n\r\n## Hermes Agent Integration\r\n\r\n### Investigation Tools\r\n\r\nUse these Hermes tools during Phase 1:\r\n\r\n- **`search_files`** — Find error strings, trace function calls, locate patterns\r\n- **`read_file`** — Read source code with line numbers for precise analysis\r\n- **`terminal`** — Run tests, check git history, reproduce bugs\r\n- **`web_search`\u002F`web_extract`** — Research error messages, library docs\r\n\r\n### With delegate_task\r\n\r\nFor complex multi-component debugging, dispatch investigation subagents:\r\n\r\n```python\r\ndelegate_task(\r\n    goal=\"Investigate why [specific test\u002Fbehavior] fails\",\r\n    context=\"\"\"\r\n    Follow systematic-debugging skill:\r\n    1. Read the error message carefully\r\n    2. Reproduce the issue\r\n    3. Trace the data flow to find root cause\r\n    4. Report findings — do NOT fix yet\r\n\r\n    Error: [paste full error]\r\n    File: [path to failing code]\r\n    Test command: [exact command]\r\n    \"\"\",\r\n    toolsets=['terminal', 'file']\r\n)\r\n```\r\n\r\n### With test-driven-development\r\n\r\nWhen fixing bugs:\r\n1. Write a test that reproduces the bug (RED)\r\n2. Debug systematically to find root cause\r\n3. Fix the root cause (GREEN)\r\n4. The test proves the fix and prevents regression\r\n\r\n## Real-World Impact\r\n\r\nFrom debugging sessions:\r\n- Systematic approach: 15-30 minutes to fix\r\n- Random fixes approach: 2-3 hours of thrashing\r\n- First-time fix rate: 95% vs 40%\r\n- New bugs introduced: Near zero vs common\r\n\r\n**No shortcuts. No guessing. Systematic always wins.**\r\n","# Systematic Debugging\r\n\r\n## Overview\r\n\r\nRandom fixes waste time and create new bugs. Quick patches mask underlying issues.\r\n\r\n**Core principle:** ALWAYS find root cause before attempting fixes. Symptom fixes are failure.\r\n\r\n**Violating the letter of this process is violating the spirit of debugging.**\r\n\r\n## The Iron Law\r\n\r\n```\r\nNO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST\r\n```\r\n\r\nIf you haven't completed Phase 1, you cannot propose fixes.\r\n\r\n## When to Use\r\n\r\nUse for ANY technical issue:\r\n- Test failures\r\n- Bugs in production\r\n- Unexpected behavior\r\n- Performance problems\r\n- Build failures\r\n- Integration issues\r\n\r\n**Use this ESPECIALLY when:**\r\n- Under time pressure (emergencies make guessing tempting)\r\n- \"Just one quick fix\" seems obvious\r\n- You've already tried multiple fixes\r\n- Previous fix didn't work\r\n- You don't fully understand the issue\r\n\r\n**Don't skip when:**\r\n- Issue seems simple (simple bugs have root causes too)\r\n- You're in a hurry (rushing guarantees rework)\r\n- Someone wants it fixed NOW (systematic is faster than thrashing)\r\n\r\n## The Four Phases\r\n\r\nYou MUST complete each phase before proceeding to the next.\r\n\r\n---\r\n\r\n## Phase 1: Root Cause Investigation\r\n\r\n**BEFORE attempting ANY fix:**\r\n\r\n### 1. Read Error Messages Carefully\r\n\r\n- Don't skip past errors or warnings\r\n- They often contain the exact solution\r\n- Read stack traces completely\r\n- Note line numbers, file paths, error codes\r\n\r\n**Action:** Use `read_file` on the relevant source files. Use `search_files` to find the error string in the codebase.\r\n\r\n### 2. Reproduce Consistently\r\n\r\n- Can you trigger it reliably?\r\n- What are the exact steps?\r\n- Does it happen every time?\r\n- If not reproducible → gather more data, don't guess\r\n\r\n**Action:** Use the `terminal` tool to run the failing test or trigger the bug:\r\n\r\n```bash\r\n# Run specific failing test\r\npytest tests\u002Ftest_module.py::test_name -v\r\n\r\n# Run with verbose output\r\npytest tests\u002Ftest_module.py -v --tb=long\r\n```\r\n\r\n### 3. Check Recent Changes\r\n\r\n- What changed that could cause this?\r\n- Git diff, recent commits\r\n- New dependencies, config changes\r\n\r\n**Action:**\r\n\r\n```bash\r\n# Recent commits\r\ngit log --oneline -10\r\n\r\n# Uncommitted changes\r\ngit diff\r\n\r\n# Changes in specific file\r\ngit log -p --follow src\u002Fproblematic_file.py | head -100\r\n```\r\n\r\n### 4. Gather Evidence in Multi-Component Systems\r\n\r\n**WHEN system has multiple components (API → service → database, CI → build → deploy):**\r\n\r\n**BEFORE proposing fixes, add diagnostic instrumentation:**\r\n\r\nFor EACH component boundary:\r\n- Log what data enters the component\r\n- Log what data exits the component\r\n- Verify environment\u002Fconfig propagation\r\n- Check state at each layer\r\n\r\nRun once to gather evidence showing WHERE it breaks.\r\nTHEN analyze evidence to identify the failing component.\r\nTHEN investigate that specific component.\r\n\r\n### 5. Trace Data Flow\r\n\r\n**WHEN error is deep in the call stack:**\r\n\r\n- Where does the bad value originate?\r\n- What called this function with the bad value?\r\n- Keep tracing upstream until you find the source\r\n- Fix at the source, not at the symptom\r\n\r\n**Action:** Use `search_files` to trace references:\r\n\r\n```python\r\n# Find where the function is called\r\nsearch_files(\"function_name(\", path=\"src\u002F\", file_glob=\"*.py\")\r\n\r\n# Find where the variable is set\r\nsearch_files(\"variable_name\\\\s*=\", path=\"src\u002F\", file_glob=\"*.py\")\r\n```\r\n\r\n### Phase 1 Completion Checklist\r\n\r\n- [ ] Error messages fully read and understood\r\n- [ ] Issue reproduced consistently\r\n- [ ] Recent changes identified and reviewed\r\n- [ ] Evidence gathered (logs, state, data flow)\r\n- [ ] Problem isolated to specific component\u002Fcode\r\n- [ ] Root cause hypothesis formed\r\n\r\n**STOP:** Do not proceed to Phase 2 until you understand WHY it's happening.\r\n\r\n---\r\n\r\n## Phase 2: Pattern Analysis\r\n\r\n**Find the pattern before fixing:**\r\n\r\n### 1. Find Working Examples\r\n\r\n- Locate similar working code in the same codebase\r\n- What works that's similar to what's broken?\r\n\r\n**Action:** Use `search_files` to find comparable patterns:\r\n\r\n```python\r\nsearch_files(\"similar_pattern\", path=\"src\u002F\", file_glob=\"*.py\")\r\n```\r\n\r\n### 2. Compare Against References\r\n\r\n- If implementing a pattern, read the reference implementation COMPLETELY\r\n- Don't skim — read every line\r\n- Understand the pattern fully before applying\r\n\r\n### 3. Identify Differences\r\n\r\n- What's different between working and broken?\r\n- List every difference, however small\r\n- Don't assume \"that can't matter\"\r\n\r\n### 4. Understand Dependencies\r\n\r\n- What other components does this need?\r\n- What settings, config, environment?\r\n- What assumptions does it make?\r\n\r\n---\r\n\r\n## Phase 3: Hypothesis and Testing\r\n\r\n**Scientific method:**\r\n\r\n### 1. Form a Single Hypothesis\r\n\r\n- State clearly: \"I think X is the root cause because Y\"\r\n- Write it down\r\n- Be specific, not vague\r\n\r\n### 2. Test Minimally\r\n\r\n- Make the SMALLEST possible change to test the hypothesis\r\n- One variable at a time\r\n- Don't fix multiple things at once\r\n\r\n### 3. Verify Before Continuing\r\n\r\n- Did it work? → Phase 4\r\n- Didn't work? → Form NEW hypothesis\r\n- DON'T add more fixes on top\r\n\r\n### 4. When You Don't Know\r\n\r\n- Say \"I don't understand X\"\r\n- Don't pretend to know\r\n- Ask the user for help\r\n- Research more\r\n\r\n---\r\n\r\n## Phase 4: Implementation\r\n\r\n**Fix the root cause, not the symptom:**\r\n\r\n### 1. Create Failing Test Case\r\n\r\n- Simplest possible reproduction\r\n- Automated test if possible\r\n- MUST have before fixing\r\n- Use the `test-driven-development` skill\r\n\r\n### 2. Implement Single Fix\r\n\r\n- Address the root cause identified\r\n- ONE change at a time\r\n- No \"while I'm here\" improvements\r\n- No bundled refactoring\r\n\r\n### 3. Verify Fix\r\n\r\n```bash\r\n# Run the specific regression test\r\npytest tests\u002Ftest_module.py::test_regression -v\r\n\r\n# Run full suite — no regressions\r\npytest tests\u002F -q\r\n```\r\n\r\n### 4. If Fix Doesn't Work — The Rule of Three\r\n\r\n- **STOP.**\r\n- Count: How many fixes have you tried?\r\n- If \u003C 3: Return to Phase 1, re-analyze with new information\r\n- **If ≥ 3: STOP and question the architecture (step 5 below)**\r\n- DON'T attempt Fix #4 without architectural discussion\r\n\r\n### 5. If 3+ Fixes Failed: Question Architecture\r\n\r\n**Pattern indicating an architectural problem:**\r\n- Each fix reveals new shared state\u002Fcoupling in a different place\r\n- Fixes require \"massive refactoring\" to implement\r\n- Each fix creates new symptoms elsewhere\r\n\r\n**STOP and question fundamentals:**\r\n- Is this pattern fundamentally sound?\r\n- Are we \"sticking with it through sheer inertia\"?\r\n- Should we refactor the architecture vs. continue fixing symptoms?\r\n\r\n**Discuss with the user before attempting more fixes.**\r\n\r\nThis is NOT a failed hypothesis — this is a wrong architecture.\r\n\r\n---\r\n\r\n## Red Flags — STOP and Follow Process\r\n\r\nIf you catch yourself thinking:\r\n- \"Quick fix for now, investigate later\"\r\n- \"Just try changing X and see if it works\"\r\n- \"Add multiple changes, run tests\"\r\n- \"Skip the test, I'll manually verify\"\r\n- \"It's probably X, let me fix that\"\r\n- \"I don't fully understand but this might work\"\r\n- \"Pattern says X but I'll adapt it differently\"\r\n- \"Here are the main problems: [lists fixes without investigation]\"\r\n- Proposing solutions before tracing data flow\r\n- **\"One more fix attempt\" (when already tried 2+)**\r\n- **Each fix reveals a new problem in a different place**\r\n\r\n**ALL of these mean: STOP. Return to Phase 1.**\r\n\r\n**If 3+ fixes failed:** Question the architecture (Phase 4 step 5).\r\n\r\n## Common Rationalizations\r\n\r\n| Excuse | Reality |\r\n|--------|---------|\r\n| \"Issue is simple, don't need process\" | Simple issues have root causes too. Process is fast for simple bugs. |\r\n| \"Emergency, no time for process\" | Systematic debugging is FASTER than guess-and-check thrashing. |\r\n| \"Just try this first, then investigate\" | First fix sets the pattern. Do it right from the start. |\r\n| \"I'll write test after confirming fix works\" | Untested fixes don't stick. Test first proves it. |\r\n| \"Multiple fixes at once saves time\" | Can't isolate what worked. Causes new bugs. |\r\n| \"Reference too long, I'll adapt the pattern\" | Partial understanding guarantees bugs. Read it completely. |\r\n| \"I see the problem, let me fix it\" | Seeing symptoms ≠ understanding root cause. |\r\n| \"One more fix attempt\" (after 2+ failures) | 3+ failures = architectural problem. Question the pattern, don't fix again. |\r\n\r\n## Quick Reference\r\n\r\n| Phase | Key Activities | Success Criteria |\r\n|-------|---------------|------------------|\r\n| **1. Root Cause** | Read errors, reproduce, check changes, gather evidence, trace data flow | Understand WHAT and WHY |\r\n| **2. Pattern** | Find working examples, compare, identify differences | Know what's different |\r\n| **3. Hypothesis** | Form theory, test minimally, one variable at a time | Confirmed or new hypothesis |\r\n| **4. Implementation** | Create regression test, fix root cause, verify | Bug resolved, all tests pass |\r\n\r\n## Hermes Agent Integration\r\n\r\n### Investigation Tools\r\n\r\nUse these Hermes tools during Phase 1:\r\n\r\n- **`search_files`** — Find error strings, trace function calls, locate patterns\r\n- **`read_file`** — Read source code with line numbers for precise analysis\r\n- **`terminal`** — Run tests, check git history, reproduce bugs\r\n- **`web_search`\u002F`web_extract`** — Research error messages, library docs\r\n\r\n### With delegate_task\r\n\r\nFor complex multi-component debugging, dispatch investigation subagents:\r\n\r\n```python\r\ndelegate_task(\r\n    goal=\"Investigate why [specific test\u002Fbehavior] fails\",\r\n    context=\"\"\"\r\n    Follow systematic-debugging skill:\r\n    1. Read the error message carefully\r\n    2. Reproduce the issue\r\n    3. Trace the data flow to find root cause\r\n    4. Report findings — do NOT fix yet\r\n\r\n    Error: [paste full error]\r\n    File: [path to failing code]\r\n    Test command: [exact command]\r\n    \"\"\",\r\n    toolsets=['terminal', 'file']\r\n)\r\n```\r\n\r\n### With test-driven-development\r\n\r\nWhen fixing bugs:\r\n1. Write a test that reproduces the bug (RED)\r\n2. Debug systematically to find root cause\r\n3. Fix the root cause (GREEN)\r\n4. The test proves the fix and prevents regression\r\n\r\n## Real-World Impact\r\n\r\nFrom debugging sessions:\r\n- Systematic approach: 15-30 minutes to fix\r\n- Random fixes approach: 2-3 hours of thrashing\r\n- First-time fix rate: 95% vs 40%\r\n- New bugs introduced: Near zero vs common\r\n\r\n**No shortcuts. No guessing. Systematic always wins.**\r\n",{"name":5,"author":49,"license":15,"version":50,"metadata":51,"description":7},"Hermes Agent (adapted from obra\u002Fsuperpowers)","1.1.0",{"hermes":52},{"tags":53,"related_skills":55},[25,54,31,32,40],"troubleshooting",[28,56,57],"writing-plans","subagent-driven-development","main","0d1434f89f4bc6b07e9d272accd8c1013768820f","archive\u002Fskill-md-reviewed\u002Fsha256\u002F6e\u002F6e407367f02896f83a6281f9f06832f82d0b3f44c3d6804c1aa01851dcf3fc7f",0,"https:\u002F\u002Fgithub.com\u002Fzapabob\u002FSkills","https:\u002F\u002Fgithub.com\u002Fzapabob","The Open University of JAPAN　2019-now\r\n\r\nTokyo University of Science　2007-2010","2026-10-26 16:29:01",{"source":8,"skillName":5,"commands":67,"prompt":77,"zipAvailable":78},[68,71,74],{"tool":69,"command":70},"npx","npx skills add zapabob\u002FSkills --skill systematic-debugging",{"tool":72,"command":73},"bunx","bunx skills add zapabob\u002FSkills --skill systematic-debugging",{"tool":75,"command":76},"pnpm","pnpm dlx skills add zapabob\u002FSkills --skill systematic-debugging","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fzapabob\u002FSkills\u002Fblob\u002Fmain\u002Farchive\u002Fskill-md-reviewed\u002Fsha256\u002F6e\u002F6e407367f02896f83a6281f9f06832f82d0b3f44c3d6804c1aa01851dcf3fc7f\u002FSKILL.md",true,[],[81,115,143,169,196,213],{"skillNo":82,"name":83,"nameZh":6,"description":84,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":85,"categories":86,"keywords":98,"publishedAt":44},"01M6GJTE1GESGGF9K028Y7753E","xurl","X\u002FTwitter via xurl CLI: post, search, DM, media, v2 API.","https:\u002F\u002Fgithub.com\u002Fzapabob\u002FSkills\u002Fblob\u002Fmain\u002Fregistry\u002Fskills\u002Fxurl\u002Fvariants\u002Fhermes-agent\u002FSKILL.md",[87,90,93],{"categoryNo":88,"categoryName":89,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":91,"categoryName":92,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":94,"categoryName":95,"taxonomyType":96,"taxonomyTypeDesc":97},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[83,99,100,101,102,103,104,105,106,107,108,109,110,38,37,111,58,112,113,114],"openclaw","macos","cli","github","linux","windows","official","search","https","social-media","api","Media","twitter","social","via","post",{"skillNo":116,"name":56,"nameZh":6,"description":117,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":118,"categories":119,"keywords":131,"publishedAt":44},"01M6GJT8S1PXQ8WPXT1HSNBWH2","Write implementation plans: bite-sized tasks, paths, code.","https:\u002F\u002Fgithub.com\u002Fzapabob\u002FSkills\u002Fblob\u002Fmain\u002Fregistry\u002Fskills\u002Fwriting-plans\u002Fvariants\u002Fhermes-agent\u002FSKILL.md",[120,123,126,127,128],{"categoryNo":121,"categoryName":122,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":124,"categoryName":125,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":91,"categoryName":92,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":94,"categoryName":95,"taxonomyType":96,"taxonomyTypeDesc":97},{"categoryNo":129,"categoryName":130,"taxonomyType":96,"taxonomyTypeDesc":97},"01JBSEEDCAT000000000000036","内容创作者",[36,132,30,133,100,134,103,135,104,136,137,42,138,139,140,39,141,34,142,28],"writing plans","design","review","workflow","documentation","tasks","code","planning","code-review","write","paths",{"skillNo":144,"name":145,"nameZh":6,"description":146,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":147,"categories":148,"keywords":152,"publishedAt":44},"01M6GJST0H5X7WHBJ3BZK0DVKH","whisper","OpenAI's general-purpose speech recognition model. Supports 99 languages, transcription, translation to English, and language identification. Six model sizes from tiny (39M params) to large (1550M params). Use for speech-to-text, podcast transcription, or multilingual audio processing. Best for robust, multilingual ASR.","https:\u002F\u002Fgithub.com\u002Fzapabob\u002FSkills\u002Fblob\u002Fmain\u002Fregistry\u002Fskills\u002Fwhisper\u002Fvariants\u002Fhermes-agent-optional\u002FSKILL.md",[149],{"categoryNo":150,"categoryName":151,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000016","图像与多媒体",[145,100,103,153,154,155,156,157,158,159,160,161,35,162,163,164,165,166,167,168],"openai","speech","multimodal","Transformers","ASR","Audio","text","model","speech recognition","general","multilingual","translation","english","identification","processing","Audio Processing",{"skillNo":170,"name":171,"nameZh":6,"description":172,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":173,"categories":174,"keywords":178,"publishedAt":44},"01M6GJSMRQ8EETZTYMG72P70EA","weights-and-biases","W&B: log ML experiments, sweeps, model registry, dashboards.","https:\u002F\u002Fgithub.com\u002Fzapabob\u002FSkills\u002Fblob\u002Fmain\u002Fregistry\u002Fskills\u002Fweights-and-biases\u002Fvariants\u002Fhermes-agent\u002FSKILL.md",[175],{"categoryNo":176,"categoryName":177,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000013","分析与可视化",[179,100,180,181,104,182,183,184,185,186,187,160,188,189,190,191,192,193,194,195],"weights and biases","tensorflow","experiments","pytorch","visualization","registry","real-time","tuning","dashboards","experiment","log","time","Experiment Tracking","Model Registry","Hyperparameter Tuning","WandB","Real-Time Visualization",{"skillNo":197,"name":198,"nameZh":6,"description":199,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":200,"categories":201,"keywords":203,"publishedAt":44},"01M6GJS19KDPRY112JTR326S06","watchers","Poll RSS, JSON APIs, and GitHub with watermark dedup.","https:\u002F\u002Fgithub.com\u002Fzapabob\u002FSkills\u002Fblob\u002Fmain\u002Fregistry\u002Fskills\u002Fwatchers\u002Fvariants\u002Fhermes-agent-optional\u002FSKILL.md",[202],{"categoryNo":91,"categoryName":92,"taxonomyType":21,"taxonomyTypeDesc":22},[198,100,204,102,103,205,206,207,208,209,210,38,37,211,212],"terminal","automation","http","monitoring","cron","json","rss","devops","with",{"skillNo":214,"name":215,"nameZh":6,"description":216,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":217,"categories":218,"keywords":221,"publishedAt":44},"01M6GJRHJD2A6Q830SWF9W48BC","serving-llms-vllm","vLLM: high-throughput LLM serving, OpenAI API, quantization.","https:\u002F\u002Fgithub.com\u002Fzapabob\u002FSkills\u002Fblob\u002Fmain\u002Fregistry\u002Fskills\u002Fvllm\u002Fvariants\u002Fhermes-agent\u002FSKILL.md",[219,220],{"categoryNo":88,"categoryName":89,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":94,"categoryName":95,"taxonomyType":96,"taxonomyTypeDesc":97},[222,223,224,103,225,153,226,227,228,156,229,109,230,231,232,233,234,235,236,237],"llms","vLLM","serving llms vllm","research","openai api","tensor","Inference Serving","Production","llm serving","High Throughput","PagedAttention","Continuous Batching","Quantization","Tensor Parallelism","high-throughput","throughput"]