[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M754SCANCXD6SCCG08C4HYF1":3,"skill-same:01M754SCANCXD6SCCG08C4HYF1":60},{"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":17,"publishedAt":18,"linkOnly":19,"markdownContent":20,"markdownBody":21,"frontMatter":22,"refName":24,"commitSha":25,"skillDirectory":26,"forksCount":27,"repositoryHtmlUrl":28,"repositoryHomepageUrl":6,"ownerHtmlUrl":29,"ownerBlogUrl":6,"ownerDescription":30,"updatedAt":31,"install":32,"resources":45},"01M754SCANCXD6SCCG08C4HYF1","codex-systematic-debugging",null,"Use for bugs, test failures, broken behavior, or unexpected results; enforces 4-phase root-cause debugging before fixes.","Bang-isme\u002FAgencyCLI","Bang-isme","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F179383529?v=4","01M754NDM8K05SAX2V31R63WEE","01M754NDMV48ECFT4HY6X2CKQ0",2,"MIT","https:\u002F\u002Fgithub.com\u002FBang-isme\u002FAgencyCLI\u002Fblob\u002Fmain\u002Fpackages\u002Fcli\u002Fskills\u002Fcodex-systematic-debugging\u002FSKILL.md",[],[],"2026-11-12 13:55:43",false,"---\nname: codex-systematic-debugging\ndescription: Use for bugs, test failures, broken behavior, or unexpected results; enforces 4-phase root-cause debugging before fixes.\nload_priority: on-demand\n---\n\n## TL;DR\n4-phase process: Root Cause Investigation → Pattern Analysis → Hypothesis & Testing → Implementation. No fixes without root cause. 3+ failed fixes = question architecture. Use `$root-cause` or `$trace` to activate.\n\n# Systematic Debugging\n\n## Activation\n\n1. Activate on `$codex-systematic-debugging`, `$root-cause`, or `$trace`.\n2. Activate when encountering any bug, test failure, or unexpected behavior.\n3. Activate when `codex-workflow-autopilot` routes to `debug` or `fix` workflow.\n4. Activate when `codex-intent-context-analyzer` detects debug intent.\n5. Activate when previous fix attempts failed.\n\n**Announce at start:** \"I'm using codex-systematic-debugging to investigate root cause.\"\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**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## 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- Deadline is tight (systematic is faster than thrashing)\n\n## The Four Phases\n\nYou MUST complete each phase before proceeding to the next.\n\n### Phase 1: Root Cause Investigation\n\n**BEFORE attempting ANY fix:**\n\n1. **Read Error Messages Carefully**\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\n2. **Reproduce Consistently**\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\n3. **Check Recent Changes**\n   - What changed that could cause this?\n   - Git diff, recent commits\n   - New dependencies, config changes\n   - Environmental differences\n\n4. **Gather Evidence in Multi-Component Systems**\n\n   **WHEN system has multiple components (CI → build → signing, API → service → database):**\n\n   **BEFORE proposing fixes, add diagnostic instrumentation:**\n   ```\n   For EACH component boundary:\n     - Log what data enters component\n     - Log what data exits component\n     - Verify environment\u002Fconfig propagation\n     - Check state at each layer\n\n   Run once to gather evidence showing WHERE it breaks\n   THEN analyze evidence to identify failing component\n   THEN investigate that specific component\n   ```\n\n   **Example (multi-layer system):**\n   ```bash\n   # Layer 1: Environment\n   echo \"=== ENV check ===\"\n   echo \"DB_HOST: ${DB_HOST:+SET}${DB_HOST:-UNSET}\"\n\n   # Layer 2: Application config\n   echo \"=== Config loaded ===\"\n   node -e \"console.log(require('.\u002Fconfig').database)\"\n\n   # Layer 3: Connection\n   echo \"=== DB connection test ===\"\n   node -e \"require('.\u002Fdb').ping().then(r => console.log(r))\"\n\n   # Layer 4: Query\n   echo \"=== Query test ===\"\n   node -e \"require('.\u002Fdb').query('SELECT 1').then(r => console.log(r))\"\n   ```\n\n   **This reveals:** Which layer fails (env → config ✓, config → connection ✗)\n\n5. **Trace Data Flow**\n\n   **WHEN error is deep in call stack:**\n\n   See `references\u002Froot-cause-tracing.md` for the complete backward tracing technique.\n\n   **Quick version:**\n   - Where does bad value originate?\n   - What called this with bad value?\n   - Keep tracing up until you find the source\n   - Fix at source, not at symptom\n\n### Phase 2: Pattern Analysis\n\n**Find the pattern before fixing:**\n\n1. **Find Working Examples**\n   - Locate similar working code in same codebase\n   - What works that's similar to what's broken?\n\n2. **Compare Against References**\n   - If implementing pattern, read reference implementation COMPLETELY\n   - Don't skim — read every line\n   - Understand the pattern fully before applying\n\n3. **Identify Differences**\n   - What's different between working and broken?\n   - List every difference, however small\n   - Don't assume \"that can't matter\"\n\n4. **Understand Dependencies**\n   - What other components does this need?\n   - What settings, config, environment?\n   - What assumptions does it make?\n\n### Phase 3: Hypothesis and Testing\n\n**Scientific method:**\n\n1. **Form Single Hypothesis**\n   - State clearly: \"I think X is the root cause because Y\"\n   - Write it down\n   - Be specific, not vague\n\n2. **Test Minimally**\n   - Make the SMALLEST possible change to test hypothesis\n   - One variable at a time\n   - Don't fix multiple things at once\n\n3. **Verify Before Continuing**\n   - Did it work? Yes → Phase 4\n   - Didn't work? Form NEW hypothesis\n   - DON'T add more fixes on top\n\n4. **When You Don't Know**\n   - Say \"I don't understand X\"\n   - Don't pretend to know\n   - Ask for help\n   - Research more\n\n### Phase 4: Implementation\n\n**Fix the root cause, not the symptom:**\n\n1. **Create Failing Test Case**\n   - Simplest possible reproduction\n   - Automated test if possible\n   - Use `codex-test-driven-development` skill for writing proper failing tests\n   - MUST have before fixing\n\n2. **Implement Single Fix**\n   - Address the root cause identified\n   - ONE change at a time\n   - No \"while I'm here\" improvements\n   - No bundled refactoring\n\n3. **Verify Fix**\n   - Test passes now?\n   - No other tests broken?\n   - Issue actually resolved?\n   - Run `$gate` or `$check` for full verification\n\n4. **If Fix Doesn't Work**\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 (Phase 4.5 below)**\n   - DON'T attempt Fix #4 without architectural discussion\n\n### Phase 4.5: Question Architecture (3+ Failed Fixes)\n\n**Pattern indicating architectural problem:**\n- Each fix reveals new shared state\u002Fcoupling\u002Fproblem in 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 architecture vs. continue fixing symptoms?\n\n**Discuss with the human before attempting more fixes.**\n\nThis is NOT a failed hypothesis — this is a wrong architecture.\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 new problem in different place**\n\n**ALL of these mean: STOP. Return to Phase 1.**\n\n**If 3+ fixes failed:** Question the architecture (see Phase 4.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 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 | Understand WHAT and WHY |\n| **2. Pattern** | Find working examples, compare | Identify differences |\n| **3. Hypothesis** | Form theory, test minimally | Confirmed or new hypothesis |\n| **4. Implementation** | Create test, fix, verify | Bug resolved, tests pass, gate green |\n\n## CodexAI Integration\n\n### Gate Integration\n\nAfter Phase 4 fix, verify through quality gate:\n\n```bash\n# Quick verification\npython codex-execution-quality-gate\u002Fscripts\u002Fauto_gate.py --mode quick --project-root \u003Crepo>\n\n# Smart test selection\npython codex-execution-quality-gate\u002Fscripts\u002Fsmart_test_selector.py --project-root \u003Crepo>\n```\n\n### Workflow Integration\n\n| Alias | Behavior |\n|-------|----------|\n| `$debug` | Activates `.workflows\u002Fdebug.md` + this skill |\n| `$root-cause` | Jump directly to Phase 1 |\n| `$trace` | Jump to data flow tracing (Phase 1, Step 5) |\n\n## Supporting Techniques\n\nAvailable in `references\u002F` directory:\n\n- **`root-cause-tracing.md`** — Trace bugs backward through call stack to find original trigger\n- **`defense-in-depth.md`** — Add validation at multiple layers after finding root cause\n- **`condition-based-waiting.md`** — Replace arbitrary timeouts with condition polling\n\n## Related Skills\n\n- **`codex-test-driven-development`** — For creating failing test case (Phase 4, Step 1)\n- **`codex-execution-quality-gate`** — Verify fix via `$gate` before claiming success\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","## TL;DR\n4-phase process: Root Cause Investigation → Pattern Analysis → Hypothesis & Testing → Implementation. No fixes without root cause. 3+ failed fixes = question architecture. Use `$root-cause` or `$trace` to activate.\n\n# Systematic Debugging\n\n## Activation\n\n1. Activate on `$codex-systematic-debugging`, `$root-cause`, or `$trace`.\n2. Activate when encountering any bug, test failure, or unexpected behavior.\n3. Activate when `codex-workflow-autopilot` routes to `debug` or `fix` workflow.\n4. Activate when `codex-intent-context-analyzer` detects debug intent.\n5. Activate when previous fix attempts failed.\n\n**Announce at start:** \"I'm using codex-systematic-debugging to investigate root cause.\"\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**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## 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- Deadline is tight (systematic is faster than thrashing)\n\n## The Four Phases\n\nYou MUST complete each phase before proceeding to the next.\n\n### Phase 1: Root Cause Investigation\n\n**BEFORE attempting ANY fix:**\n\n1. **Read Error Messages Carefully**\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\n2. **Reproduce Consistently**\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\n3. **Check Recent Changes**\n   - What changed that could cause this?\n   - Git diff, recent commits\n   - New dependencies, config changes\n   - Environmental differences\n\n4. **Gather Evidence in Multi-Component Systems**\n\n   **WHEN system has multiple components (CI → build → signing, API → service → database):**\n\n   **BEFORE proposing fixes, add diagnostic instrumentation:**\n   ```\n   For EACH component boundary:\n     - Log what data enters component\n     - Log what data exits component\n     - Verify environment\u002Fconfig propagation\n     - Check state at each layer\n\n   Run once to gather evidence showing WHERE it breaks\n   THEN analyze evidence to identify failing component\n   THEN investigate that specific component\n   ```\n\n   **Example (multi-layer system):**\n   ```bash\n   # Layer 1: Environment\n   echo \"=== ENV check ===\"\n   echo \"DB_HOST: ${DB_HOST:+SET}${DB_HOST:-UNSET}\"\n\n   # Layer 2: Application config\n   echo \"=== Config loaded ===\"\n   node -e \"console.log(require('.\u002Fconfig').database)\"\n\n   # Layer 3: Connection\n   echo \"=== DB connection test ===\"\n   node -e \"require('.\u002Fdb').ping().then(r => console.log(r))\"\n\n   # Layer 4: Query\n   echo \"=== Query test ===\"\n   node -e \"require('.\u002Fdb').query('SELECT 1').then(r => console.log(r))\"\n   ```\n\n   **This reveals:** Which layer fails (env → config ✓, config → connection ✗)\n\n5. **Trace Data Flow**\n\n   **WHEN error is deep in call stack:**\n\n   See `references\u002Froot-cause-tracing.md` for the complete backward tracing technique.\n\n   **Quick version:**\n   - Where does bad value originate?\n   - What called this with bad value?\n   - Keep tracing up until you find the source\n   - Fix at source, not at symptom\n\n### Phase 2: Pattern Analysis\n\n**Find the pattern before fixing:**\n\n1. **Find Working Examples**\n   - Locate similar working code in same codebase\n   - What works that's similar to what's broken?\n\n2. **Compare Against References**\n   - If implementing pattern, read reference implementation COMPLETELY\n   - Don't skim — read every line\n   - Understand the pattern fully before applying\n\n3. **Identify Differences**\n   - What's different between working and broken?\n   - List every difference, however small\n   - Don't assume \"that can't matter\"\n\n4. **Understand Dependencies**\n   - What other components does this need?\n   - What settings, config, environment?\n   - What assumptions does it make?\n\n### Phase 3: Hypothesis and Testing\n\n**Scientific method:**\n\n1. **Form Single Hypothesis**\n   - State clearly: \"I think X is the root cause because Y\"\n   - Write it down\n   - Be specific, not vague\n\n2. **Test Minimally**\n   - Make the SMALLEST possible change to test hypothesis\n   - One variable at a time\n   - Don't fix multiple things at once\n\n3. **Verify Before Continuing**\n   - Did it work? Yes → Phase 4\n   - Didn't work? Form NEW hypothesis\n   - DON'T add more fixes on top\n\n4. **When You Don't Know**\n   - Say \"I don't understand X\"\n   - Don't pretend to know\n   - Ask for help\n   - Research more\n\n### Phase 4: Implementation\n\n**Fix the root cause, not the symptom:**\n\n1. **Create Failing Test Case**\n   - Simplest possible reproduction\n   - Automated test if possible\n   - Use `codex-test-driven-development` skill for writing proper failing tests\n   - MUST have before fixing\n\n2. **Implement Single Fix**\n   - Address the root cause identified\n   - ONE change at a time\n   - No \"while I'm here\" improvements\n   - No bundled refactoring\n\n3. **Verify Fix**\n   - Test passes now?\n   - No other tests broken?\n   - Issue actually resolved?\n   - Run `$gate` or `$check` for full verification\n\n4. **If Fix Doesn't Work**\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 (Phase 4.5 below)**\n   - DON'T attempt Fix #4 without architectural discussion\n\n### Phase 4.5: Question Architecture (3+ Failed Fixes)\n\n**Pattern indicating architectural problem:**\n- Each fix reveals new shared state\u002Fcoupling\u002Fproblem in 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 architecture vs. continue fixing symptoms?\n\n**Discuss with the human before attempting more fixes.**\n\nThis is NOT a failed hypothesis — this is a wrong architecture.\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 new problem in different place**\n\n**ALL of these mean: STOP. Return to Phase 1.**\n\n**If 3+ fixes failed:** Question the architecture (see Phase 4.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 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 | Understand WHAT and WHY |\n| **2. Pattern** | Find working examples, compare | Identify differences |\n| **3. Hypothesis** | Form theory, test minimally | Confirmed or new hypothesis |\n| **4. Implementation** | Create test, fix, verify | Bug resolved, tests pass, gate green |\n\n## CodexAI Integration\n\n### Gate Integration\n\nAfter Phase 4 fix, verify through quality gate:\n\n```bash\n# Quick verification\npython codex-execution-quality-gate\u002Fscripts\u002Fauto_gate.py --mode quick --project-root \u003Crepo>\n\n# Smart test selection\npython codex-execution-quality-gate\u002Fscripts\u002Fsmart_test_selector.py --project-root \u003Crepo>\n```\n\n### Workflow Integration\n\n| Alias | Behavior |\n|-------|----------|\n| `$debug` | Activates `.workflows\u002Fdebug.md` + this skill |\n| `$root-cause` | Jump directly to Phase 1 |\n| `$trace` | Jump to data flow tracing (Phase 1, Step 5) |\n\n## Supporting Techniques\n\nAvailable in `references\u002F` directory:\n\n- **`root-cause-tracing.md`** — Trace bugs backward through call stack to find original trigger\n- **`defense-in-depth.md`** — Add validation at multiple layers after finding root cause\n- **`condition-based-waiting.md`** — Replace arbitrary timeouts with condition polling\n\n## Related Skills\n\n- **`codex-test-driven-development`** — For creating failing test case (Phase 4, Step 1)\n- **`codex-execution-quality-gate`** — Verify fix via `$gate` before claiming success\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",{"name":5,"description":7,"load_priority":23},"on-demand","main","19b976c6b4f182f06d2d2e6b030549f2f8a69cc0","packages\u002Fcli\u002Fskills\u002Fcodex-systematic-debugging",0,"https:\u002F\u002Fgithub.com\u002FBang-isme\u002FAgencyCLI","https:\u002F\u002Fgithub.com\u002FBang-isme","Hi my name is jeff","2026-07-15 19:58:17",{"source":8,"skillName":5,"commands":33,"prompt":43,"zipAvailable":44},[34,37,40],{"tool":35,"command":36},"npx","npx skills add Bang-isme\u002FAgencyCLI --skill codex-systematic-debugging",{"tool":38,"command":39},"bunx","bunx skills add Bang-isme\u002FAgencyCLI --skill codex-systematic-debugging",{"tool":41,"command":42},"pnpm","pnpm dlx skills add Bang-isme\u002FAgencyCLI --skill codex-systematic-debugging","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FBang-isme\u002FAgencyCLI\u002Fblob\u002Fmain\u002Fpackages\u002Fcli\u002Fskills\u002Fcodex-systematic-debugging\u002FSKILL.md",true,[46,52,56],{"path":47,"resourceType":48,"resourceTypeDesc":49,"sizeBytes":50,"sourceHtmlUrl":51},"references\u002Fcondition-based-waiting.md","REFERENCE","参考文档",3754,"https:\u002F\u002Fgithub.com\u002FBang-isme\u002FAgencyCLI\u002Fblob\u002Fmain\u002Fpackages\u002Fcli\u002Fskills\u002Fcodex-systematic-debugging\u002Freferences\u002Fcondition-based-waiting.md",{"path":53,"resourceType":48,"resourceTypeDesc":49,"sizeBytes":54,"sourceHtmlUrl":55},"references\u002Fdefense-in-depth.md",3524,"https:\u002F\u002Fgithub.com\u002FBang-isme\u002FAgencyCLI\u002Fblob\u002Fmain\u002Fpackages\u002Fcli\u002Fskills\u002Fcodex-systematic-debugging\u002Freferences\u002Fdefense-in-depth.md",{"path":57,"resourceType":48,"resourceTypeDesc":49,"sizeBytes":58,"sourceHtmlUrl":59},"references\u002Froot-cause-tracing.md",4104,"https:\u002F\u002Fgithub.com\u002FBang-isme\u002FAgencyCLI\u002Fblob\u002Fmain\u002Fpackages\u002Fcli\u002Fskills\u002Fcodex-systematic-debugging\u002Freferences\u002Froot-cause-tracing.md",[61,68,75,82,89,96],{"skillNo":62,"name":63,"nameZh":6,"description":64,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":65,"categories":66,"keywords":67,"publishedAt":18},"01M754T5CB6WCXB2AV8N0M50AC","codex-test-driven-development","Fixture stub for TDD skill.","https:\u002F\u002Fgithub.com\u002FBang-isme\u002FAgencyCLI\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fmock-skills\u002Fcodex-test-driven-development\u002FSKILL.md",[],[],{"skillNo":69,"name":70,"nameZh":6,"description":71,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":72,"categories":73,"keywords":74,"publishedAt":18},"01M754T41J59TG0MJYC52TES58","codex-subagent-execution","Fixture stub for subagent execution skill.","https:\u002F\u002Fgithub.com\u002FBang-isme\u002FAgencyCLI\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fmock-skills\u002Fcodex-subagent-execution\u002FSKILL.md",[],[],{"skillNo":76,"name":77,"nameZh":6,"description":78,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":79,"categories":80,"keywords":81,"publishedAt":18},"01M754T2JDSPA3YF83FK6BMNV6","codex-runtime-hook","Fixture stub for runtime hook skill.","https:\u002F\u002Fgithub.com\u002FBang-isme\u002FAgencyCLI\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fmock-skills\u002Fcodex-runtime-hook\u002FSKILL.md",[],[],{"skillNo":83,"name":84,"nameZh":6,"description":85,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":86,"categories":87,"keywords":88,"publishedAt":18},"01M754T1HG4JRTJVZC2PBFTXDT","codex-plan-writer","Fixture stub for plan writer skill.","https:\u002F\u002Fgithub.com\u002FBang-isme\u002FAgencyCLI\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fmock-skills\u002Fcodex-plan-writer\u002FSKILL.md",[],[],{"skillNo":90,"name":91,"nameZh":6,"description":92,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":93,"categories":94,"keywords":95,"publishedAt":18},"01M754SZJVZKGQR5PSA6YFFY09","codex-execution-quality-gate","Fixture stub for quality gate skill.","https:\u002F\u002Fgithub.com\u002FBang-isme\u002FAgencyCLI\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fmock-skills\u002Fcodex-execution-quality-gate\u002FSKILL.md",[],[],{"skillNo":97,"name":98,"nameZh":6,"description":99,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":100,"categories":101,"keywords":102,"publishedAt":18},"01M754SXBJ1DE0JR6TK0XJ4SAK","codex-demo","Minimal fixture skill for Agency CLI skill-md parser tests.","https:\u002F\u002Fgithub.com\u002FBang-isme\u002FAgencyCLI\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fmock-skills\u002Fcodex-demo\u002FSKILL.md",[],[]]