[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71JZ735R78C1P1WZXKQCXFN":3,"skill-same:01M71JZ735R78C1P1WZXKQCXFN":115},{"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":16,"sourceHtmlUrl":17,"categories":18,"keywords":27,"publishedAt":37,"linkOnly":38,"markdownContent":39,"markdownBody":40,"frontMatter":41,"refName":43,"commitSha":44,"skillDirectory":45,"forksCount":46,"repositoryHtmlUrl":47,"repositoryHomepageUrl":48,"ownerHtmlUrl":49,"ownerBlogUrl":50,"ownerDescription":51,"updatedAt":52,"install":53,"resources":66},"01M71JZ735R78C1P1WZXKQCXFN","systematic-debugging",null,"Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes","coco-research\u002Fcoco","coco-research","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F68911604?v=4","01M71JRE9C4NM4NSZM4JD0BJTB","Coco Research","01M71JREA0ZMR0PMH3CKA99SN1",631,"MIT","https:\u002F\u002Fgithub.com\u002Fcoco-research\u002Fcoco\u002Fblob\u002Fmain\u002Fskills\u002Fsystematic-debugging\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fcoco-research\u002Fcoco\u002Fblob\u002Fmain\u002Fskills\u002Fsystematic-debugging\u002FSKILL.md",[19,24],{"categoryNo":20,"categoryName":21,"taxonomyType":22,"taxonomyTypeDesc":23},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":25,"categoryName":26,"taxonomyType":22,"taxonomyTypeDesc":23},"01JBSEEDCAT000000000000023","Skill与智能体开发",[28,29,30,31,32,33,34,35,36],"systematic debugging","debugging","systematic","test","behavior","use","bug","fixes","when","2026-11-10 10:12:30",false,"---\nname: systematic-debugging\ndescription: Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes\ndomain: foundational\n---\n\n# Systematic Debugging\n\n## Overview\n\n**Announce at start:** \"Systematic Debugging skill activated.\"\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- Manager 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### 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: Workflow\n   echo \"=== Secrets available in workflow: ===\"\n   echo \"IDENTITY: ${IDENTITY:+SET}${IDENTITY:-UNSET}\"\n\n   # Layer 2: Build script\n   echo \"=== Env vars in build script: ===\"\n   env | grep IDENTITY || echo \"IDENTITY not in environment\"\n\n   # Layer 3: Signing script\n   echo \"=== Keychain state: ===\"\n   security list-keychains\n   security find-identity -v\n\n   # Layer 4: Actual signing\n   codesign --sign \"$IDENTITY\" --verbose=4 \"$APP\"\n   ```\n\n   **This reveals:** Which layer fails (secrets → workflow ✓, workflow → build ✗)\n\n5. **Trace Data Flow**\n\n   **WHEN error is deep in call stack:**\n\n   See `root-cause-tracing.md` in this directory 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   - One-off test script if no framework\n   - MUST have before fixing\n   - Use the `superpowers:test-driven-development` skill for writing proper failing tests\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\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 (step 5 below)**\n   - DON'T attempt Fix #4 without architectural discussion\n\n5. **If 3+ Fixes Failed: Question Architecture**\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 your human partner before attempting more fixes**\n\n   This 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## your human partner's Signals You're Doing It Wrong\n\n**Watch for these redirections:**\n- \"Is that not happening?\" - You assumed without verifying\n- \"Will it show us...?\" - You should have added evidence gathering\n- \"Stop guessing\" - You're proposing fixes without understanding\n- \"Ultrathink this\" - Question fundamentals, not just symptoms\n- \"We're stuck?\" (frustrated) - Your approach isn't working\n\n**When you see these:** STOP. Return to Phase 1.\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 |\n\n## When Process Reveals \"No Root Cause\"\n\nIf systematic investigation reveals issue is truly environmental, timing-dependent, or external:\n\n1. You've completed the process\n2. Document what you investigated\n3. Implement appropriate handling (retry, timeout, error message)\n4. Add monitoring\u002Flogging for future investigation\n\n**But:** 95% of \"no root cause\" cases are incomplete investigation.\n\n## Supporting Techniques\n\nThese techniques are part of systematic debugging and available in this 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- **superpowers:test-driven-development** - For creating failing test case (Phase 4, Step 1)\n- **superpowers:verification-before-completion** - Verify fix worked 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","# Systematic Debugging\n\n## Overview\n\n**Announce at start:** \"Systematic Debugging skill activated.\"\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- Manager 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### 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: Workflow\n   echo \"=== Secrets available in workflow: ===\"\n   echo \"IDENTITY: ${IDENTITY:+SET}${IDENTITY:-UNSET}\"\n\n   # Layer 2: Build script\n   echo \"=== Env vars in build script: ===\"\n   env | grep IDENTITY || echo \"IDENTITY not in environment\"\n\n   # Layer 3: Signing script\n   echo \"=== Keychain state: ===\"\n   security list-keychains\n   security find-identity -v\n\n   # Layer 4: Actual signing\n   codesign --sign \"$IDENTITY\" --verbose=4 \"$APP\"\n   ```\n\n   **This reveals:** Which layer fails (secrets → workflow ✓, workflow → build ✗)\n\n5. **Trace Data Flow**\n\n   **WHEN error is deep in call stack:**\n\n   See `root-cause-tracing.md` in this directory 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   - One-off test script if no framework\n   - MUST have before fixing\n   - Use the `superpowers:test-driven-development` skill for writing proper failing tests\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\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 (step 5 below)**\n   - DON'T attempt Fix #4 without architectural discussion\n\n5. **If 3+ Fixes Failed: Question Architecture**\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 your human partner before attempting more fixes**\n\n   This 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## your human partner's Signals You're Doing It Wrong\n\n**Watch for these redirections:**\n- \"Is that not happening?\" - You assumed without verifying\n- \"Will it show us...?\" - You should have added evidence gathering\n- \"Stop guessing\" - You're proposing fixes without understanding\n- \"Ultrathink this\" - Question fundamentals, not just symptoms\n- \"We're stuck?\" (frustrated) - Your approach isn't working\n\n**When you see these:** STOP. Return to Phase 1.\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 |\n\n## When Process Reveals \"No Root Cause\"\n\nIf systematic investigation reveals issue is truly environmental, timing-dependent, or external:\n\n1. You've completed the process\n2. Document what you investigated\n3. Implement appropriate handling (retry, timeout, error message)\n4. Add monitoring\u002Flogging for future investigation\n\n**But:** 95% of \"no root cause\" cases are incomplete investigation.\n\n## Supporting Techniques\n\nThese techniques are part of systematic debugging and available in this 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- **superpowers:test-driven-development** - For creating failing test case (Phase 4, Step 1)\n- **superpowers:verification-before-completion** - Verify fix worked 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,"domain":42,"description":7},"foundational","main","cd89f013b617f7eea982a9bbc60e992974fda2aa","skills\u002Fsystematic-debugging",15,"https:\u002F\u002Fgithub.com\u002Fcoco-research\u002Fcoco","https:\u002F\u002Fcocoresearch.org\u002Fcoco\u002F","https:\u002F\u002Fgithub.com\u002Fcoco-research","https:\u002F\u002Fcocoresearch.org","Local-first, open-source tools for people who work with AI agents: governed memory, agents that check their own work, and data that stays on your machine.","2026-11-11 12:18:13",{"source":8,"skillName":5,"commands":54,"prompt":64,"zipAvailable":65},[55,58,61],{"tool":56,"command":57},"npx","npx skills add coco-research\u002Fcoco --skill systematic-debugging",{"tool":59,"command":60},"bunx","bunx skills add coco-research\u002Fcoco --skill systematic-debugging",{"tool":62,"command":63},"pnpm","pnpm dlx skills add coco-research\u002Fcoco --skill systematic-debugging","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fcoco-research\u002Fcoco\u002Fblob\u002Fmain\u002Fskills\u002Fsystematic-debugging\u002FSKILL.md",true,[67,73,79,83,87,91,95,99,103,107,111],{"path":68,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":71,"sourceHtmlUrl":72},"condition-based-waiting-example.ts","SCRIPT","脚本",5054,"https:\u002F\u002Fgithub.com\u002Fcoco-research\u002Fcoco\u002Fblob\u002Fmain\u002Fskills\u002Fsystematic-debugging\u002Fcondition-based-waiting-example.ts",{"path":74,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":77,"sourceHtmlUrl":78},"condition-based-waiting.md","REFERENCE","参考文档",3516,"https:\u002F\u002Fgithub.com\u002Fcoco-research\u002Fcoco\u002Fblob\u002Fmain\u002Fskills\u002Fsystematic-debugging\u002Fcondition-based-waiting.md",{"path":80,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":81,"sourceHtmlUrl":82},"CREATION-LOG.md",4268,"https:\u002F\u002Fgithub.com\u002Fcoco-research\u002Fcoco\u002Fblob\u002Fmain\u002Fskills\u002Fsystematic-debugging\u002FCREATION-LOG.md",{"path":84,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":85,"sourceHtmlUrl":86},"defense-in-depth.md",3650,"https:\u002F\u002Fgithub.com\u002Fcoco-research\u002Fcoco\u002Fblob\u002Fmain\u002Fskills\u002Fsystematic-debugging\u002Fdefense-in-depth.md",{"path":88,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":89,"sourceHtmlUrl":90},"find-polluter.sh",1528,"https:\u002F\u002Fgithub.com\u002Fcoco-research\u002Fcoco\u002Fblob\u002Fmain\u002Fskills\u002Fsystematic-debugging\u002Ffind-polluter.sh",{"path":92,"resourceType":92,"resourceTypeDesc":93,"sizeBytes":94,"sourceHtmlUrl":16},"LICENSE","许可证",1070,{"path":96,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":97,"sourceHtmlUrl":98},"root-cause-tracing.md",5327,"https:\u002F\u002Fgithub.com\u002Fcoco-research\u002Fcoco\u002Fblob\u002Fmain\u002Fskills\u002Fsystematic-debugging\u002Froot-cause-tracing.md",{"path":100,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":101,"sourceHtmlUrl":102},"test-academic.md",653,"https:\u002F\u002Fgithub.com\u002Fcoco-research\u002Fcoco\u002Fblob\u002Fmain\u002Fskills\u002Fsystematic-debugging\u002Ftest-academic.md",{"path":104,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":105,"sourceHtmlUrl":106},"test-pressure-1.md",1900,"https:\u002F\u002Fgithub.com\u002Fcoco-research\u002Fcoco\u002Fblob\u002Fmain\u002Fskills\u002Fsystematic-debugging\u002Ftest-pressure-1.md",{"path":108,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":109,"sourceHtmlUrl":110},"test-pressure-2.md",2283,"https:\u002F\u002Fgithub.com\u002Fcoco-research\u002Fcoco\u002Fblob\u002Fmain\u002Fskills\u002Fsystematic-debugging\u002Ftest-pressure-2.md",{"path":112,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":113,"sourceHtmlUrl":114},"test-pressure-3.md",2692,"https:\u002F\u002Fgithub.com\u002Fcoco-research\u002Fcoco\u002Fblob\u002Fmain\u002Fskills\u002Fsystematic-debugging\u002Ftest-pressure-3.md",[116,142,152,170,205,224],{"skillNo":117,"name":118,"nameZh":6,"description":119,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":120,"licenseFileUrl":6,"sourceHtmlUrl":121,"categories":122,"keywords":124,"publishedAt":37},"01M71KEJXF9KMT0BWCMRSRFA4M","trading-super-intelligence","Trading Super Intelligence Team. Named real-world personas across 8 cells. Built local-first (LM Studio) and validator-gated. Illustrative composites; see DISCLAIMER.md.","Apache-2.0","https:\u002F\u002Fgithub.com\u002Fcoco-research\u002Fcoco\u002Fblob\u002Fmain\u002Fsystems\u002Fsuperintelligence\u002Ftrading\u002FSKILL.md",[123],{"categoryNo":25,"categoryName":26,"taxonomyType":22,"taxonomyTypeDesc":23},[125,126,127,128,129,130,131,132,133,134,135,136,137,138,139,140,141],"super","trading super intelligence","intelligence","trading","validator","personas","local","composites","studio","team","across","world","first","gated","2026","lm studio","local-first",{"skillNo":143,"name":144,"nameZh":6,"description":145,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":120,"licenseFileUrl":6,"sourceHtmlUrl":146,"categories":147,"keywords":149,"publishedAt":37},"01M71KEFWS3CMAP7DF1P0FWTDE","strategy-super-intelligence","Strategy Super Intelligence Team. Named real-world personas across 7 cells. Built local-first (LM Studio) and validator-gated. Illustrative composites; see DISCLAIMER.md.","https:\u002F\u002Fgithub.com\u002Fcoco-research\u002Fcoco\u002Fblob\u002Fmain\u002Fsystems\u002Fsuperintelligence\u002Fstrategy\u002FSKILL.md",[148],{"categoryNo":25,"categoryName":26,"taxonomyType":22,"taxonomyTypeDesc":23},[150,125,151,127,129,130,131,132,133,134,135,136,137,138,139,140,141],"strategy","strategy super intelligence",{"skillNo":153,"name":154,"nameZh":6,"description":155,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":120,"licenseFileUrl":6,"sourceHtmlUrl":156,"categories":157,"keywords":164,"publishedAt":37},"01M71KED56ZEPK2QE84QSQPMT0","risk-compliance-super-intelligence","Risk & Compliance (GRC) Super Intelligence Team. Named real-world personas across 7 cells. Built local-first (LM Studio) and validator-gated. Illustrative composites; see DISCLAIMER.md.","https:\u002F\u002Fgithub.com\u002Fcoco-research\u002Fcoco\u002Fblob\u002Fmain\u002Fsystems\u002Fsuperintelligence\u002Frisk-compliance\u002FSKILL.md",[158,159],{"categoryNo":25,"categoryName":26,"taxonomyType":22,"taxonomyTypeDesc":23},{"categoryNo":160,"categoryName":161,"taxonomyType":162,"taxonomyTypeDesc":163},"01JBSEEDCAT000000000000037","律师与法务","PROFESSION","适用职业",[165,125,166,167,168,127,129,130,131,132,169,133,134,135,136,137,138,139,140,141],"risk","risk compliance super intelligence","compliance","risk compliance","grc",{"skillNo":171,"name":172,"nameZh":6,"description":173,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":120,"licenseFileUrl":6,"sourceHtmlUrl":174,"categories":175,"keywords":189,"publishedAt":37},"01M71KE9A2FWSC74VA96W1EZSN","product-design-super-intelligence","Your product + design brain trust and decision partner. Named personas across 8 cells spanning product strategy, discovery\u002Fresearch, growth\u002Fmetrics, design foundations\u002Fusability, design leadership\u002Fcraft, UX\u002Fcontent, design systems, and a…","https:\u002F\u002Fgithub.com\u002Fcoco-research\u002Fcoco\u002Fblob\u002Fmain\u002Fsystems\u002Fsuperintelligence\u002Fproduct-design\u002FSKILL.md",[176,179,182,183,186],{"categoryNo":177,"categoryName":178,"taxonomyType":22,"taxonomyTypeDesc":23},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":180,"categoryName":181,"taxonomyType":22,"taxonomyTypeDesc":23},"01JBSEEDCAT000000000000021","资料检索与研究",{"categoryNo":25,"categoryName":26,"taxonomyType":22,"taxonomyTypeDesc":23},{"categoryNo":184,"categoryName":185,"taxonomyType":162,"taxonomyTypeDesc":163},"01JBSEEDCAT000000000000031","产品经理",{"categoryNo":187,"categoryName":188,"taxonomyType":162,"taxonomyTypeDesc":163},"01JBSEEDCAT000000000000032","设计师",[190,191,127,192,125,193,194,195,196,197,198,134,135,199,200,139,201,202,203,204],"design","product","product design","product design super intelligence","foundations","product-design","decision","design systems","usability","leadership","ux","brain","craft","metrics","trust",{"skillNo":206,"name":207,"nameZh":6,"description":208,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":120,"licenseFileUrl":6,"sourceHtmlUrl":209,"categories":210,"keywords":213,"publishedAt":37},"01M71KE6H9FPSD9TECYFBPXZ8Y","legal-ip-super-intelligence","Your legal, IP, and regulatory brain trust. 31 named personas across 7 cells covering patent strategy, tech licensing, regulatory litigation, AI governance, open-source compliance, privacy law, and antitrust.","https:\u002F\u002Fgithub.com\u002Fcoco-research\u002Fcoco\u002Fblob\u002Fmain\u002Fsystems\u002Fsuperintelligence\u002Flegal-ip\u002FSKILL.md",[211,212],{"categoryNo":25,"categoryName":26,"taxonomyType":22,"taxonomyTypeDesc":23},{"categoryNo":160,"categoryName":161,"taxonomyType":162,"taxonomyTypeDesc":163},[214,125,215,127,216,217,204,218,130,219,220,221,150,134,135,222,167,223,139,201],"ip","legal ip super intelligence","legal","sep","tech","litigation","ai governance","open","open-source","governance",{"skillNo":225,"name":226,"nameZh":6,"description":227,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":120,"licenseFileUrl":6,"sourceHtmlUrl":228,"categories":229,"keywords":231,"publishedAt":37},"01M71KE36QRY610V6YVB9JWRND","healthcare-life-sciences-super-intelligence","Your healthcare and life sciences brain trust. 25 named personas across 7 cells covering drug discovery, medtech, biotech strategy, health policy, genomics, clinical trials, and healthcare economics.","https:\u002F\u002Fgithub.com\u002Fcoco-research\u002Fcoco\u002Fblob\u002Fmain\u002Fsystems\u002Fsuperintelligence\u002Fhealthcare-life-sciences\u002FSKILL.md",[230],{"categoryNo":25,"categoryName":26,"taxonomyType":22,"taxonomyTypeDesc":23},[232,125,233,234,127,217,204,235,236,130,237,238,150,134,135,239,240,241,242,139],"healthcare","healthcare life sciences super intelligence","life","economics","discovery","policy","clinical","clinical trials","health","trials","genomics"]