[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71HKJB1VAM3JWDAPV3ECCBW":3,"skill-same:01M71HKJB1VAM3JWDAPV3ECCBW":67},{"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":18,"publishedAt":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":44,"commitSha":45,"skillDirectory":46,"forksCount":47,"repositoryHtmlUrl":48,"repositoryHomepageUrl":49,"ownerHtmlUrl":50,"ownerBlogUrl":51,"ownerDescription":6,"updatedAt":52,"install":53,"resources":66},"01M71HKJB1VAM3JWDAPV3ECCBW","investigate-bug",null,"Investigate a bug or issue by exploring the codebase to find root cause, then write a TDD-based fix plan to specs\u002Fbugs\u002FBUG-*.md. Use when user reports a bug, wants to investigate a problem, mentions \"triage\", or wants to plan a fix.","danielvm-git\u002Fbigpowers","danielvm-git","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F1020864?v=4","01M71H1N1CTQ529S0KN7KETVG6","Daniel V M","01M71H1N218Y3S8WHCJ58NPRSW",289,"MIT","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002F.codex\u002Fskills\u002Finvestigate-bug\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"bug","investigate","investigate bug","root","triage","codebase","find","tdd","to plan","use","root cause","bugs","sonnet","issue","write","plan","reports","when","fix","problem","2026-11-10 10:12:30",false,"---\nname: investigate-bug\nmodel: sonnet\ndescription: \"Investigate a bug or issue by exploring the codebase to find root cause, then write a TDD-based fix plan to specs\u002Fbugs\u002FBUG-*.md. Use when user reports a bug, wants to investigate a problem, mentions \\\"triage\\\", or wants to plan a fix.\"\n---\n\n# Investigate Bug\n\n**Boundary**: End-to-end bug entry point — history check → RCA (via `diagnose-root`) → fix approach → TDD plan → bug file. Delegates the 4-phase RCA to `diagnose-root`; does not re-implement it.\n\nInvestigate a reported problem, find its root cause, and write a TDD fix plan to `specs\u002Fbugs\u002FBUG-*.md`. This is a mostly hands-off workflow — minimize questions to the user.\n\n## Process\n\n### 0. Read previous bug history\n\nBefore starting diagnosis:\n\n1. Read `specs\u002Fbugs\u002Fregistry.yaml` (if it exists) — check for prior bugs in the same `scope` or with similar symptoms.\n2. If a relevant prior bug is found, read the corresponding `specs\u002Fbugs\u002FBUG-*.md` file to understand previous root cause analysis and fix approach.\n3. Note in your investigation whether this is a recurrence, a related issue, or novel.\n\n### 1. Capture the problem\n\nGet a brief description of the issue from the user. If they haven't provided one, ask ONE question: \"What's the problem you're seeing?\"\n\nDo NOT ask follow-up questions yet. Start investigating immediately.\n\n> **Security-impact assessment** — After capturing the problem, assess and document: `Security impact: NONE \u002F LOW \u002F MEDIUM \u002F HIGH \u002F CRITICAL`. If HIGH or CRITICAL, assign bug severity HIGH and document the exploit path in findings. If MEDIUM+, include exploit path in the bug file. Document \"no security exploit path identified\" for NONE\u002FLOW.\n\n### 2. Explore and diagnose (4-phase RCA)\n\nRun the 4-phase root-cause analysis via the `diagnose-root` skill (Reproduce → Isolate → Hypothesize → Verify). That skill is the canonical RCA engine — do not re-implement the phases here.\n\nAlso look at:\n- Recent changes to affected files (`git log --oneline \u003Cfile>`)\n- Existing tests (what's tested, what's missing)\n- Similar patterns elsewhere in the codebase that work correctly\n\n> **HARD GATE** — Do NOT proceed to Step 3 (Fix Approach) until `diagnose-root` Phase 4 produces a verified root cause. \"It probably is X\" is not verified.\n\n### 3. Identify the fix approach\n\nBased on your investigation, determine:\n\n- The minimal change needed to fix the root cause\n- Which modules\u002Finterfaces are affected\n- What behaviors need to be verified via tests\n- Whether this is a regression, missing feature, or design flaw\n- Risk level: Low \u002F Medium \u002F High\n\n### 4. Design TDD fix plan\n\nCreate a concrete, ordered list of RED-GREEN cycles. Each cycle is one vertical slice:\n\n- **RED**: Describe a specific test that captures the broken\u002Fmissing behavior\n- **GREEN**: Describe the minimal code change to make that test pass\n\nRules:\n- Tests verify behavior through public interfaces, not implementation details\n- One test at a time, vertical slices (NOT all tests first, then all code)\n- Each test should survive internal refactors\n- Include a final refactor step if needed\n- **Durability**: Only suggest fixes that would survive radical codebase changes. Tests assert on observable outcomes (API responses, UI state, user-visible effects), not internal state.\n\n### 5. Write the bug file\n\nSave the investigation and fix plan to `specs\u002Fbugs\u002FBUG-NNN-slug.md`. Create the `specs\u002Fbugs\u002F` directory if it doesn't exist.\n\nAfter writing, append a row to `specs\u002Fbugs\u002Fregistry.yaml` with: bug_id (same timestamp), date, severity, priority, scope, summary, and file path. Create `specs\u002Fbugs\u002Fregistry.yaml` if it doesn't exist.\n\n\u003Cdiagnosis-template>\n\n# BUG-YYYY-MM-DDTHHMMSS: [short title]\n\n## Problem\n\nA clear description of the bug or issue, including:\n- What happens (actual behavior)\n- What should happen (expected behavior)\n- How to reproduce (if applicable)\n\n## Root Cause Analysis\n\nDescribe what you found during investigation:\n- The code path involved\n- Why the current code fails\n- Any contributing factors\n- Risk level: Low \u002F Medium \u002F High\n\nDo NOT include specific file paths, line numbers, or implementation details that couple to current code layout. Describe modules, behaviors, and contracts instead.\n\n## TDD Fix Plan\n\nA numbered list of RED-GREEN cycles:\n\n1. **RED**: Write a test that [describes expected behavior]\n   **GREEN**: [Minimal change to make it pass]\n   **verify**: [runnable command]\n\n2. **RED**: Write a test that [describes next behavior]\n   **GREEN**: [Minimal change to make it pass]\n   **verify**: [runnable command]\n\n**REFACTOR**: [Any cleanup needed after all tests pass]\n\n## Acceptance Criteria\n\n- [ ] Criterion 1\n- [ ] Criterion 2\n- [ ] All new tests pass\n- [ ] Existing tests still pass\n\n## Resolution\n\n\u003C!-- filled in by validate-fix -->\n\n\u003C\u002Fdiagnosis-template>\n\nAfter writing the bug file, print a one-line summary of the root cause and suggest running `kickoff-branch` next to create a fix branch.\n\n## References\n\n\u003C!-- story: e35s10 -->\n\n- [Feathers' Seams & Characterization Tests](..\u002F..\u002Fdocs\u002Freferences\u002Ffeathers.md) — seam types, characterization tests, and the legacy code change algorithm\n- [Fowler's Code Smells](..\u002F..\u002Fdocs\u002Freferences\u002Ffowler.md) — identifying structural problems by smell before investigating\n","# Investigate Bug\n\n**Boundary**: End-to-end bug entry point — history check → RCA (via `diagnose-root`) → fix approach → TDD plan → bug file. Delegates the 4-phase RCA to `diagnose-root`; does not re-implement it.\n\nInvestigate a reported problem, find its root cause, and write a TDD fix plan to `specs\u002Fbugs\u002FBUG-*.md`. This is a mostly hands-off workflow — minimize questions to the user.\n\n## Process\n\n### 0. Read previous bug history\n\nBefore starting diagnosis:\n\n1. Read `specs\u002Fbugs\u002Fregistry.yaml` (if it exists) — check for prior bugs in the same `scope` or with similar symptoms.\n2. If a relevant prior bug is found, read the corresponding `specs\u002Fbugs\u002FBUG-*.md` file to understand previous root cause analysis and fix approach.\n3. Note in your investigation whether this is a recurrence, a related issue, or novel.\n\n### 1. Capture the problem\n\nGet a brief description of the issue from the user. If they haven't provided one, ask ONE question: \"What's the problem you're seeing?\"\n\nDo NOT ask follow-up questions yet. Start investigating immediately.\n\n> **Security-impact assessment** — After capturing the problem, assess and document: `Security impact: NONE \u002F LOW \u002F MEDIUM \u002F HIGH \u002F CRITICAL`. If HIGH or CRITICAL, assign bug severity HIGH and document the exploit path in findings. If MEDIUM+, include exploit path in the bug file. Document \"no security exploit path identified\" for NONE\u002FLOW.\n\n### 2. Explore and diagnose (4-phase RCA)\n\nRun the 4-phase root-cause analysis via the `diagnose-root` skill (Reproduce → Isolate → Hypothesize → Verify). That skill is the canonical RCA engine — do not re-implement the phases here.\n\nAlso look at:\n- Recent changes to affected files (`git log --oneline \u003Cfile>`)\n- Existing tests (what's tested, what's missing)\n- Similar patterns elsewhere in the codebase that work correctly\n\n> **HARD GATE** — Do NOT proceed to Step 3 (Fix Approach) until `diagnose-root` Phase 4 produces a verified root cause. \"It probably is X\" is not verified.\n\n### 3. Identify the fix approach\n\nBased on your investigation, determine:\n\n- The minimal change needed to fix the root cause\n- Which modules\u002Finterfaces are affected\n- What behaviors need to be verified via tests\n- Whether this is a regression, missing feature, or design flaw\n- Risk level: Low \u002F Medium \u002F High\n\n### 4. Design TDD fix plan\n\nCreate a concrete, ordered list of RED-GREEN cycles. Each cycle is one vertical slice:\n\n- **RED**: Describe a specific test that captures the broken\u002Fmissing behavior\n- **GREEN**: Describe the minimal code change to make that test pass\n\nRules:\n- Tests verify behavior through public interfaces, not implementation details\n- One test at a time, vertical slices (NOT all tests first, then all code)\n- Each test should survive internal refactors\n- Include a final refactor step if needed\n- **Durability**: Only suggest fixes that would survive radical codebase changes. Tests assert on observable outcomes (API responses, UI state, user-visible effects), not internal state.\n\n### 5. Write the bug file\n\nSave the investigation and fix plan to `specs\u002Fbugs\u002FBUG-NNN-slug.md`. Create the `specs\u002Fbugs\u002F` directory if it doesn't exist.\n\nAfter writing, append a row to `specs\u002Fbugs\u002Fregistry.yaml` with: bug_id (same timestamp), date, severity, priority, scope, summary, and file path. Create `specs\u002Fbugs\u002Fregistry.yaml` if it doesn't exist.\n\n\u003Cdiagnosis-template>\n\n# BUG-YYYY-MM-DDTHHMMSS: [short title]\n\n## Problem\n\nA clear description of the bug or issue, including:\n- What happens (actual behavior)\n- What should happen (expected behavior)\n- How to reproduce (if applicable)\n\n## Root Cause Analysis\n\nDescribe what you found during investigation:\n- The code path involved\n- Why the current code fails\n- Any contributing factors\n- Risk level: Low \u002F Medium \u002F High\n\nDo NOT include specific file paths, line numbers, or implementation details that couple to current code layout. Describe modules, behaviors, and contracts instead.\n\n## TDD Fix Plan\n\nA numbered list of RED-GREEN cycles:\n\n1. **RED**: Write a test that [describes expected behavior]\n   **GREEN**: [Minimal change to make it pass]\n   **verify**: [runnable command]\n\n2. **RED**: Write a test that [describes next behavior]\n   **GREEN**: [Minimal change to make it pass]\n   **verify**: [runnable command]\n\n**REFACTOR**: [Any cleanup needed after all tests pass]\n\n## Acceptance Criteria\n\n- [ ] Criterion 1\n- [ ] Criterion 2\n- [ ] All new tests pass\n- [ ] Existing tests still pass\n\n## Resolution\n\n\u003C!-- filled in by validate-fix -->\n\n\u003C\u002Fdiagnosis-template>\n\nAfter writing the bug file, print a one-line summary of the root cause and suggest running `kickoff-branch` next to create a fix branch.\n\n## References\n\n\u003C!-- story: e35s10 -->\n\n- [Feathers' Seams & Characterization Tests](..\u002F..\u002Fdocs\u002Freferences\u002Ffeathers.md) — seam types, characterization tests, and the legacy code change algorithm\n- [Fowler's Code Smells](..\u002F..\u002Fdocs\u002Freferences\u002Ffowler.md) — identifying structural problems by smell before investigating\n",{"name":5,"model":31,"description":7},"main","72f5e4c8b43f60cf86b37078ad8cd7e22daf67aa",".codex\u002Fskills\u002Finvestigate-bug",24,"https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers","https:\u002F\u002Fdanielvm-git.github.io\u002Fbigpowers\u002F","https:\u002F\u002Fgithub.com\u002Fdanielvm-git","danielvm.net","2026-11-10 01:18:54",{"source":8,"skillName":5,"commands":54,"prompt":64,"zipAvailable":65},[55,58,61],{"tool":56,"command":57},"npx","npx skills add danielvm-git\u002Fbigpowers --skill investigate-bug",{"tool":59,"command":60},"bunx","bunx skills add danielvm-git\u002Fbigpowers --skill investigate-bug",{"tool":62,"command":63},"pnpm","pnpm dlx skills add danielvm-git\u002Fbigpowers --skill investigate-bug","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002F.codex\u002Fskills\u002Finvestigate-bug\u002FSKILL.md",true,[],[68,89,96,122,145,166],{"skillNo":69,"name":70,"nameZh":6,"description":71,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":72,"categories":73,"keywords":79,"publishedAt":39},"01M71KBG9F8X644MJB16H4V8M7","skill-verify-fail-open-fixture","Negative-path fixture for run-skill-verify.sh — must never PASS.","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fspecs\u002Fverifications\u002Ffixtures\u002Fskill-verify-fail-open\u002FSKILL.md",[74],{"categoryNo":75,"categoryName":76,"taxonomyType":77,"taxonomyTypeDesc":78},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[80,81,82,83,84,85,86,87,88],"fixture","open","verify","skill verify fail open fixture","skill verify","path","run","for","never",{"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":39},"01M71KBE3BKEMKNE0C5DGVDWZH","negative-path","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fspecs\u002Fverifications\u002Ffixtures\u002Fnegative-path\u002FSKILL.md",[],[95,85],"negative path",{"skillNo":97,"name":98,"nameZh":6,"description":99,"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":105,"publishedAt":39},"01M71KBBGF7Y4EB4AMHBZ8CJFC","write-document","Write, organize, and sync high-integrity technical documents using the BMAD methodology. Ensures every document is Bold, Minimal, Actionable, and Durable. Use when creating architectural docs, technical guides, or organizing the specs\u002F directory.","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fskills\u002Fwrite-document\u002FSKILL.md",[102],{"categoryNo":103,"categoryName":104,"taxonomyType":77,"taxonomyTypeDesc":78},"01JBSEEDCAT000000000000002","文档处理",[33,106,107,108,109,110,111,112,113,114,28,36,115,116,31,117,118,119,120,121],"write document","document","documents","actionable","technical","methodology","high","bmad","standard","minimal","bold","integrity","organize","sync","directory","guides",{"skillNo":123,"name":124,"nameZh":6,"description":125,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":126,"categories":127,"keywords":128,"publishedAt":39},"01M71KB8TM089JJD5AY5KAFSDM","wire-observability","Add structured JSON logging, observability commands, and idempotent setup scripts to a project. Use when a project needs production-readiness instrumentation, when user wants structured logging, or as a production-readiness gate at any phase of development.","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fskills\u002Fwire-observability\u002FSKILL.md",[],[129,130,131,114,132,28,133,134,135,136,31,137,138,139,140,141,142,36,143,144],"observability","wire observability","readiness","commands","development","as","logging","add","instrumentation","at","structured logging","production-readiness","idempotent","phase","project","scripts",{"skillNo":146,"name":147,"nameZh":6,"description":148,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":149,"categories":150,"keywords":151,"publishedAt":39},"01M71KB6CNRANP449DQA3NJZ96","wire-ci","CI pipeline setup with bundled, forge-neutral templates and local validation. Detects the forge from the git remote, generates workflows for supported forges, and skips honestly for the rest. The CI equivalent of wire-observability.","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fskills\u002Fwire-ci\u002FSKILL.md",[],[152,153,154,155,156,157,158,159,160,161,162,114,163,87,129,31,164,165],"wire ci","ci","remote","local","pipeline","forge","validation","setup","templates","REST","with","ci pipeline setup","git","workflows",{"skillNo":167,"name":168,"nameZh":6,"description":169,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":170,"categories":171,"keywords":183,"publishedAt":39},"01M71KB2ZV98P03X88QR8MT9F1","visual-dashboard","Start a browser-based dashboard that visualizes architecture, implementation plans, and project status. Persists artifacts in .bigpowers\u002Fdashboard\u002F. Reads specs\u002Fstate.yaml, release-plan.yaml, epics, and planning-status via HTTP API or opencode panel.","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fskills\u002Fvisual-dashboard\u002FSKILL.md",[172,175,180],{"categoryNo":173,"categoryName":174,"taxonomyType":77,"taxonomyTypeDesc":78},"01JBSEEDCAT000000000000013","分析与可视化",{"categoryNo":176,"categoryName":177,"taxonomyType":178,"taxonomyTypeDesc":179},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",{"categoryNo":181,"categoryName":182,"taxonomyType":178,"taxonomyTypeDesc":179},"01JBSEEDCAT000000000000033","数据分析师",[184,185,186,187,188,189,190,191,192,31,193,194,195,34,196,197,198,143,199,200],"dashboard","visual","visual dashboard","status","artifacts","http","plans","planning","panel","start","release","opencode","browser","api","architecture","project status","http api"]