[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6H86AFNF0JT6D4YDP3Z6RHD":3,"skill-same:01M6H86AFNF0JT6D4YDP3Z6RHD":68},{"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":41,"linkOnly":42,"markdownContent":43,"markdownBody":44,"frontMatter":45,"refName":46,"commitSha":47,"skillDirectory":48,"forksCount":14,"repositoryHtmlUrl":49,"repositoryHomepageUrl":6,"ownerHtmlUrl":50,"ownerBlogUrl":51,"ownerDescription":52,"updatedAt":53,"install":54,"resources":67},"01M6H86AFNF0JT6D4YDP3Z6RHD","triage-issue",null,"Triage a bug or issue by exploring the codebase to find root cause, then create a GitHub issue with a TDD-based fix plan. Use when user reports a bug, wants to file an issue, mentions \"triage\", or wants to investigate and plan a fix for a problem.","O-Marsters-1997\u002Fmy-claude-code","O-Marsters-1997","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F72571979?v=4","01M6H800V7V9BSXYZKDM0JXTJ2","Olly Marsters","01M6H800ZYDJR42TNRH0E6ZVZ7",0,"MIT","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fproduct\u002Ftriage-issue\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40],"triage","triage issue","issue","bug","when","root cause","codebase","for","root","with","problem","reports","github","github issue","use","fix","find","plan","investigate","file","create","tdd","2026-11-10 10:12:30",false,"---\nname: triage-issue\ndescription: Triage a bug or issue by exploring the codebase to find root cause, then create a GitHub issue with a TDD-based fix plan. Use when user reports a bug, wants to file an issue, mentions \"triage\", or wants to investigate and plan a fix for a problem.\n---\n\n# Triage Issue\n\nInvestigate a reported problem, find its root cause, and create a GitHub issue with a TDD fix plan. This is a mostly hands-off workflow - minimize questions to the user.\n\n## Process\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### 2. Explore and diagnose\n\nUse the Agent tool with subagent_type=Explore to deeply investigate the codebase. Your goal is to find:\n\n- **Where** the bug manifests (entry points, UI, API responses)\n- **What** code path is involved (trace the flow)\n- **Why** it fails (the root cause, not just the symptom)\n- **What** related code exists (similar patterns, tests, adjacent modules)\n\nLook at:\n- Related source files and their dependencies\n- Existing tests (what's tested, what's missing)\n- Recent changes to affected files (`git log` on relevant files)\n- Error handling in the code path\n- Similar patterns elsewhere in the codebase that work correctly\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\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. Describe behaviors and contracts, not internal structure. Tests assert on observable outcomes (API responses, UI state, user-visible effects), not internal state. A good suggestion reads like a spec; a bad one reads like a diff.\n\n### 5. Create the GitHub issue\n\nCreate a GitHub issue using `gh issue create` with the template below. Do NOT ask the user to review before creating - just create it and share the URL.\n\n\u003Cissue-template>\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\nDo NOT include specific file paths, line numbers, or implementation details that couple to current code layout. Describe modules, behaviors, and contracts instead. The issue should remain useful even after major refactors.\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\n2. **RED**: Write a test that [describes next behavior]\n   **GREEN**: [Minimal change to make it pass]\n\n...\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\u003C\u002Fissue-template>\n\nAfter creating the issue, print the issue URL and a one-line summary of the root cause.\n","# Triage Issue\n\nInvestigate a reported problem, find its root cause, and create a GitHub issue with a TDD fix plan. This is a mostly hands-off workflow - minimize questions to the user.\n\n## Process\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### 2. Explore and diagnose\n\nUse the Agent tool with subagent_type=Explore to deeply investigate the codebase. Your goal is to find:\n\n- **Where** the bug manifests (entry points, UI, API responses)\n- **What** code path is involved (trace the flow)\n- **Why** it fails (the root cause, not just the symptom)\n- **What** related code exists (similar patterns, tests, adjacent modules)\n\nLook at:\n- Related source files and their dependencies\n- Existing tests (what's tested, what's missing)\n- Recent changes to affected files (`git log` on relevant files)\n- Error handling in the code path\n- Similar patterns elsewhere in the codebase that work correctly\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\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. Describe behaviors and contracts, not internal structure. Tests assert on observable outcomes (API responses, UI state, user-visible effects), not internal state. A good suggestion reads like a spec; a bad one reads like a diff.\n\n### 5. Create the GitHub issue\n\nCreate a GitHub issue using `gh issue create` with the template below. Do NOT ask the user to review before creating - just create it and share the URL.\n\n\u003Cissue-template>\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\nDo NOT include specific file paths, line numbers, or implementation details that couple to current code layout. Describe modules, behaviors, and contracts instead. The issue should remain useful even after major refactors.\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\n2. **RED**: Write a test that [describes next behavior]\n   **GREEN**: [Minimal change to make it pass]\n\n...\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\u003C\u002Fissue-template>\n\nAfter creating the issue, print the issue URL and a one-line summary of the root cause.\n",{"name":5,"description":7},"main","aede9f7bc29a2d9127fa7ce29682c242596c7759","skills\u002Fproduct\u002Ftriage-issue","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997","https:\u002F\u002Fpersonal-portfolio-v2-phi.vercel.app","Go & TypeScript developer building tooling for AI-assisted development: git worktree workflows, Claude Code skills and agent orchestration.","2026-11-11 22:26:34",{"source":8,"skillName":5,"commands":55,"prompt":65,"zipAvailable":66},[56,59,62],{"tool":57,"command":58},"npx","npx skills add O-Marsters-1997\u002Fmy-claude-code --skill triage-issue",{"tool":60,"command":61},"bunx","bunx skills add O-Marsters-1997\u002Fmy-claude-code --skill triage-issue",{"tool":63,"command":64},"pnpm","pnpm dlx skills add O-Marsters-1997\u002Fmy-claude-code --skill triage-issue","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fproduct\u002Ftriage-issue\u002FSKILL.md",true,[],[69,77,84,109,136,163],{"skillNo":70,"name":71,"nameZh":6,"description":72,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":73,"categories":74,"keywords":75,"publishedAt":76},"01M745F5J4Z2W32G4QXESCN5PM","vault-recall","Answer the user's conceptual or technical question using their Obsidian vault as well as general knowledge. Use when the user asks a question (not a task) whose topic appears in the vault MOC digest from session start. Not for task instructions, not mid-task, and not for writing to the vault (that is to-vault).","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fproductivity\u002Fvault-recall\u002FSKILL.md",[],[],"2026-11-11 15:11:14",{"skillNo":78,"name":79,"nameZh":6,"description":80,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":81,"categories":82,"keywords":83,"publishedAt":76},"01M745EW5W0A7K9016Z54A4KG2","ingest","Ingest one external source (an article, course lesson, doc, PDF or URL) into the user's Obsidian vault: save the original to raw\u002F, then build wiki\u002F pages per the vault's § Ingest. Use when the user types \u002Fingest, or says \"ingest this\", \"add this source to my wiki\", \"put this article\u002Flesson in the vault as a wiki page\". Works from any repo. Routing rule: someone else's words go to wiki\u002F (this skill); the user's own learnings and decisions go to notes\u002F (\u002Fto-vault).","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fproductivity\u002Fingest\u002FSKILL.md",[],[],{"skillNo":85,"name":86,"nameZh":6,"description":87,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":88,"categories":89,"keywords":90,"publishedAt":41},"01M6H88J6TYRV9T8RKWW569YM8","to-tickets","Breaks a source into independently-grabbable GitHub tickets. For a code feature the source is the plan (`docs\u002Fplans\u002F\u003Cfeature>.md`, from \u002Fto-plan) and every new or changed symbol lands in exactly one ticket, its signatures copied into the ticket body; a non-code feature is cut from the PRD's slices. Cuts tickets for one feature per run. If a code feature has no approved plan, offers \u002Fto-plan instead of cutting from prose. In a repo that runs command-centre, also emits `[[task]]` blocks into its config; in a plain treepad repo, emits a Batch Manifest instead so the tickets materialise as stacked worktrees.","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fto-tickets\u002FSKILL.md",[],[91,92,93,94,31,36,95,96,97,98,99,100,101,102,103,26,104,105,106,107,108],"tickets","to tickets","new","signatures","batch","task","code","manifest","plans","true","ticket","command","repo","feature","run","worktrees","as","cut",{"skillNo":110,"name":111,"nameZh":6,"description":112,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":113,"categories":114,"keywords":120,"publishedAt":41},"01M6H88E98X9KGGYBGSVDS1E8H","to-seams","Records an agreed-but-unlanded cross-repo interface as a seam: the file a consumer's agent gets pasted into its prompt as ground truth, plus the `[[seam]]` block command-centre reads for the retirement pointer. Use when two repos need to build against an interface neither has landed yet — \"record a seam for X\", \"we agreed on this schema, seam it\", \"add a seam so Y can build against Z's new field\". Halts for approval before writing either file.","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fto-seams\u002FSKILL.md",[115],{"categoryNo":116,"categoryName":117,"taxonomyType":118,"taxonomyTypeDesc":119},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[121,122,93,123,124,125,38,126,127,33,128,23,129,100,130,131,132,103,26,133,134,135,107,102],"to seams","schema","neither","it","but","prompt","either","writing","interface","repos","block","records","build","can","record",{"skillNo":137,"name":138,"nameZh":6,"description":139,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":140,"categories":141,"keywords":147,"publishedAt":41},"01M6H889PSQM2E1ATS2JC10QRV","to-roadmap","Prioritises settled features into a Now \u002F Next \u002F Later kanban board, rendered as a self-contained .\u002Fideas\u002Froadmap.html. Each card is a feature, not a ticket — one card later becomes several tickets via \u002Fto-prd -> \u002Fto-plan -> \u002Fto-tickets. Boards the features in .\u002Fdocs\u002Fapproach.md, or the \"## Accepted ideas\" in .\u002Fideas\u002FCONTEXT.md when there is no approach doc. The approach doc is settled truth: this assigns tiers and reasons about ordering, it never re-litigates what was decided.","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fto-roadmap\u002FSKILL.md",[142],{"categoryNo":143,"categoryName":144,"taxonomyType":145,"taxonomyTypeDesc":146},"01JBSEEDCAT000000000000031","产品经理","PROFESSION","适用职业",[148,149,150,107,104,151,152,23,153,154,155,91,156,157,36,158,159,100,101,160,161,162],"to roadmap","roadmap","never","via","features","doc","board","about","next","later","self","now","card","re","ideas",{"skillNo":164,"name":165,"nameZh":6,"description":166,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":167,"categories":168,"keywords":170,"publishedAt":41},"01M6H885QAK839Q771ZBKBK1KA","to-prd","Turns one feature idea into a PRD built on journeys: a one-line problem, journeys (each ending in an observable state) and delivery slices that say what is usable after each. Interviews, explores the codebase, and saves to docs\u002Fprds\u002F\u003Cfeature>.md. Covers exactly one feature: given a multi-feature source, ask which one. Reads any approach doc or ideate report as priors so it doesn't re-ask what's settled, but needs none. Starts the per-feature spine (\u002Fto-prd -> \u002Fto-plan -> \u002Fto-tickets).","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fto-prd\u002FSKILL.md",[169],{"categoryNo":143,"categoryName":144,"taxonomyType":145,"taxonomyTypeDesc":146},[171,172,173,174,25,175,176,177,91,178,36,179,180,181,100,161,104,29,182,107],"prd","to prd","say","interviews","report","line","delivery","spine","state","multi","ask","which"]