[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71NSPGTE0PY0YJ9HSDWB62B":3,"skill-same:01M71NSPGTE0PY0YJ9HSDWB62B":62},{"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":35,"linkOnly":36,"markdownContent":37,"markdownBody":38,"frontMatter":39,"refName":42,"commitSha":43,"skillDirectory":44,"forksCount":13,"repositoryHtmlUrl":45,"repositoryHomepageUrl":6,"ownerHtmlUrl":46,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":47,"install":48,"resources":61},"01M71NSPGTE0PY0YJ9HSDWB62B","triage-issue",null,"Use when the user reports a bug and wants it investigated and filed as a durable GitHub issue with a TDD-based fix plan.","max-kharena\u002Fnous","max-kharena","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F249811097?v=4","01M71NQQ2DRKPEV4AF9J318N31","01M71NQQ303XV5QX5DHCZKM41V",0,"MIT","https:\u002F\u002Fgithub.com\u002Fmax-kharena\u002Fnous\u002Fblob\u002Fmain\u002Fskills\u002Ftriage-issue\u002FSKILL.md",[],[18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34],"issue","triage","triage issue","user","it","bug","quality","github issue","tdd","github","plan","with","reports","when","use","fix","as","2026-11-10 10:56:23",false,"---\nname: triage-issue\ndescription: Use when the user reports a bug and wants it investigated and filed as a durable GitHub issue with a TDD-based fix plan.\nversion: 0.1.0\ntype: quality\nrisk: medium\n---\n\n# Triage Issue\n\nInvestigate a reported problem, find the 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## How this differs from `nous:debug`\n\n- `nous:debug` (`systematic-debugging`) is the live root-cause loop in this session.\n- `triage-issue` is the **artifact-producing** version: it ends with a durable, refactor-proof GitHub issue another agent (or human) can pick up later.\n\n## Workflow\n\n### 1. Capture the problem\n\nGet a brief description from the user. If they have not provided one, ask ONE question: \"What's the problem you're seeing?\"\n\nDo NOT ask follow-up questions. Start investigating immediately.\n\n### 2. Explore and diagnose\n\nUse a fresh `subagent` (or the host's exploration primitive) to deeply investigate the codebase. 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 the symptom)\n- **What** related code exists (similar patterns, tests, adjacent modules)\n\nLook at:\n\n- Related source files and their dependencies\n- Existing tests (what is tested, what is missing)\n- Recent changes to affected files (`git log` on relevant files)\n- Error handling in the code path\n- Similar patterns elsewhere that work correctly\n\n### 3. Identify the fix approach\n\n- The minimal change that fixes the root cause\n- Which modules \u002F interfaces are affected\n- What behaviors need to be verified by tests\n- Whether this is a regression, missing feature, or design flaw\n\n### 4. Design the 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 \u002F missing behavior\n- **GREEN** — describe the minimal code change that makes that test pass\n\nRules:\n\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 with `gh issue create`. Do NOT ask the user to review before creating — file it and share the URL.\n\n## Issue template\n\n```md\n## Problem\n\nClear description of the bug:\n- What happens (actual behavior)\n- What should happen (expected behavior)\n- How to reproduce (if applicable)\n\n## Root Cause Analysis\n\nWhat you found during investigation:\n- The code path involved\n- Why the current code fails\n- Any contributing factors\n\nDo NOT include file paths, line numbers, or implementation details that couple to current code layout. Describe modules, behaviors, and contracts. The issue should remain useful even after major refactors.\n\n## TDD Fix Plan\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\nAfter creating the issue, print the URL and a one-line summary of the root cause.\n\n## Rules\n\n- No file paths or line numbers in the issue body.\n- Use project domain language (`UBIQUITOUS_LANGUAGE.md` \u002F `CONTEXT.md` if present).\n- Reproduction steps mandatory for bugs.\n","# Triage Issue\n\nInvestigate a reported problem, find the 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## How this differs from `nous:debug`\n\n- `nous:debug` (`systematic-debugging`) is the live root-cause loop in this session.\n- `triage-issue` is the **artifact-producing** version: it ends with a durable, refactor-proof GitHub issue another agent (or human) can pick up later.\n\n## Workflow\n\n### 1. Capture the problem\n\nGet a brief description from the user. If they have not provided one, ask ONE question: \"What's the problem you're seeing?\"\n\nDo NOT ask follow-up questions. Start investigating immediately.\n\n### 2. Explore and diagnose\n\nUse a fresh `subagent` (or the host's exploration primitive) to deeply investigate the codebase. 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 the symptom)\n- **What** related code exists (similar patterns, tests, adjacent modules)\n\nLook at:\n\n- Related source files and their dependencies\n- Existing tests (what is tested, what is missing)\n- Recent changes to affected files (`git log` on relevant files)\n- Error handling in the code path\n- Similar patterns elsewhere that work correctly\n\n### 3. Identify the fix approach\n\n- The minimal change that fixes the root cause\n- Which modules \u002F interfaces are affected\n- What behaviors need to be verified by tests\n- Whether this is a regression, missing feature, or design flaw\n\n### 4. Design the 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 \u002F missing behavior\n- **GREEN** — describe the minimal code change that makes that test pass\n\nRules:\n\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 with `gh issue create`. Do NOT ask the user to review before creating — file it and share the URL.\n\n## Issue template\n\n```md\n## Problem\n\nClear description of the bug:\n- What happens (actual behavior)\n- What should happen (expected behavior)\n- How to reproduce (if applicable)\n\n## Root Cause Analysis\n\nWhat you found during investigation:\n- The code path involved\n- Why the current code fails\n- Any contributing factors\n\nDo NOT include file paths, line numbers, or implementation details that couple to current code layout. Describe modules, behaviors, and contracts. The issue should remain useful even after major refactors.\n\n## TDD Fix Plan\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\nAfter creating the issue, print the URL and a one-line summary of the root cause.\n\n## Rules\n\n- No file paths or line numbers in the issue body.\n- Use project domain language (`UBIQUITOUS_LANGUAGE.md` \u002F `CONTEXT.md` if present).\n- Reproduction steps mandatory for bugs.\n",{"name":5,"risk":40,"type":24,"version":41,"description":7},"medium","0.1.0","main","05ddbcce9e3471b880e9edc7c63e4bdd40359861","skills\u002Ftriage-issue","https:\u002F\u002Fgithub.com\u002Fmax-kharena\u002Fnous","https:\u002F\u002Fgithub.com\u002Fmax-kharena","2026-04-28 22:54:20",{"source":8,"skillName":5,"commands":49,"prompt":59,"zipAvailable":60},[50,53,56],{"tool":51,"command":52},"npx","npx skills add max-kharena\u002Fnous --skill triage-issue",{"tool":54,"command":55},"bunx","bunx skills add max-kharena\u002Fnous --skill triage-issue",{"tool":57,"command":58},"pnpm","pnpm dlx skills add max-kharena\u002Fnous --skill triage-issue","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmax-kharena\u002Fnous\u002Fblob\u002Fmain\u002Fskills\u002Ftriage-issue\u002FSKILL.md",true,[],[63,88,109,125,147,165],{"skillNo":64,"name":65,"nameZh":6,"description":66,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":67,"categories":68,"keywords":74,"publishedAt":35},"01M71NSZ170Z45TAP4CWY74YH3","write-a-skill","Create new agent skills with proper structure, progressive disclosure, and bundled resources. Use when the user wants to create, write, or build a new skill.","https:\u002F\u002Fgithub.com\u002Fmax-kharena\u002Fnous\u002Fblob\u002Fmain\u002Fskills\u002Fwrite-a-skill\u002FSKILL.md",[69],{"categoryNo":70,"categoryName":71,"taxonomyType":72,"taxonomyTypeDesc":73},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[75,76,77,78,79,80,81,29,21,82,83,84,85,32,31,86,87],"write a skill","write","a skill","create","structure","build","new skill","Meta","progressive","resources","new","new agent","progressive disclosure",{"skillNo":89,"name":90,"nameZh":6,"description":91,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":92,"categories":93,"keywords":99,"publishedAt":35},"01M71NSX1D1C2MK3NJ42E1GQ47","verification-before-completion","Use when about to claim work is complete, fixed, passing, ready, merged, shippable, reviewed, or verified.","https:\u002F\u002Fgithub.com\u002Fmax-kharena\u002Fnous\u002Fblob\u002Fmain\u002Fskills\u002Fverification-before-completion\u002FSKILL.md",[94],{"categoryNo":95,"categoryName":96,"taxonomyType":97,"taxonomyTypeDesc":98},"01JBSEEDCAT000000000000037","律师与法务","PROFESSION","适用职业",[100,101,102,103,31,32,104,105,24,106,107,108],"verification","verification before completion","ready","verified","claim","complete","about","high","work",{"skillNo":110,"name":111,"nameZh":6,"description":112,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":113,"categories":114,"keywords":115,"publishedAt":35},"01M71NSVRTWNA5RYBRRRBQ4830","using-nous","Use when a request needs NOUS command routing or personality-driven planning.","https:\u002F\u002Fgithub.com\u002Fmax-kharena\u002Fnous\u002Fblob\u002Fmain\u002Fskills\u002Fusing-nous\u002FSKILL.md",[],[116,117,118,31,32,119,120,121,122,123,124],"using nous","personality","driven","command routing","request","planning","command","routing","router",{"skillNo":126,"name":127,"nameZh":6,"description":128,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":129,"categories":130,"keywords":131,"publishedAt":35},"01M71NST398KW57VNX72Z35MC2","using-git-worktrees","Use when NOUS execution needs isolated implementation branches, phase worktrees, parallel worktrees, or safe branch setup before executing a plan.","https:\u002F\u002Fgithub.com\u002Fmax-kharena\u002Fnous\u002Fblob\u002Fmain\u002Fskills\u002Fusing-git-worktrees\u002FSKILL.md",[],[132,133,134,135,136,137,138,139,140,107,28,141,31,32,142,143,144,145,146],"git","worktrees","git worktrees","using git worktrees","Using git","execution","branch setup","implementation","safe","phase","parallel worktrees","setup","branches","branch","parallel",{"skillNo":148,"name":149,"nameZh":6,"description":150,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":151,"categories":152,"keywords":153,"publishedAt":35},"01M71NSRQ1VYJT15323W6HE1X1","ubiquitous-language","Use when the user wants to define domain terms, build a glossary, harden terminology, or extract a DDD-style ubiquitous language. Saves to UBIQUITOUS_LANGUAGE.md.","https:\u002F\u002Fgithub.com\u002Fmax-kharena\u002Fnous\u002Fblob\u002Fmain\u002Fskills\u002Fubiquitous-language\u002FSKILL.md",[],[154,155,156,157,80,158,159,160,32,21,161,162,163,31,164],"language","ubiquitous language","define","ddd","domain","style","terminology","extract","terms","harden","glossary",{"skillNo":166,"name":167,"nameZh":6,"description":168,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":169,"categories":170,"keywords":174,"publishedAt":35},"01M71NSN59ZV9BVTKYF8QZCZ7R","to-prd","Use when the user wants to turn the current conversation context into a PRD and submit it as a GitHub issue. No interview — synthesizes what has already been discussed.","https:\u002F\u002Fgithub.com\u002Fmax-kharena\u002Fnous\u002Fblob\u002Fmain\u002Fskills\u002Fto-prd\u002FSKILL.md",[171],{"categoryNo":172,"categoryName":173,"taxonomyType":97,"taxonomyTypeDesc":98},"01JBSEEDCAT000000000000031","产品经理",[175,176,31,177,21,22,32,18,25,178,121,27,34,179,180],"prd","to prd","context","submit","interview","conversation"]