[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71JFCA5S48PZ5M7DG31R8K5":3,"skill-same:01M71JFCA5S48PZ5M7DG31R8K5":79},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":22,"publishedAt":43,"linkOnly":44,"markdownContent":45,"markdownBody":46,"frontMatter":47,"refName":58,"commitSha":59,"skillDirectory":60,"forksCount":61,"repositoryHtmlUrl":62,"repositoryHomepageUrl":6,"ownerHtmlUrl":63,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":64,"install":65,"resources":78},"01M71JFCA5S48PZ5M7DG31R8K5","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.","xuanxuan1983\u002Fhermes-skills-backup","xuanxuan1983","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F151701653?v=4","01M71HCZNB5H19QJ6YBF98W2WH","01M71HCZP14T0921BD0TC9EPD3",1,"MIT","https:\u002F\u002Fgithub.com\u002Fxuanxuan1983\u002Fhermes-skills-backup\u002Fblob\u002Fmain\u002Fskills\u002Fsoftware-development\u002Fsystematic-debugging\u002FSKILL.md",[17],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",[23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42],"debugging","systematic","systematic debugging","test","root-cause","use","plans","root cause","fixes","development","bug","phase","subagent","when","writing","superpowers","test-driven-development","problem-solving","problem","test-driven","2026-11-10 10:12:30",false,"---\nname: systematic-debugging\ndescription: Use when encountering any bug, test failure, or unexpected behavior. 4-phase root cause investigation — NO fixes without understanding the problem first.\nversion: 1.1.0\nauthor: Hermes Agent (adapted from obra\u002Fsuperpowers)\nlicense: MIT\nmetadata:\n  hermes:\n    tags: [debugging, troubleshooting, problem-solving, root-cause, investigation]\n    related_skills: [test-driven-development, writing-plans, subagent-driven-development]\n---\n\n# Systematic Debugging\n\n## Overview\n\nRandom fixes waste time and create new bugs. Quick patches mask underlying issues.\n\n**Core principle:** ALWAYS find root cause before attempting fixes. Symptom fixes are failure.\n\n**Violating the letter of this process is violating the spirit of debugging.**\n\n## The Iron Law\n\n```\nNO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST\n```\n\nIf you haven't completed Phase 1, you cannot propose fixes.\n\n## When to Use\n\nUse for ANY technical issue:\n- Test failures\n- Bugs in production\n- Unexpected behavior\n- Performance problems\n- Build failures\n- Integration issues\n\n**Use this ESPECIALLY when:**\n- Under time pressure (emergencies make guessing tempting)\n- \"Just one quick fix\" seems obvious\n- You've already tried multiple fixes\n- Previous fix didn't work\n- You don't fully understand the issue\n\n**Don't skip when:**\n- Issue seems simple (simple bugs have root causes too)\n- You're in a hurry (rushing guarantees rework)\n- Someone wants it fixed NOW (systematic is faster than thrashing)\n\n## The Four Phases\n\nYou MUST complete each phase before proceeding to the next.\n\n---\n\n## Phase 1: Root Cause Investigation\n\n**BEFORE attempting ANY fix:**\n\n### 1. Read Error Messages Carefully\n\n- Don't skip past errors or warnings\n- They often contain the exact solution\n- Read stack traces completely\n- Note line numbers, file paths, error codes\n\n**Action:** Use `read_file` on the relevant source files. Use `search_files` to find the error string in the codebase.\n\n### 2. Reproduce Consistently\n\n- Can you trigger it reliably?\n- What are the exact steps?\n- Does it happen every time?\n- If not reproducible → gather more data, don't guess\n\n**Action:** Use the `terminal` tool to run the failing test or trigger the bug:\n\n```bash\n# Run specific failing test\npytest tests\u002Ftest_module.py::test_name -v\n\n# Run with verbose output\npytest tests\u002Ftest_module.py -v --tb=long\n```\n\n### 3. Check Recent Changes\n\n- What changed that could cause this?\n- Git diff, recent commits\n- New dependencies, config changes\n\n**Action:**\n\n```bash\n# Recent commits\ngit log --oneline -10\n\n# Uncommitted changes\ngit diff\n\n# Changes in specific file\ngit log -p --follow src\u002Fproblematic_file.py | head -100\n```\n\n### 4. Gather Evidence in Multi-Component Systems\n\n**WHEN system has multiple components (API → service → database, CI → build → deploy):**\n\n**BEFORE proposing fixes, add diagnostic instrumentation:**\n\nFor EACH component boundary:\n- Log what data enters the component\n- Log what data exits the component\n- Verify environment\u002Fconfig propagation\n- Check state at each layer\n\nRun once to gather evidence showing WHERE it breaks.\nTHEN analyze evidence to identify the failing component.\nTHEN investigate that specific component.\n\n### 5. Trace Data Flow\n\n**WHEN error is deep in the call stack:**\n\n- Where does the bad value originate?\n- What called this function with the bad value?\n- Keep tracing upstream until you find the source\n- Fix at the source, not at the symptom\n\n**Action:** Use `search_files` to trace references:\n\n```python\n# Find where the function is called\nsearch_files(\"function_name(\", path=\"src\u002F\", file_glob=\"*.py\")\n\n# Find where the variable is set\nsearch_files(\"variable_name\\\\s*=\", path=\"src\u002F\", file_glob=\"*.py\")\n```\n\n### Phase 1 Completion Checklist\n\n- [ ] Error messages fully read and understood\n- [ ] Issue reproduced consistently\n- [ ] Recent changes identified and reviewed\n- [ ] Evidence gathered (logs, state, data flow)\n- [ ] Problem isolated to specific component\u002Fcode\n- [ ] Root cause hypothesis formed\n\n**STOP:** Do not proceed to Phase 2 until you understand WHY it's happening.\n\n---\n\n## Phase 2: Pattern Analysis\n\n**Find the pattern before fixing:**\n\n### 1. Find Working Examples\n\n- Locate similar working code in the same codebase\n- What works that's similar to what's broken?\n\n**Action:** Use `search_files` to find comparable patterns:\n\n```python\nsearch_files(\"similar_pattern\", path=\"src\u002F\", file_glob=\"*.py\")\n```\n\n### 2. Compare Against References\n\n- If implementing a pattern, read the reference implementation COMPLETELY\n- Don't skim — read every line\n- Understand the pattern fully before applying\n\n### 3. Identify Differences\n\n- What's different between working and broken?\n- List every difference, however small\n- Don't assume \"that can't matter\"\n\n### 4. Understand Dependencies\n\n- What other components does this need?\n- What settings, config, environment?\n- What assumptions does it make?\n\n---\n\n## Phase 3: Hypothesis and Testing\n\n**Scientific method:**\n\n### 1. Form a Single Hypothesis\n\n- State clearly: \"I think X is the root cause because Y\"\n- Write it down\n- Be specific, not vague\n\n### 2. Test Minimally\n\n- Make the SMALLEST possible change to test the hypothesis\n- One variable at a time\n- Don't fix multiple things at once\n\n### 3. Verify Before Continuing\n\n- Did it work? → Phase 4\n- Didn't work? → Form NEW hypothesis\n- DON'T add more fixes on top\n\n### 4. When You Don't Know\n\n- Say \"I don't understand X\"\n- Don't pretend to know\n- Ask the user for help\n- Research more\n\n---\n\n## Phase 4: Implementation\n\n**Fix the root cause, not the symptom:**\n\n### 1. Create Failing Test Case\n\n- Simplest possible reproduction\n- Automated test if possible\n- MUST have before fixing\n- Use the `test-driven-development` skill\n\n### 2. Implement Single Fix\n\n- Address the root cause identified\n- ONE change at a time\n- No \"while I'm here\" improvements\n- No bundled refactoring\n\n### 3. Verify Fix\n\n```bash\n# Run the specific regression test\npytest tests\u002Ftest_module.py::test_regression -v\n\n# Run full suite — no regressions\npytest tests\u002F -q\n```\n\n### 4. If Fix Doesn't Work — The Rule of Three\n\n- **STOP.**\n- Count: How many fixes have you tried?\n- If \u003C 3: Return to Phase 1, re-analyze with new information\n- **If ≥ 3: STOP and question the architecture (step 5 below)**\n- DON'T attempt Fix #4 without architectural discussion\n\n### 5. If 3+ Fixes Failed: Question Architecture\n\n**Pattern indicating an architectural problem:**\n- Each fix reveals new shared state\u002Fcoupling in a different place\n- Fixes require \"massive refactoring\" to implement\n- Each fix creates new symptoms elsewhere\n\n**STOP and question fundamentals:**\n- Is this pattern fundamentally sound?\n- Are we \"sticking with it through sheer inertia\"?\n- Should we refactor the architecture vs. continue fixing symptoms?\n\n**Discuss with the user before attempting more fixes.**\n\nThis is NOT a failed hypothesis — this is a wrong architecture.\n\n---\n\n## Red Flags — STOP and Follow Process\n\nIf you catch yourself thinking:\n- \"Quick fix for now, investigate later\"\n- \"Just try changing X and see if it works\"\n- \"Add multiple changes, run tests\"\n- \"Skip the test, I'll manually verify\"\n- \"It's probably X, let me fix that\"\n- \"I don't fully understand but this might work\"\n- \"Pattern says X but I'll adapt it differently\"\n- \"Here are the main problems: [lists fixes without investigation]\"\n- Proposing solutions before tracing data flow\n- **\"One more fix attempt\" (when already tried 2+)**\n- **Each fix reveals a new problem in a different place**\n\n**ALL of these mean: STOP. Return to Phase 1.**\n\n**If 3+ fixes failed:** Question the architecture (Phase 4 step 5).\n\n## Common Rationalizations\n\n| Excuse | Reality |\n|--------|---------|\n| \"Issue is simple, don't need process\" | Simple issues have root causes too. Process is fast for simple bugs. |\n| \"Emergency, no time for process\" | Systematic debugging is FASTER than guess-and-check thrashing. |\n| \"Just try this first, then investigate\" | First fix sets the pattern. Do it right from the start. |\n| \"I'll write test after confirming fix works\" | Untested fixes don't stick. Test first proves it. |\n| \"Multiple fixes at once saves time\" | Can't isolate what worked. Causes new bugs. |\n| \"Reference too long, I'll adapt the pattern\" | Partial understanding guarantees bugs. Read it completely. |\n| \"I see the problem, let me fix it\" | Seeing symptoms ≠ understanding root cause. |\n| \"One more fix attempt\" (after 2+ failures) | 3+ failures = architectural problem. Question the pattern, don't fix again. |\n\n## Quick Reference\n\n| Phase | Key Activities | Success Criteria |\n|-------|---------------|------------------|\n| **1. Root Cause** | Read errors, reproduce, check changes, gather evidence, trace data flow | Understand WHAT and WHY |\n| **2. Pattern** | Find working examples, compare, identify differences | Know what's different |\n| **3. Hypothesis** | Form theory, test minimally, one variable at a time | Confirmed or new hypothesis |\n| **4. Implementation** | Create regression test, fix root cause, verify | Bug resolved, all tests pass |\n\n## Hermes Agent Integration\n\n### Investigation Tools\n\nUse these Hermes tools during Phase 1:\n\n- **`search_files`** — Find error strings, trace function calls, locate patterns\n- **`read_file`** — Read source code with line numbers for precise analysis\n- **`terminal`** — Run tests, check git history, reproduce bugs\n- **`web_search`\u002F`web_extract`** — Research error messages, library docs\n\n### With delegate_task\n\nFor complex multi-component debugging, dispatch investigation subagents:\n\n```python\ndelegate_task(\n    goal=\"Investigate why [specific test\u002Fbehavior] fails\",\n    context=\"\"\"\n    Follow systematic-debugging skill:\n    1. Read the error message carefully\n    2. Reproduce the issue\n    3. Trace the data flow to find root cause\n    4. Report findings — do NOT fix yet\n\n    Error: [paste full error]\n    File: [path to failing code]\n    Test command: [exact command]\n    \"\"\",\n    toolsets=['terminal', 'file']\n)\n```\n\n### With test-driven-development\n\nWhen fixing bugs:\n1. Write a test that reproduces the bug (RED)\n2. Debug systematically to find root cause\n3. Fix the root cause (GREEN)\n4. The test proves the fix and prevents regression\n\n## Real-World Impact\n\nFrom debugging sessions:\n- Systematic approach: 15-30 minutes to fix\n- Random fixes approach: 2-3 hours of thrashing\n- First-time fix rate: 95% vs 40%\n- New bugs introduced: Near zero vs common\n\n**No shortcuts. No guessing. Systematic always wins.**\n","# Systematic Debugging\n\n## Overview\n\nRandom fixes waste time and create new bugs. Quick patches mask underlying issues.\n\n**Core principle:** ALWAYS find root cause before attempting fixes. Symptom fixes are failure.\n\n**Violating the letter of this process is violating the spirit of debugging.**\n\n## The Iron Law\n\n```\nNO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST\n```\n\nIf you haven't completed Phase 1, you cannot propose fixes.\n\n## When to Use\n\nUse for ANY technical issue:\n- Test failures\n- Bugs in production\n- Unexpected behavior\n- Performance problems\n- Build failures\n- Integration issues\n\n**Use this ESPECIALLY when:**\n- Under time pressure (emergencies make guessing tempting)\n- \"Just one quick fix\" seems obvious\n- You've already tried multiple fixes\n- Previous fix didn't work\n- You don't fully understand the issue\n\n**Don't skip when:**\n- Issue seems simple (simple bugs have root causes too)\n- You're in a hurry (rushing guarantees rework)\n- Someone wants it fixed NOW (systematic is faster than thrashing)\n\n## The Four Phases\n\nYou MUST complete each phase before proceeding to the next.\n\n---\n\n## Phase 1: Root Cause Investigation\n\n**BEFORE attempting ANY fix:**\n\n### 1. Read Error Messages Carefully\n\n- Don't skip past errors or warnings\n- They often contain the exact solution\n- Read stack traces completely\n- Note line numbers, file paths, error codes\n\n**Action:** Use `read_file` on the relevant source files. Use `search_files` to find the error string in the codebase.\n\n### 2. Reproduce Consistently\n\n- Can you trigger it reliably?\n- What are the exact steps?\n- Does it happen every time?\n- If not reproducible → gather more data, don't guess\n\n**Action:** Use the `terminal` tool to run the failing test or trigger the bug:\n\n```bash\n# Run specific failing test\npytest tests\u002Ftest_module.py::test_name -v\n\n# Run with verbose output\npytest tests\u002Ftest_module.py -v --tb=long\n```\n\n### 3. Check Recent Changes\n\n- What changed that could cause this?\n- Git diff, recent commits\n- New dependencies, config changes\n\n**Action:**\n\n```bash\n# Recent commits\ngit log --oneline -10\n\n# Uncommitted changes\ngit diff\n\n# Changes in specific file\ngit log -p --follow src\u002Fproblematic_file.py | head -100\n```\n\n### 4. Gather Evidence in Multi-Component Systems\n\n**WHEN system has multiple components (API → service → database, CI → build → deploy):**\n\n**BEFORE proposing fixes, add diagnostic instrumentation:**\n\nFor EACH component boundary:\n- Log what data enters the component\n- Log what data exits the component\n- Verify environment\u002Fconfig propagation\n- Check state at each layer\n\nRun once to gather evidence showing WHERE it breaks.\nTHEN analyze evidence to identify the failing component.\nTHEN investigate that specific component.\n\n### 5. Trace Data Flow\n\n**WHEN error is deep in the call stack:**\n\n- Where does the bad value originate?\n- What called this function with the bad value?\n- Keep tracing upstream until you find the source\n- Fix at the source, not at the symptom\n\n**Action:** Use `search_files` to trace references:\n\n```python\n# Find where the function is called\nsearch_files(\"function_name(\", path=\"src\u002F\", file_glob=\"*.py\")\n\n# Find where the variable is set\nsearch_files(\"variable_name\\\\s*=\", path=\"src\u002F\", file_glob=\"*.py\")\n```\n\n### Phase 1 Completion Checklist\n\n- [ ] Error messages fully read and understood\n- [ ] Issue reproduced consistently\n- [ ] Recent changes identified and reviewed\n- [ ] Evidence gathered (logs, state, data flow)\n- [ ] Problem isolated to specific component\u002Fcode\n- [ ] Root cause hypothesis formed\n\n**STOP:** Do not proceed to Phase 2 until you understand WHY it's happening.\n\n---\n\n## Phase 2: Pattern Analysis\n\n**Find the pattern before fixing:**\n\n### 1. Find Working Examples\n\n- Locate similar working code in the same codebase\n- What works that's similar to what's broken?\n\n**Action:** Use `search_files` to find comparable patterns:\n\n```python\nsearch_files(\"similar_pattern\", path=\"src\u002F\", file_glob=\"*.py\")\n```\n\n### 2. Compare Against References\n\n- If implementing a pattern, read the reference implementation COMPLETELY\n- Don't skim — read every line\n- Understand the pattern fully before applying\n\n### 3. Identify Differences\n\n- What's different between working and broken?\n- List every difference, however small\n- Don't assume \"that can't matter\"\n\n### 4. Understand Dependencies\n\n- What other components does this need?\n- What settings, config, environment?\n- What assumptions does it make?\n\n---\n\n## Phase 3: Hypothesis and Testing\n\n**Scientific method:**\n\n### 1. Form a Single Hypothesis\n\n- State clearly: \"I think X is the root cause because Y\"\n- Write it down\n- Be specific, not vague\n\n### 2. Test Minimally\n\n- Make the SMALLEST possible change to test the hypothesis\n- One variable at a time\n- Don't fix multiple things at once\n\n### 3. Verify Before Continuing\n\n- Did it work? → Phase 4\n- Didn't work? → Form NEW hypothesis\n- DON'T add more fixes on top\n\n### 4. When You Don't Know\n\n- Say \"I don't understand X\"\n- Don't pretend to know\n- Ask the user for help\n- Research more\n\n---\n\n## Phase 4: Implementation\n\n**Fix the root cause, not the symptom:**\n\n### 1. Create Failing Test Case\n\n- Simplest possible reproduction\n- Automated test if possible\n- MUST have before fixing\n- Use the `test-driven-development` skill\n\n### 2. Implement Single Fix\n\n- Address the root cause identified\n- ONE change at a time\n- No \"while I'm here\" improvements\n- No bundled refactoring\n\n### 3. Verify Fix\n\n```bash\n# Run the specific regression test\npytest tests\u002Ftest_module.py::test_regression -v\n\n# Run full suite — no regressions\npytest tests\u002F -q\n```\n\n### 4. If Fix Doesn't Work — The Rule of Three\n\n- **STOP.**\n- Count: How many fixes have you tried?\n- If \u003C 3: Return to Phase 1, re-analyze with new information\n- **If ≥ 3: STOP and question the architecture (step 5 below)**\n- DON'T attempt Fix #4 without architectural discussion\n\n### 5. If 3+ Fixes Failed: Question Architecture\n\n**Pattern indicating an architectural problem:**\n- Each fix reveals new shared state\u002Fcoupling in a different place\n- Fixes require \"massive refactoring\" to implement\n- Each fix creates new symptoms elsewhere\n\n**STOP and question fundamentals:**\n- Is this pattern fundamentally sound?\n- Are we \"sticking with it through sheer inertia\"?\n- Should we refactor the architecture vs. continue fixing symptoms?\n\n**Discuss with the user before attempting more fixes.**\n\nThis is NOT a failed hypothesis — this is a wrong architecture.\n\n---\n\n## Red Flags — STOP and Follow Process\n\nIf you catch yourself thinking:\n- \"Quick fix for now, investigate later\"\n- \"Just try changing X and see if it works\"\n- \"Add multiple changes, run tests\"\n- \"Skip the test, I'll manually verify\"\n- \"It's probably X, let me fix that\"\n- \"I don't fully understand but this might work\"\n- \"Pattern says X but I'll adapt it differently\"\n- \"Here are the main problems: [lists fixes without investigation]\"\n- Proposing solutions before tracing data flow\n- **\"One more fix attempt\" (when already tried 2+)**\n- **Each fix reveals a new problem in a different place**\n\n**ALL of these mean: STOP. Return to Phase 1.**\n\n**If 3+ fixes failed:** Question the architecture (Phase 4 step 5).\n\n## Common Rationalizations\n\n| Excuse | Reality |\n|--------|---------|\n| \"Issue is simple, don't need process\" | Simple issues have root causes too. Process is fast for simple bugs. |\n| \"Emergency, no time for process\" | Systematic debugging is FASTER than guess-and-check thrashing. |\n| \"Just try this first, then investigate\" | First fix sets the pattern. Do it right from the start. |\n| \"I'll write test after confirming fix works\" | Untested fixes don't stick. Test first proves it. |\n| \"Multiple fixes at once saves time\" | Can't isolate what worked. Causes new bugs. |\n| \"Reference too long, I'll adapt the pattern\" | Partial understanding guarantees bugs. Read it completely. |\n| \"I see the problem, let me fix it\" | Seeing symptoms ≠ understanding root cause. |\n| \"One more fix attempt\" (after 2+ failures) | 3+ failures = architectural problem. Question the pattern, don't fix again. |\n\n## Quick Reference\n\n| Phase | Key Activities | Success Criteria |\n|-------|---------------|------------------|\n| **1. Root Cause** | Read errors, reproduce, check changes, gather evidence, trace data flow | Understand WHAT and WHY |\n| **2. Pattern** | Find working examples, compare, identify differences | Know what's different |\n| **3. Hypothesis** | Form theory, test minimally, one variable at a time | Confirmed or new hypothesis |\n| **4. Implementation** | Create regression test, fix root cause, verify | Bug resolved, all tests pass |\n\n## Hermes Agent Integration\n\n### Investigation Tools\n\nUse these Hermes tools during Phase 1:\n\n- **`search_files`** — Find error strings, trace function calls, locate patterns\n- **`read_file`** — Read source code with line numbers for precise analysis\n- **`terminal`** — Run tests, check git history, reproduce bugs\n- **`web_search`\u002F`web_extract`** — Research error messages, library docs\n\n### With delegate_task\n\nFor complex multi-component debugging, dispatch investigation subagents:\n\n```python\ndelegate_task(\n    goal=\"Investigate why [specific test\u002Fbehavior] fails\",\n    context=\"\"\"\n    Follow systematic-debugging skill:\n    1. Read the error message carefully\n    2. Reproduce the issue\n    3. Trace the data flow to find root cause\n    4. Report findings — do NOT fix yet\n\n    Error: [paste full error]\n    File: [path to failing code]\n    Test command: [exact command]\n    \"\"\",\n    toolsets=['terminal', 'file']\n)\n```\n\n### With test-driven-development\n\nWhen fixing bugs:\n1. Write a test that reproduces the bug (RED)\n2. Debug systematically to find root cause\n3. Fix the root cause (GREEN)\n4. The test proves the fix and prevents regression\n\n## Real-World Impact\n\nFrom debugging sessions:\n- Systematic approach: 15-30 minutes to fix\n- Random fixes approach: 2-3 hours of thrashing\n- First-time fix rate: 95% vs 40%\n- New bugs introduced: Near zero vs common\n\n**No shortcuts. No guessing. Systematic always wins.**\n",{"name":5,"author":48,"license":14,"version":49,"metadata":50,"description":7},"Hermes Agent (adapted from obra\u002Fsuperpowers)","1.1.0",{"hermes":51},{"tags":52,"related_skills":55},[23,53,40,27,54],"troubleshooting","investigation",[39,56,57],"writing-plans","subagent-driven-development","main","17ee50c38aefa9426a89d7e8ee167fdc4c184fb7","skills\u002Fsoftware-development\u002Fsystematic-debugging",0,"https:\u002F\u002Fgithub.com\u002Fxuanxuan1983\u002Fhermes-skills-backup","https:\u002F\u002Fgithub.com\u002Fxuanxuan1983","2026-05-24 00:14:48",{"source":8,"skillName":5,"commands":66,"prompt":76,"zipAvailable":77},[67,70,73],{"tool":68,"command":69},"npx","npx skills add xuanxuan1983\u002Fhermes-skills-backup --skill systematic-debugging",{"tool":71,"command":72},"bunx","bunx skills add xuanxuan1983\u002Fhermes-skills-backup --skill systematic-debugging",{"tool":74,"command":75},"pnpm","pnpm dlx skills add xuanxuan1983\u002Fhermes-skills-backup --skill systematic-debugging","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fxuanxuan1983\u002Fhermes-skills-backup\u002Fblob\u002Fmain\u002Fskills\u002Fsoftware-development\u002Fsystematic-debugging\u002FSKILL.md",true,[],[80,112,134,155,176,195],{"skillNo":81,"name":56,"nameZh":6,"description":82,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":83,"categories":84,"keywords":99,"publishedAt":43},"01M71JFHVW1W4XE013TY9ZYN9P","Use when you have a spec or requirements for a multi-step task. Creates comprehensive implementation plans with bite-sized tasks, exact file paths, and complete code examples.","https:\u002F\u002Fgithub.com\u002Fxuanxuan1983\u002Fhermes-skills-backup\u002Fblob\u002Fmain\u002Fskills\u002Fsoftware-development\u002Fwriting-plans\u002FSKILL.md",[85,88,91,96],{"categoryNo":86,"categoryName":87,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":89,"categoryName":90,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":92,"categoryName":93,"taxonomyType":94,"taxonomyTypeDesc":95},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",{"categoryNo":97,"categoryName":98,"taxonomyType":94,"taxonomyTypeDesc":95},"01JBSEEDCAT000000000000036","内容创作者",[37,100,29,42,39,38,101,36,102,103,104,105,35,106,107,108,109,110,32,111],"writing plans","design","workflow","you","code","tasks","code-review","review","documentation","paths","planning","for",{"skillNo":113,"name":39,"nameZh":6,"description":114,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":115,"categories":116,"keywords":123,"publishedAt":43},"01M71JFF859RV0XGWS206X1TMB","Use when implementing any feature or bugfix, before writing implementation code. Enforces RED-GREEN-REFACTOR cycle with test-first approach.","https:\u002F\u002Fgithub.com\u002Fxuanxuan1983\u002Fhermes-skills-backup\u002Fblob\u002Fmain\u002Fskills\u002Fsoftware-development\u002Ftest-driven-development\u002FSKILL.md",[117,120,121,122],{"categoryNo":118,"categoryName":119,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":89,"categoryName":90,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":97,"categoryName":98,"taxonomyType":94,"taxonomyTypeDesc":95},[124,32,26,125,126,127,128,129,130,131,38,37,23,36,104,35,24,132,133,5],"test driven development","driven","test-first","green","cycle","red-green-refactor","testing","implementing","bugfix","refactor",{"skillNo":135,"name":57,"nameZh":6,"description":136,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":137,"categories":138,"keywords":148,"publishedAt":43},"01M71JF9RQ092KM5ZXCBBT6FS1","Use when executing implementation plans with independent tasks. Dispatches fresh delegate_task per task with two-stage review (spec compliance then code quality).","https:\u002F\u002Fgithub.com\u002Fxuanxuan1983\u002Fhermes-skills-backup\u002Fblob\u002Fmain\u002Fskills\u002Fsoftware-development\u002Fsubagent-driven-development\u002FSKILL.md",[139,140,143,144,145],{"categoryNo":89,"categoryName":90,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":141,"categoryName":142,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":92,"categoryName":93,"taxonomyType":94,"taxonomyTypeDesc":95},{"categoryNo":97,"categoryName":98,"taxonomyType":94,"taxonomyTypeDesc":95},{"categoryNo":146,"categoryName":147,"taxonomyType":94,"taxonomyTypeDesc":95},"01JBSEEDCAT000000000000037","律师与法务",[149,35,32,125,42,39,150,151,38,37,36,102,104,105,106,107,152,153,154,29],"subagent driven development","delegate","delegation","fresh","parallel","code quality",{"skillNo":156,"name":157,"nameZh":6,"description":158,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":159,"categories":160,"keywords":163,"publishedAt":43},"01M71JF76DA8ARZ4JRYR4VBRWM","requesting-code-review","Pre-commit verification pipeline — static security scan, baseline-aware quality gates, independent reviewer subagent, and auto-fix loop. Use after code changes and before committing, pushing, or opening a PR.","https:\u002F\u002Fgithub.com\u002Fxuanxuan1983\u002Fhermes-skills-backup\u002Fblob\u002Fmain\u002Fskills\u002Fsoftware-development\u002Frequesting-code-review\u002FSKILL.md",[161,162],{"categoryNo":118,"categoryName":119,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":92,"categoryName":93,"taxonomyType":94,"taxonomyTypeDesc":95},[164,165,104,107,42,166,167,39,168,169,38,170,37,171,172,173,35,106,174,175],"code review","requesting code review","pipeline","static","fix","auto-fix","auto","loop","security scan","commit","reviewer","verification",{"skillNo":177,"name":178,"nameZh":6,"description":179,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":180,"categories":181,"keywords":182,"publishedAt":43},"01M71JF52HZT5VQXFVF9K2H76K","plan","Plan mode for Hermes — inspect context, write a markdown plan into the active workspace's `.hermes\u002Fplans\u002F` directory, and do not execute the work.","https:\u002F\u002Fgithub.com\u002Fxuanxuan1983\u002Fhermes-skills-backup\u002Fblob\u002Fmain\u002Fskills\u002Fsoftware-development\u002Fplan\u002FSKILL.md",[],[178,183,184,110,32,111,185,186,29,37,102,35,187,188,189,190,191,192,193,194],"plan-mode","do","inspect","mode","work","markdown","active","directory","workspace","plan mode","write","implementation",{"skillNo":196,"name":197,"nameZh":6,"description":198,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":199,"categories":200,"keywords":205,"publishedAt":43},"01M71JE8HX3Q2TC5QV5SZVZHQ8","xitter","Interact with X\u002FTwitter via the x-cli terminal client using official X API credentials. Use for posting, reading timelines, searching tweets, liking, retweeting, bookmarks, mentions, and user lookups.","https:\u002F\u002Fgithub.com\u002Fxuanxuan1983\u002Fhermes-skills-backup\u002Fblob\u002Fmain\u002Fskills\u002Fsocial-media\u002Fxitter\u002FSKILL.md",[201,204],{"categoryNo":202,"categoryName":203,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":141,"categoryName":142,"taxonomyType":20,"taxonomyTypeDesc":21},[197,206,207,208,209,210,211,212,213,214,215,216,217,218,219,220,221,111,222,223],"Media","official","x api","social","secret","uv","access","api","credentials","cli","terminal","token","reading","macos","posting","social-media","twitter","linux"]