[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CBARAMY9YBME25Y6SW8BEE":3,"skill-same:01M6CBARAMY9YBME25Y6SW8BEE":82},{"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":37,"linkOnly":38,"markdownContent":39,"markdownBody":40,"frontMatter":41,"refName":46,"commitSha":47,"skillDirectory":48,"forksCount":49,"repositoryHtmlUrl":50,"repositoryHomepageUrl":51,"ownerHtmlUrl":52,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":53,"install":54,"resources":67},"01M6CBARAMY9YBME25Y6SW8BEE","systematic-debugging",null,"Root-cause debugging discipline for any bug, test failure, or unexpected behavior: investigate before proposing fixes. Language- and framework- agnostic. Use before attempting a fix, especially under time pressure.","shahboura\u002Fagents-opencode","shahboura","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F210767?v=4","01M6C6WKTBT0NH92BEPQRHQSYM","Shehab El Hadidy","01M6C6WKYXG8AE68MCGBNE5ZFR",2,"MIT","https:\u002F\u002Fgithub.com\u002Fshahboura\u002Fagents-opencode\u002Fblob\u002Fmain\u002F.opencode\u002Fskills\u002Fsystematic-debugging\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],"systematic debugging","debugging","test","framework","methodology","investigate","behavior","fix","use","discipline","superpowers","opencode","bug","2026-11-10 10:12:30",false,"---\nname: systematic-debugging\ndescription: >-\n  Root-cause debugging discipline for any bug, test failure, or unexpected\n  behavior: investigate before proposing fixes. Language- and framework-\n  agnostic. Use before attempting a fix, especially under time pressure.\nlicense: MIT\ncompatibility: opencode\nmetadata:\n  author: shahboura (methodology adapted from obra\u002Fsuperpowers, MIT)\n  version: \"1.0.0\"\n  audience: developers\n  workflow: debugging\n---\n\n# Systematic Debugging — root cause before fixes\n\n## What I do\n\n- Enforce a four-phase investigation before any fix is proposed\n- Turn \"quick fix\" pressure into evidence gathering\n- Escalate repeated failed fixes into an architecture question\n- Ship root-cause fixes, not symptom patches\n\n## When to use me\n\nUse for ANY technical issue: test failures, production bugs, unexpected\nbehavior, performance problems, build or integration failures.\n\nUse ESPECIALLY when:\n\n- Under time pressure (emergencies make guessing tempting)\n- \"Just one quick fix\" seems obvious\n- You have already tried multiple fixes\n- You do not fully understand the issue\n\n## The Iron Law\n\n```\nNO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST\n```\n\nIf Phase 1 is not complete, you cannot propose a fix.\n\n## The four phases\n\nComplete each phase before starting the next.\n\n### Phase 1 — Root cause investigation\n\n1. **Read the error carefully** — full stack traces, line numbers, paths, codes.\n2. **Reproduce consistently** — exact steps, every time; if it is not reproducible, gather more data, do not guess.\n3. **Check recent changes** — VCS diff, new dependencies, config, environment.\n4. **Gather evidence at component boundaries** — for multi-component systems, instrument each boundary (log inputs, outputs, config propagation) and run once to see WHERE it breaks before analysing. Log only the specific non-sensitive values needed; never log secrets, tokens, or PII.\n5. **Trace the data flow** — follow the bad value backward to its origin and fix at the source. See `references\u002Froot-cause-tracing.md`.\n\n### Phase 2 — Pattern analysis\n\n- Find similar working code in the same codebase.\n- Read any reference implementation completely — no skimming.\n- List every difference between working and broken, however small.\n- Understand the dependencies, settings, and assumptions.\n\n### Phase 3 — Hypothesis and testing\n\n- State one specific hypothesis (\"X is the cause because Y\") and write it down.\n- Test with the smallest possible change — one variable at a time.\n- Confirmed → Phase 4. Not confirmed → form a NEW hypothesis; do not stack fixes.\n- If you do not understand something, say so and research it.\n\n### Phase 4 — Implementation\n\n1. Create a failing test case that reproduces the bug (see `test-driven-development`).\n2. Implement ONE fix for the root cause — no bundled refactors, no \"while I'm here\" changes.\n3. Verify: the test passes and nothing else broke (see `verification-before-completion`).\n4. If the fix does not work, return to Phase 1 with the new information.\n5. **Three or more failed fixes → question the architecture**, not the hypothesis. Each fix revealing a new problem elsewhere is a design signal, not bad luck. Discuss with the user before attempting more fixes.\n\n## Red flags — stop and return to Phase 1\n\n- \"Quick fix now, investigate later\"\n- \"Just try changing X and see\"\n- \"Add several changes and run the tests\"\n- \"It's probably X, let me fix that\"\n- Proposing solutions before tracing the data flow\n- \"One more fix attempt\" after two failures\n- Each fix reveals a new problem in a different place\n\n## Common rationalizations\n\n| Excuse | Reality |\n|--------|---------|\n| \"Issue is simple, no process needed\" | Simple issues have root causes too; the process is fast for them. |\n| \"Emergency — no time\" | Systematic debugging is faster than guess-and-check thrashing. |\n| \"Just try this first\" | The first fix sets the pattern; do it right from the start. |\n| \"I'll write the test after confirming the fix\" | Untested fixes do not stick; a test first proves it. |\n| \"Several fixes at once saves time\" | You cannot isolate what worked, and you cause new bugs. |\n| \"I see the problem\" | Seeing symptoms is not understanding the root cause. |\n\n## When there is genuinely no root cause\n\nIf investigation shows the issue is environmental, timing-dependent, or\nexternal: document what you investigated, implement appropriate handling\n(retry, timeout, clear error), and add monitoring. Most \"no root cause\"\nconclusions are incomplete investigations.\n\n## Supporting techniques\n\n- `references\u002Froot-cause-tracing.md` — trace a bug backward through the call stack to its original trigger\n- `references\u002Fdefense-in-depth.md` — after finding the root cause, validate at every layer\n- `references\u002Fcondition-based-waiting.md` — replace arbitrary delays with condition polling\n\n## Related\n\n- `test-driven-development` — write the failing reproduction first\n- `verification-before-completion` — prove the fix before claiming success\n- `code-change-impact` — after the fix, trace the blast radius of the change\n\n## Provenance\n\nAdapted from `obra\u002Fsuperpowers` (MIT), © 2025 Jesse Vincent. See\n`THIRD_PARTY_NOTICES.md`.\n","# Systematic Debugging — root cause before fixes\n\n## What I do\n\n- Enforce a four-phase investigation before any fix is proposed\n- Turn \"quick fix\" pressure into evidence gathering\n- Escalate repeated failed fixes into an architecture question\n- Ship root-cause fixes, not symptom patches\n\n## When to use me\n\nUse for ANY technical issue: test failures, production bugs, unexpected\nbehavior, performance problems, build or integration failures.\n\nUse ESPECIALLY when:\n\n- Under time pressure (emergencies make guessing tempting)\n- \"Just one quick fix\" seems obvious\n- You have already tried multiple fixes\n- You do not fully understand the issue\n\n## The Iron Law\n\n```\nNO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST\n```\n\nIf Phase 1 is not complete, you cannot propose a fix.\n\n## The four phases\n\nComplete each phase before starting the next.\n\n### Phase 1 — Root cause investigation\n\n1. **Read the error carefully** — full stack traces, line numbers, paths, codes.\n2. **Reproduce consistently** — exact steps, every time; if it is not reproducible, gather more data, do not guess.\n3. **Check recent changes** — VCS diff, new dependencies, config, environment.\n4. **Gather evidence at component boundaries** — for multi-component systems, instrument each boundary (log inputs, outputs, config propagation) and run once to see WHERE it breaks before analysing. Log only the specific non-sensitive values needed; never log secrets, tokens, or PII.\n5. **Trace the data flow** — follow the bad value backward to its origin and fix at the source. See `references\u002Froot-cause-tracing.md`.\n\n### Phase 2 — Pattern analysis\n\n- Find similar working code in the same codebase.\n- Read any reference implementation completely — no skimming.\n- List every difference between working and broken, however small.\n- Understand the dependencies, settings, and assumptions.\n\n### Phase 3 — Hypothesis and testing\n\n- State one specific hypothesis (\"X is the cause because Y\") and write it down.\n- Test with the smallest possible change — one variable at a time.\n- Confirmed → Phase 4. Not confirmed → form a NEW hypothesis; do not stack fixes.\n- If you do not understand something, say so and research it.\n\n### Phase 4 — Implementation\n\n1. Create a failing test case that reproduces the bug (see `test-driven-development`).\n2. Implement ONE fix for the root cause — no bundled refactors, no \"while I'm here\" changes.\n3. Verify: the test passes and nothing else broke (see `verification-before-completion`).\n4. If the fix does not work, return to Phase 1 with the new information.\n5. **Three or more failed fixes → question the architecture**, not the hypothesis. Each fix revealing a new problem elsewhere is a design signal, not bad luck. Discuss with the user before attempting more fixes.\n\n## Red flags — stop and return to Phase 1\n\n- \"Quick fix now, investigate later\"\n- \"Just try changing X and see\"\n- \"Add several changes and run the tests\"\n- \"It's probably X, let me fix that\"\n- Proposing solutions before tracing the data flow\n- \"One more fix attempt\" after two failures\n- Each fix reveals a new problem in a different place\n\n## Common rationalizations\n\n| Excuse | Reality |\n|--------|---------|\n| \"Issue is simple, no process needed\" | Simple issues have root causes too; the process is fast for them. |\n| \"Emergency — no time\" | Systematic debugging is faster than guess-and-check thrashing. |\n| \"Just try this first\" | The first fix sets the pattern; do it right from the start. |\n| \"I'll write the test after confirming the fix\" | Untested fixes do not stick; a test first proves it. |\n| \"Several fixes at once saves time\" | You cannot isolate what worked, and you cause new bugs. |\n| \"I see the problem\" | Seeing symptoms is not understanding the root cause. |\n\n## When there is genuinely no root cause\n\nIf investigation shows the issue is environmental, timing-dependent, or\nexternal: document what you investigated, implement appropriate handling\n(retry, timeout, clear error), and add monitoring. Most \"no root cause\"\nconclusions are incomplete investigations.\n\n## Supporting techniques\n\n- `references\u002Froot-cause-tracing.md` — trace a bug backward through the call stack to its original trigger\n- `references\u002Fdefense-in-depth.md` — after finding the root cause, validate at every layer\n- `references\u002Fcondition-based-waiting.md` — replace arbitrary delays with condition polling\n\n## Related\n\n- `test-driven-development` — write the failing reproduction first\n- `verification-before-completion` — prove the fix before claiming success\n- `code-change-impact` — after the fix, trace the blast radius of the change\n\n## Provenance\n\nAdapted from `obra\u002Fsuperpowers` (MIT), © 2025 Jesse Vincent. See\n`THIRD_PARTY_NOTICES.md`.\n",{"name":5,"license":15,"metadata":42,"description":7,"compatibility":35},{"author":43,"version":44,"audience":45,"workflow":25},"shahboura (methodology adapted from obra\u002Fsuperpowers, MIT)","1.0.0","developers","main","9b951b5b2e5d07d427baff330db5deb2a8c67511",".opencode\u002Fskills\u002Fsystematic-debugging",0,"https:\u002F\u002Fgithub.com\u002Fshahboura\u002Fagents-opencode","https:\u002F\u002Fagnts.elkodr.com\u002F","https:\u002F\u002Fgithub.com\u002Fshahboura","2026-11-05 13:30:42",{"source":8,"skillName":5,"commands":55,"prompt":65,"zipAvailable":66},[56,59,62],{"tool":57,"command":58},"npx","npx skills add shahboura\u002Fagents-opencode --skill systematic-debugging",{"tool":60,"command":61},"bunx","bunx skills add shahboura\u002Fagents-opencode --skill systematic-debugging",{"tool":63,"command":64},"pnpm","pnpm dlx skills add shahboura\u002Fagents-opencode --skill systematic-debugging","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fshahboura\u002Fagents-opencode\u002Fblob\u002Fmain\u002F.opencode\u002Fskills\u002Fsystematic-debugging\u002FSKILL.md",true,[68,74,78],{"path":69,"resourceType":70,"resourceTypeDesc":71,"sizeBytes":72,"sourceHtmlUrl":73},"references\u002Fcondition-based-waiting.md","REFERENCE","参考文档",3113,"https:\u002F\u002Fgithub.com\u002Fshahboura\u002Fagents-opencode\u002Fblob\u002Fmain\u002F.opencode\u002Fskills\u002Fsystematic-debugging\u002Freferences\u002Fcondition-based-waiting.md",{"path":75,"resourceType":70,"resourceTypeDesc":71,"sizeBytes":76,"sourceHtmlUrl":77},"references\u002Fdefense-in-depth.md",3325,"https:\u002F\u002Fgithub.com\u002Fshahboura\u002Fagents-opencode\u002Fblob\u002Fmain\u002F.opencode\u002Fskills\u002Fsystematic-debugging\u002Freferences\u002Fdefense-in-depth.md",{"path":79,"resourceType":70,"resourceTypeDesc":71,"sizeBytes":80,"sourceHtmlUrl":81},"references\u002Froot-cause-tracing.md",3690,"https:\u002F\u002Fgithub.com\u002Fshahboura\u002Fagents-opencode\u002Fblob\u002Fmain\u002F.opencode\u002Fskills\u002Fsystematic-debugging\u002Freferences\u002Froot-cause-tracing.md",[83,89,98,103,108,113],{"skillNo":84,"name":85,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":86,"categories":87,"keywords":88,"publishedAt":37},"01M6CBBX1C6NV7VY8XK21DV5FW","python","https:\u002F\u002Fgithub.com\u002Fshahboura\u002Fagents-opencode\u002Fblob\u002Fmain\u002Fscripts\u002Ffixtures\u002Fvalidate-agents\u002Fvalid\u002F.opencode\u002Fskills\u002Fpython\u002FSKILL.md",[],[85],{"skillNo":90,"name":91,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":92,"categories":93,"keywords":94,"publishedAt":37},"01M6CBBVB7W6ABJH8XP3Z8PPMK","docs-validation","https:\u002F\u002Fgithub.com\u002Fshahboura\u002Fagents-opencode\u002Fblob\u002Fmain\u002Fscripts\u002Ffixtures\u002Fvalidate-agents\u002Fvalid\u002F.opencode\u002Fskills\u002Fdocs-validation\u002FSKILL.md",[],[95,96,97],"docs","validation","docs validation",{"skillNo":99,"name":85,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":100,"categories":101,"keywords":102,"publishedAt":37},"01M6CBBT2WC781609MH5RN7KM7","https:\u002F\u002Fgithub.com\u002Fshahboura\u002Fagents-opencode\u002Fblob\u002Fmain\u002Fscripts\u002Ffixtures\u002Fvalidate-agents\u002Funknown-skill\u002F.opencode\u002Fskills\u002Fpython\u002FSKILL.md",[],[85],{"skillNo":104,"name":91,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":105,"categories":106,"keywords":107,"publishedAt":37},"01M6CBBRNY6TDRZ5627GC8436D","https:\u002F\u002Fgithub.com\u002Fshahboura\u002Fagents-opencode\u002Fblob\u002Fmain\u002Fscripts\u002Ffixtures\u002Fvalidate-agents\u002Funknown-skill\u002F.opencode\u002Fskills\u002Fdocs-validation\u002FSKILL.md",[],[95,96,97],{"skillNo":109,"name":85,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":110,"categories":111,"keywords":112,"publishedAt":37},"01M6CBBQDS170GBYA1CVW3DC5D","https:\u002F\u002Fgithub.com\u002Fshahboura\u002Fagents-opencode\u002Fblob\u002Fmain\u002Fscripts\u002Ffixtures\u002Fvalidate-agents\u002Finline-skill\u002F.opencode\u002Fskills\u002Fpython\u002FSKILL.md",[],[85],{"skillNo":114,"name":91,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":115,"categories":116,"keywords":117,"publishedAt":37},"01M6CBBP222WAW802YHY37F48A","https:\u002F\u002Fgithub.com\u002Fshahboura\u002Fagents-opencode\u002Fblob\u002Fmain\u002Fscripts\u002Ffixtures\u002Fvalidate-agents\u002Finline-skill\u002F.opencode\u002Fskills\u002Fdocs-validation\u002FSKILL.md",[],[95,96,97]]