[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6MN44D6K3QDAMABDRTB2D0P":3,"skill-same:01M6MN44D6K3QDAMABDRTB2D0P":64},{"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":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":43,"commitSha":44,"skillDirectory":45,"forksCount":46,"repositoryHtmlUrl":47,"repositoryHomepageUrl":6,"ownerHtmlUrl":48,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":49,"install":50,"resources":63},"01M6MN44D6K3QDAMABDRTB2D0P","qa",null,"Interactive QA session where user reports bugs or issues conversationally, and the agent files GitHub issues. Explores the codebase in the background for context and domain language. Use when user wants to report bugs, do QA, file issues conversationally, or mentions \"QA session\".","arkhe-genesis\u002FArkhe-OS","arkhe-genesis","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F272629719?v=4","01M6KJDTSTJD2AD5RFPVZNGYCP","Rafael Oliveira","01M6KJDTXSTA997KDK184EA55A",2,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Farkhe-genesis\u002FArkhe-OS\u002Fblob\u002Fmain\u002Fcomponents\u002Fskills\u002Fqa\u002FSKILL.md",[],[5,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"use","background","codebase","bugs","for","domain","do","language","files","reports","github","session","user","interactive","context","file","issues","report","github issues","2026-11-10 10:12:30",false,"---\nname: qa\ndescription: Interactive QA session where user reports bugs or issues conversationally, and the agent files GitHub issues. Explores the codebase in the background for context and domain language. Use when user wants to report bugs, do QA, file issues conversationally, or mentions \"QA session\".\n---\n\n# QA Session\n\nRun an interactive QA session. The user describes problems they're encountering. You clarify, explore the codebase for context, and file GitHub issues that are durable, user-focused, and use the project's domain language.\n\n## For each issue the user raises\n\n### 1. Listen and lightly clarify\n\nLet the user describe the problem in their own words. Ask **at most 2-3 short clarifying questions** focused on:\n\n- What they expected vs what actually happened\n- Steps to reproduce (if not obvious)\n- Whether it's consistent or intermittent\n\nDo NOT over-interview. If the description is clear enough to file, move on.\n\n### 2. Explore the codebase in the background\n\nWhile talking to the user, kick off an Agent (subagent_type=Explore) in the background to understand the relevant area. The goal is NOT to find a fix — it's to:\n\n- Learn the domain language used in that area (check UBIQUITOUS_LANGUAGE.md)\n- Understand what the feature is supposed to do\n- Identify the user-facing behavior boundary\n\nThis context helps you write a better issue — but the issue itself should NOT reference specific files, line numbers, or internal implementation details.\n\n### 3. Assess scope: single issue or breakdown?\n\nBefore filing, decide whether this is a **single issue** or needs to be **broken down** into multiple issues.\n\nBreak down when:\n\n- The fix spans multiple independent areas (e.g. \"the form validation is wrong AND the success message is missing AND the redirect is broken\")\n- There are clearly separable concerns that different people could work on in parallel\n- The user describes something that has multiple distinct failure modes or symptoms\n\nKeep as a single issue when:\n\n- It's one behavior that's wrong in one place\n- The symptoms are all caused by the same root behavior\n\n### 4. File the GitHub issue(s)\n\nCreate issues with `gh issue create`. Do NOT ask the user to review first — just file and share URLs.\n\nIssues must be **durable** — they should still make sense after major refactors. Write from the user's perspective.\n\n#### For a single issue\n\nUse this template:\n\n```\n## What happened\n\n[Describe the actual behavior the user experienced, in plain language]\n\n## What I expected\n\n[Describe the expected behavior]\n\n## Steps to reproduce\n\n1. [Concrete, numbered steps a developer can follow]\n2. [Use domain terms from the codebase, not internal module names]\n3. [Include relevant inputs, flags, or configuration]\n\n## Additional context\n\n[Any extra observations from the user or from codebase exploration that help frame the issue — e.g. \"this only happens when using the Docker layer, not the filesystem layer\" — use domain language but don't cite files]\n```\n\n#### For a breakdown (multiple issues)\n\nCreate issues in dependency order (blockers first) so you can reference real issue numbers.\n\nUse this template for each sub-issue:\n\n```\n## Parent issue\n\n#\u003Cparent-issue-number> (if you created a tracking issue) or \"Reported during QA session\"\n\n## What's wrong\n\n[Describe this specific behavior problem — just this slice, not the whole report]\n\n## What I expected\n\n[Expected behavior for this specific slice]\n\n## Steps to reproduce\n\n1. [Steps specific to THIS issue]\n\n## Blocked by\n\n- #\u003Cissue-number> (if this issue can't be fixed until another is resolved)\n\nOr \"None — can start immediately\" if no blockers.\n\n## Additional context\n\n[Any extra observations relevant to this slice]\n```\n\nWhen creating a breakdown:\n\n- **Prefer many thin issues over few thick ones** — each should be independently fixable and verifiable\n- **Mark blocking relationships honestly** — if issue B genuinely can't be tested until issue A is fixed, say so. If they're independent, mark both as \"None — can start immediately\"\n- **Create issues in dependency order** so you can reference real issue numbers in \"Blocked by\"\n- **Maximize parallelism** — the goal is that multiple people (or agents) can grab different issues simultaneously\n\n#### Rules for all issue bodies\n\n- **No file paths or line numbers** — these go stale\n- **Use the project's domain language** (check UBIQUITOUS_LANGUAGE.md if it exists)\n- **Describe behaviors, not code** — \"the sync service fails to apply the patch\" not \"applyPatch() throws on line 42\"\n- **Reproduction steps are mandatory** — if you can't determine them, ask the user\n- **Keep it concise** — a developer should be able to read the issue in 30 seconds\n\nAfter filing, print all issue URLs (with blocking relationships summarized) and ask: \"Next issue, or are we done?\"\n\n### 5. Continue the session\n\nKeep going until the user says they're done. Each issue is independent — don't batch them.\n","# QA Session\n\nRun an interactive QA session. The user describes problems they're encountering. You clarify, explore the codebase for context, and file GitHub issues that are durable, user-focused, and use the project's domain language.\n\n## For each issue the user raises\n\n### 1. Listen and lightly clarify\n\nLet the user describe the problem in their own words. Ask **at most 2-3 short clarifying questions** focused on:\n\n- What they expected vs what actually happened\n- Steps to reproduce (if not obvious)\n- Whether it's consistent or intermittent\n\nDo NOT over-interview. If the description is clear enough to file, move on.\n\n### 2. Explore the codebase in the background\n\nWhile talking to the user, kick off an Agent (subagent_type=Explore) in the background to understand the relevant area. The goal is NOT to find a fix — it's to:\n\n- Learn the domain language used in that area (check UBIQUITOUS_LANGUAGE.md)\n- Understand what the feature is supposed to do\n- Identify the user-facing behavior boundary\n\nThis context helps you write a better issue — but the issue itself should NOT reference specific files, line numbers, or internal implementation details.\n\n### 3. Assess scope: single issue or breakdown?\n\nBefore filing, decide whether this is a **single issue** or needs to be **broken down** into multiple issues.\n\nBreak down when:\n\n- The fix spans multiple independent areas (e.g. \"the form validation is wrong AND the success message is missing AND the redirect is broken\")\n- There are clearly separable concerns that different people could work on in parallel\n- The user describes something that has multiple distinct failure modes or symptoms\n\nKeep as a single issue when:\n\n- It's one behavior that's wrong in one place\n- The symptoms are all caused by the same root behavior\n\n### 4. File the GitHub issue(s)\n\nCreate issues with `gh issue create`. Do NOT ask the user to review first — just file and share URLs.\n\nIssues must be **durable** — they should still make sense after major refactors. Write from the user's perspective.\n\n#### For a single issue\n\nUse this template:\n\n```\n## What happened\n\n[Describe the actual behavior the user experienced, in plain language]\n\n## What I expected\n\n[Describe the expected behavior]\n\n## Steps to reproduce\n\n1. [Concrete, numbered steps a developer can follow]\n2. [Use domain terms from the codebase, not internal module names]\n3. [Include relevant inputs, flags, or configuration]\n\n## Additional context\n\n[Any extra observations from the user or from codebase exploration that help frame the issue — e.g. \"this only happens when using the Docker layer, not the filesystem layer\" — use domain language but don't cite files]\n```\n\n#### For a breakdown (multiple issues)\n\nCreate issues in dependency order (blockers first) so you can reference real issue numbers.\n\nUse this template for each sub-issue:\n\n```\n## Parent issue\n\n#\u003Cparent-issue-number> (if you created a tracking issue) or \"Reported during QA session\"\n\n## What's wrong\n\n[Describe this specific behavior problem — just this slice, not the whole report]\n\n## What I expected\n\n[Expected behavior for this specific slice]\n\n## Steps to reproduce\n\n1. [Steps specific to THIS issue]\n\n## Blocked by\n\n- #\u003Cissue-number> (if this issue can't be fixed until another is resolved)\n\nOr \"None — can start immediately\" if no blockers.\n\n## Additional context\n\n[Any extra observations relevant to this slice]\n```\n\nWhen creating a breakdown:\n\n- **Prefer many thin issues over few thick ones** — each should be independently fixable and verifiable\n- **Mark blocking relationships honestly** — if issue B genuinely can't be tested until issue A is fixed, say so. If they're independent, mark both as \"None — can start immediately\"\n- **Create issues in dependency order** so you can reference real issue numbers in \"Blocked by\"\n- **Maximize parallelism** — the goal is that multiple people (or agents) can grab different issues simultaneously\n\n#### Rules for all issue bodies\n\n- **No file paths or line numbers** — these go stale\n- **Use the project's domain language** (check UBIQUITOUS_LANGUAGE.md if it exists)\n- **Describe behaviors, not code** — \"the sync service fails to apply the patch\" not \"applyPatch() throws on line 42\"\n- **Reproduction steps are mandatory** — if you can't determine them, ask the user\n- **Keep it concise** — a developer should be able to read the issue in 30 seconds\n\nAfter filing, print all issue URLs (with blocking relationships summarized) and ask: \"Next issue, or are we done?\"\n\n### 5. Continue the session\n\nKeep going until the user says they're done. Each issue is independent — don't batch them.\n",{"name":5,"description":7},"main","74cd3c4137064fdcde71ed9fe5c4bff58921d899","components\u002Fskills\u002Fqa",0,"https:\u002F\u002Fgithub.com\u002Farkhe-genesis\u002FArkhe-OS","https:\u002F\u002Fgithub.com\u002Farkhe-genesis","2026-11-08 09:08:55",{"source":8,"skillName":5,"commands":51,"prompt":61,"zipAvailable":62},[52,55,58],{"tool":53,"command":54},"npx","npx skills add arkhe-genesis\u002FArkhe-OS --skill qa",{"tool":56,"command":57},"bunx","bunx skills add arkhe-genesis\u002FArkhe-OS --skill qa",{"tool":59,"command":60},"pnpm","pnpm dlx skills add arkhe-genesis\u002FArkhe-OS --skill qa","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Farkhe-genesis\u002FArkhe-OS\u002Fblob\u002Fmain\u002Fcomponents\u002Fskills\u002Fqa\u002FSKILL.md",true,[],[65,88,105,126,148,167],{"skillNo":66,"name":67,"nameZh":6,"description":68,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":69,"categories":70,"keywords":71,"publishedAt":38},"01M6MN97RPP1Q9BG489WHW70R8","career-ops","AI job search command center -- evaluate offers, generate CVs, scan portals, track applications","https:\u002F\u002Fgithub.com\u002Farkhe-genesis\u002FArkhe-OS\u002Fblob\u002Fmain\u002Ftools\u002F.ai-integrations\u002Fvscode\u002F.claude\u002Fskills\u002Fcareer-ops\u002FSKILL.md",[],[72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87],"ops","career","career ops","track","applications","evaluate","mode","true","command center","cvs","scan","command","offers","Job Search","search","generate",{"skillNo":89,"name":90,"nameZh":6,"description":91,"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":38},"01M6MN93GFX8W9J1PCKDKZVD3N","zoom-out","Tell the agent to zoom out and give broader context or a higher-level perspective. Use when you're unfamiliar with a section of code or need to understand how it fits into the bigger picture.","https:\u002F\u002Fgithub.com\u002Farkhe-genesis\u002FArkhe-OS\u002Fblob\u002Fmain\u002Ftools\u002F.agents\u002Fskills\u002Fzoom-out\u002FSKILL.md",[],[95,96,19,97,33,98,99,100,79,101,102,103,104],"zoom out","zoom","how","code","it","perspective","re","you","with","understand",{"skillNo":106,"name":107,"nameZh":6,"description":108,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":109,"categories":110,"keywords":116,"publishedAt":38},"01M6MN8Y2ETBC91BGREF4D39JH","write-a-skill","Create new agent skills with proper structure, progressive disclosure, and bundled resources. Use when user wants to create, write, or build a new skill.","https:\u002F\u002Fgithub.com\u002Farkhe-genesis\u002FArkhe-OS\u002Fblob\u002Fmain\u002Ftools\u002F.agents\u002Fskills\u002Fwrite-a-skill\u002FSKILL.md",[111],{"categoryNo":112,"categoryName":113,"taxonomyType":114,"taxonomyTypeDesc":115},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[117,118,119,103,120,121,122,123,124,19,31,125],"write","write a skill","progressive disclosure","resources","new agent","structure","new skill","build","create",{"skillNo":127,"name":128,"nameZh":6,"description":129,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":130,"categories":131,"keywords":133,"publishedAt":38},"01M6MN8RWE2V2PPFVPD0G8FHKF","triage","Triage issues through a state machine driven by triage roles. Use when user wants to create an issue, triage issues, review incoming bugs or feature requests, prepare issues for an AFK agent, or manage issue workflow.","https:\u002F\u002Fgithub.com\u002Farkhe-genesis\u002FArkhe-OS\u002Fblob\u002Fmain\u002Ftools\u002F.agents\u002Fskills\u002Ftriage\u002FSKILL.md",[132],{"categoryNo":112,"categoryName":113,"taxonomyType":114,"taxonomyTypeDesc":115},[128,22,134,125,135,136,137,138,139,140,141,19,35,142,23,143,144,145,146,147],"state machine","requests","machine","feature","roles","issue workflow","manage","issue","state","feature requests","prepare","triage issues","workflow","review",{"skillNo":149,"name":150,"nameZh":6,"description":151,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":152,"categories":153,"keywords":159,"publishedAt":38},"01M6MN8KVDBD28672WMER7HPXM","to-prd","Turn the current conversation context into a PRD and publish it to the project issue tracker. Use when user wants to create a PRD from the current context.","https:\u002F\u002Fgithub.com\u002Farkhe-genesis\u002FArkhe-OS\u002Fblob\u002Fmain\u002Ftools\u002F.agents\u002Fskills\u002Fto-prd\u002FSKILL.md",[154],{"categoryNo":155,"categoryName":156,"taxonomyType":157,"taxonomyTypeDesc":158},"01JBSEEDCAT000000000000031","产品经理","PROFESSION","适用职业",[160,161,19,31,33,162,125,141,163,99,164,165,166],"to prd","prd","publish","issue tracker","project","conversation","tracker",{"skillNo":168,"name":169,"nameZh":6,"description":170,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":171,"categories":172,"keywords":173,"publishedAt":38},"01M6MN8E9CGYVWVDDR0NJEFDBB","to-issues","Break a plan, spec, or PRD into independently-grabbable issues on the project issue tracker using tracer-bullet vertical slices. Use when user wants to convert a plan into issues, create implementation tickets, or break down work into issues.","https:\u002F\u002Fgithub.com\u002Farkhe-genesis\u002FArkhe-OS\u002Fblob\u002Fmain\u002Ftools\u002F.agents\u002Fskills\u002Fto-issues\u002FSKILL.md",[],[35,174,175,164,176,177,163,178,179,166,141,180,19,31,181,182,183,161,125],"to issues","spec","down","break","break down","tickets","implementation","work","convert","plan"]