[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71Q37K6468BFSDRCGQJFPC3":3,"skill-same:01M71Q37K6468BFSDRCGQJFPC3":80},{"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":27,"publishedAt":48,"linkOnly":49,"markdownContent":50,"markdownBody":51,"frontMatter":52,"refName":60,"commitSha":61,"skillDirectory":62,"forksCount":13,"repositoryHtmlUrl":63,"repositoryHomepageUrl":6,"ownerHtmlUrl":64,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":65,"install":66,"resources":79},"01M71Q37K6468BFSDRCGQJFPC3","adversarial-ux-test",null,"Roleplay the most difficult, tech-resistant user for your product. Browse the app as that persona, find every UX pain point, then filter complaints through a pragmatism layer to separate real problems from noise. Creates actionable tickets from genuine issues only.","gjbvsjjvgm-sketch\u002FWORM_V2_SOVEREIGN","gjbvsjjvgm-sketch","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F278511911?v=4","01M71F3JXKZQ70H2KCHHTXKZDA","01M71PENEVFN19DBZFNHJPCHQ7",0,"MIT","https:\u002F\u002Fgithub.com\u002Fgjbvsjjvgm-sketch\u002FWORM_V2_SOVEREIGN\u002Fblob\u002Fmain\u002Fcore\u002Foptional-skills\u002Fdogfood\u002Fadversarial-ux-test\u002FSKILL.md",[17,22],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":23,"categoryName":24,"taxonomyType":25,"taxonomyTypeDesc":26},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47],"adversarial","ux","adversarial ux test","test","roleplay","filter","qa","persona","only","issues","testing","personas","actionable","for","browse","tech","dogfood","point","as","app","2026-11-10 13:02:02",false,"---\nname: adversarial-ux-test\ndescription: Roleplay the most difficult, tech-resistant user for your product. Browse the app as that persona, find every UX pain point, then filter complaints through a pragmatism layer to separate real problems from noise. Creates actionable tickets from genuine issues only.\nversion: 1.0.0\nauthor: Omni @ Comelse\nlicense: MIT\nmetadata:\n  hermes:\n    tags: [qa, ux, testing, adversarial, dogfood, personas, user-testing]\n    related_skills: [dogfood]\n---\n\n# Adversarial UX Test\n\nRoleplay the worst-case user for your product — the person who hates technology, doesn't want your software, and will find every reason to complain. Then filter their feedback through a pragmatism layer to separate real UX problems from \"I hate computers\" noise.\n\nThink of it as an automated \"mom test\" — but angry.\n\n## Why This Works\n\nMost QA finds bugs. This finds **friction**. A technically correct app can still be unusable for real humans. The adversarial persona catches:\n- Confusing terminology that makes sense to developers but not users\n- Too many steps to accomplish basic tasks\n- Missing onboarding or \"aha moments\"\n- Accessibility issues (font size, contrast, click targets)\n- Cold-start problems (empty states, no demo content)\n- Paywall\u002Fsignup friction that kills conversion\n\nThe **pragmatism filter** (Phase 3) is what makes this useful instead of just entertaining. Without it, you'd add a \"print this page\" button to every screen because Grandpa can't figure out PDFs.\n\n## How to Use\n\nTell the agent:\n```\n\"Run an adversarial UX test on [URL]\"\n\"Be a grumpy [persona type] and test [app name]\"\n\"Do an asshole user test on my staging site\"\n```\n\nYou can provide a persona or let the agent generate one based on your product's target audience.\n\n## Step 1: Define the Persona\n\nIf no persona is provided, generate one by answering:\n\n1. **Who is the HARDEST user for this product?** (age 50+, non-technical role, decades of experience doing it \"the old way\")\n2. **What is their tech comfort level?** (the lower the better — WhatsApp-only, paper notebooks, wife set up their email)\n3. **What is the ONE thing they need to accomplish?** (their core job, not your feature list)\n4. **What would make them give up?** (too many clicks, jargon, slow, confusing)\n5. **How do they talk when frustrated?** (blunt, sweary, dismissive, sighing)\n\n### Good Persona Example\n> **\"Big Mick\" McAllister** — 58-year-old S&C coach. Uses WhatsApp and that's it. His \"spreadsheet\" is a paper notebook. \"If I can't figure it out in 10 seconds I'm going back to my notebook.\" Needs to log session results for 25 players. Hates small text, jargon, and passwords.\n\n### Bad Persona Example\n> \"A user who doesn't like the app\" — too vague, no constraints, no voice.\n\nThe persona must be **specific enough to stay in character** for 20 minutes of testing.\n\n## Step 2: Become the Asshole (Browse as the Persona)\n\n1. Read any available project docs for app context and URLs\n2. **Fully inhabit the persona** — their frustrations, limitations, goals\n3. Navigate to the app using browser tools\n4. **Attempt the persona's ACTUAL TASKS** (not a feature tour):\n   - Can they do what they came to do?\n   - How many clicks\u002Fscreens to accomplish it?\n   - What confuses them?\n   - What makes them angry?\n   - Where do they get lost?\n   - What would make them give up and go back to their old way?\n\n5. Test these friction categories:\n   - **First impression** — would they even bother past the landing page?\n   - **Core workflow** — the ONE thing they need to do most often\n   - **Error recovery** — what happens when they do something wrong?\n   - **Readability** — text size, contrast, information density\n   - **Speed** — does it feel faster than their current method?\n   - **Terminology** — any jargon they wouldn't understand?\n   - **Navigation** — can they find their way back? do they know where they are?\n\n6. Take screenshots of every pain point\n7. Check browser console for JS errors on every page\n\n## Step 3: The Rant (Write Feedback in Character)\n\nWrite the feedback AS THE PERSONA — in their voice, with their frustrations. This is not a bug report. This is a real human venting.\n\n```\n[PERSONA NAME]'s Review of [PRODUCT]\n\nOverall: [Would they keep using it? Yes\u002FNo\u002FMaybe with conditions]\n\nTHE GOOD (grudging admission):\n- [things even they have to admit work]\n\nTHE BAD (legitimate UX issues):\n- [real problems that would stop them from using the product]\n\nTHE UGLY (showstoppers):\n- [things that would make them uninstall\u002Fcancel immediately]\n\nSPECIFIC COMPLAINTS:\n1. [Page\u002Ffeature]: \"[quote in persona voice]\" — [what happened, expected]\n2. ...\n\nVERDICT: \"[one-line persona quote summarizing their experience]\"\n```\n\n## Step 4: The Pragmatism Filter (Critical — Do Not Skip)\n\nStep OUT of the persona. Evaluate each complaint as a product person:\n\n- **RED: REAL UX BUG** — Any user would have this problem, not just grumpy ones. Fix it.\n- **YELLOW: VALID BUT LOW PRIORITY** — Real issue but only for extreme users. Note it.\n- **WHITE: PERSONA NOISE** — \"I hate computers\" talking, not a product problem. Skip it.\n- **GREEN: FEATURE REQUEST** — Good idea hidden in the complaint. Consider it.\n\n### Filter Criteria\n1. Would a 35-year-old competent-but-busy user have the same complaint? → RED\n2. Is this a genuine accessibility issue (font size, contrast, click targets)? → RED\n3. Is this \"I want it to work like paper\" resistance to digital? → WHITE\n4. Is this a real workflow inefficiency the persona stumbled on? → YELLOW or RED\n5. Would fixing this add complexity for the 80% who are fine? → WHITE\n6. Does the complaint reveal a missing onboarding moment? → GREEN\n\n**This filter is MANDATORY.** Never ship raw persona complaints as tickets.\n\n## Step 5: Create Tickets\n\nFor **RED** and **GREEN** items only:\n- Clear, actionable title\n- Include the persona's verbatim quote (entertaining + memorable)\n- The real UX issue underneath (objective)\n- A suggested fix (actionable)\n- Tag\u002Flabel: \"ux-review\"\n\nFor **YELLOW** items: one catch-all ticket with all notes.\n\n**WHITE** items appear in the report only. No tickets.\n\n**Max 10 tickets per session** — focus on the worst issues.\n\n## Step 6: Report\n\nDeliver:\n1. The persona rant (Step 3) — entertaining and visceral\n2. The filtered assessment (Step 4) — pragmatic and actionable\n3. Tickets created (Step 5) — with links\n4. Screenshots of key issues\n\n## Tips\n\n- **One persona per session.** Don't mix perspectives.\n- **Stay in character during Steps 2-3.** Break character only at Step 4.\n- **Test the CORE WORKFLOW first.** Don't get distracted by settings pages.\n- **Empty states are gold.** New user experience reveals the most friction.\n- **The best findings are RED items the persona found accidentally** while trying to do something else.\n- **If the persona has zero complaints, your persona is too tech-savvy.** Make them older, less patient, more set in their ways.\n- **Run this before demos, launches, or after shipping a batch of features.**\n- **Register as a NEW user when possible.** Don't use pre-seeded admin accounts — the cold start experience is where most friction lives.\n- **Zero WHITE items is a signal, not a failure.** If the pragmatism filter finds no noise, your product has real UX problems, not just a grumpy persona.\n- **Check known issues in project docs AFTER the test.** If the persona found a bug that's already in the known issues list, that's actually the most damning finding — it means the team knew about it but never felt the user's pain.\n- **Subscription\u002Fpaywall testing is critical.** Test with expired accounts, not just active ones. The \"what happens when you can't pay\" experience reveals whether the product respects users or holds their data hostage.\n- **Count the clicks to accomplish the persona's ONE task.** If it's more than 5, that's almost always a RED finding regardless of persona tech level.\n\n## Example Personas by Industry\n\nThese are starting points — customize for your specific product:\n\n| Product Type | Persona | Age | Key Trait |\n|-------------|---------|-----|-----------|\n| CRM | Retirement home director | 68 | Filing cabinet is the current CRM |\n| Photography SaaS | Rural wedding photographer | 62 | Books clients by phone, invoices on paper |\n| AI\u002FML Tool | Department store buyer | 55 | Burned by 3 failed tech startups |\n| Fitness App | Old-school gym coach | 58 | Paper notebook, thick fingers, bad eyes |\n| Accounting | Family bakery owner | 64 | Shoebox of receipts, hates subscriptions |\n| E-commerce | Market stall vendor | 60 | Cash only, smartphone is for calls |\n| Healthcare | Senior GP | 63 | Dictates notes, nurse handles the computer |\n| Education | Veteran teacher | 57 | Chalk and talk, worksheets in ring binders |\n\n## Rules\n\n- Stay in character during Steps 2-3\n- Be genuinely mean but fair — find real problems, not manufactured ones\n- The pragmatism filter (Step 4) is **MANDATORY**\n- Screenshots required for every complaint\n- Max 10 tickets per session\n- Test on staging\u002Fdeployed app, not local dev\n- One persona, one session, one report\n","# Adversarial UX Test\n\nRoleplay the worst-case user for your product — the person who hates technology, doesn't want your software, and will find every reason to complain. Then filter their feedback through a pragmatism layer to separate real UX problems from \"I hate computers\" noise.\n\nThink of it as an automated \"mom test\" — but angry.\n\n## Why This Works\n\nMost QA finds bugs. This finds **friction**. A technically correct app can still be unusable for real humans. The adversarial persona catches:\n- Confusing terminology that makes sense to developers but not users\n- Too many steps to accomplish basic tasks\n- Missing onboarding or \"aha moments\"\n- Accessibility issues (font size, contrast, click targets)\n- Cold-start problems (empty states, no demo content)\n- Paywall\u002Fsignup friction that kills conversion\n\nThe **pragmatism filter** (Phase 3) is what makes this useful instead of just entertaining. Without it, you'd add a \"print this page\" button to every screen because Grandpa can't figure out PDFs.\n\n## How to Use\n\nTell the agent:\n```\n\"Run an adversarial UX test on [URL]\"\n\"Be a grumpy [persona type] and test [app name]\"\n\"Do an asshole user test on my staging site\"\n```\n\nYou can provide a persona or let the agent generate one based on your product's target audience.\n\n## Step 1: Define the Persona\n\nIf no persona is provided, generate one by answering:\n\n1. **Who is the HARDEST user for this product?** (age 50+, non-technical role, decades of experience doing it \"the old way\")\n2. **What is their tech comfort level?** (the lower the better — WhatsApp-only, paper notebooks, wife set up their email)\n3. **What is the ONE thing they need to accomplish?** (their core job, not your feature list)\n4. **What would make them give up?** (too many clicks, jargon, slow, confusing)\n5. **How do they talk when frustrated?** (blunt, sweary, dismissive, sighing)\n\n### Good Persona Example\n> **\"Big Mick\" McAllister** — 58-year-old S&C coach. Uses WhatsApp and that's it. His \"spreadsheet\" is a paper notebook. \"If I can't figure it out in 10 seconds I'm going back to my notebook.\" Needs to log session results for 25 players. Hates small text, jargon, and passwords.\n\n### Bad Persona Example\n> \"A user who doesn't like the app\" — too vague, no constraints, no voice.\n\nThe persona must be **specific enough to stay in character** for 20 minutes of testing.\n\n## Step 2: Become the Asshole (Browse as the Persona)\n\n1. Read any available project docs for app context and URLs\n2. **Fully inhabit the persona** — their frustrations, limitations, goals\n3. Navigate to the app using browser tools\n4. **Attempt the persona's ACTUAL TASKS** (not a feature tour):\n   - Can they do what they came to do?\n   - How many clicks\u002Fscreens to accomplish it?\n   - What confuses them?\n   - What makes them angry?\n   - Where do they get lost?\n   - What would make them give up and go back to their old way?\n\n5. Test these friction categories:\n   - **First impression** — would they even bother past the landing page?\n   - **Core workflow** — the ONE thing they need to do most often\n   - **Error recovery** — what happens when they do something wrong?\n   - **Readability** — text size, contrast, information density\n   - **Speed** — does it feel faster than their current method?\n   - **Terminology** — any jargon they wouldn't understand?\n   - **Navigation** — can they find their way back? do they know where they are?\n\n6. Take screenshots of every pain point\n7. Check browser console for JS errors on every page\n\n## Step 3: The Rant (Write Feedback in Character)\n\nWrite the feedback AS THE PERSONA — in their voice, with their frustrations. This is not a bug report. This is a real human venting.\n\n```\n[PERSONA NAME]'s Review of [PRODUCT]\n\nOverall: [Would they keep using it? Yes\u002FNo\u002FMaybe with conditions]\n\nTHE GOOD (grudging admission):\n- [things even they have to admit work]\n\nTHE BAD (legitimate UX issues):\n- [real problems that would stop them from using the product]\n\nTHE UGLY (showstoppers):\n- [things that would make them uninstall\u002Fcancel immediately]\n\nSPECIFIC COMPLAINTS:\n1. [Page\u002Ffeature]: \"[quote in persona voice]\" — [what happened, expected]\n2. ...\n\nVERDICT: \"[one-line persona quote summarizing their experience]\"\n```\n\n## Step 4: The Pragmatism Filter (Critical — Do Not Skip)\n\nStep OUT of the persona. Evaluate each complaint as a product person:\n\n- **RED: REAL UX BUG** — Any user would have this problem, not just grumpy ones. Fix it.\n- **YELLOW: VALID BUT LOW PRIORITY** — Real issue but only for extreme users. Note it.\n- **WHITE: PERSONA NOISE** — \"I hate computers\" talking, not a product problem. Skip it.\n- **GREEN: FEATURE REQUEST** — Good idea hidden in the complaint. Consider it.\n\n### Filter Criteria\n1. Would a 35-year-old competent-but-busy user have the same complaint? → RED\n2. Is this a genuine accessibility issue (font size, contrast, click targets)? → RED\n3. Is this \"I want it to work like paper\" resistance to digital? → WHITE\n4. Is this a real workflow inefficiency the persona stumbled on? → YELLOW or RED\n5. Would fixing this add complexity for the 80% who are fine? → WHITE\n6. Does the complaint reveal a missing onboarding moment? → GREEN\n\n**This filter is MANDATORY.** Never ship raw persona complaints as tickets.\n\n## Step 5: Create Tickets\n\nFor **RED** and **GREEN** items only:\n- Clear, actionable title\n- Include the persona's verbatim quote (entertaining + memorable)\n- The real UX issue underneath (objective)\n- A suggested fix (actionable)\n- Tag\u002Flabel: \"ux-review\"\n\nFor **YELLOW** items: one catch-all ticket with all notes.\n\n**WHITE** items appear in the report only. No tickets.\n\n**Max 10 tickets per session** — focus on the worst issues.\n\n## Step 6: Report\n\nDeliver:\n1. The persona rant (Step 3) — entertaining and visceral\n2. The filtered assessment (Step 4) — pragmatic and actionable\n3. Tickets created (Step 5) — with links\n4. Screenshots of key issues\n\n## Tips\n\n- **One persona per session.** Don't mix perspectives.\n- **Stay in character during Steps 2-3.** Break character only at Step 4.\n- **Test the CORE WORKFLOW first.** Don't get distracted by settings pages.\n- **Empty states are gold.** New user experience reveals the most friction.\n- **The best findings are RED items the persona found accidentally** while trying to do something else.\n- **If the persona has zero complaints, your persona is too tech-savvy.** Make them older, less patient, more set in their ways.\n- **Run this before demos, launches, or after shipping a batch of features.**\n- **Register as a NEW user when possible.** Don't use pre-seeded admin accounts — the cold start experience is where most friction lives.\n- **Zero WHITE items is a signal, not a failure.** If the pragmatism filter finds no noise, your product has real UX problems, not just a grumpy persona.\n- **Check known issues in project docs AFTER the test.** If the persona found a bug that's already in the known issues list, that's actually the most damning finding — it means the team knew about it but never felt the user's pain.\n- **Subscription\u002Fpaywall testing is critical.** Test with expired accounts, not just active ones. The \"what happens when you can't pay\" experience reveals whether the product respects users or holds their data hostage.\n- **Count the clicks to accomplish the persona's ONE task.** If it's more than 5, that's almost always a RED finding regardless of persona tech level.\n\n## Example Personas by Industry\n\nThese are starting points — customize for your specific product:\n\n| Product Type | Persona | Age | Key Trait |\n|-------------|---------|-----|-----------|\n| CRM | Retirement home director | 68 | Filing cabinet is the current CRM |\n| Photography SaaS | Rural wedding photographer | 62 | Books clients by phone, invoices on paper |\n| AI\u002FML Tool | Department store buyer | 55 | Burned by 3 failed tech startups |\n| Fitness App | Old-school gym coach | 58 | Paper notebook, thick fingers, bad eyes |\n| Accounting | Family bakery owner | 64 | Shoebox of receipts, hates subscriptions |\n| E-commerce | Market stall vendor | 60 | Cash only, smartphone is for calls |\n| Healthcare | Senior GP | 63 | Dictates notes, nurse handles the computer |\n| Education | Veteran teacher | 57 | Chalk and talk, worksheets in ring binders |\n\n## Rules\n\n- Stay in character during Steps 2-3\n- Be genuinely mean but fair — find real problems, not manufactured ones\n- The pragmatism filter (Step 4) is **MANDATORY**\n- Screenshots required for every complaint\n- Max 10 tickets per session\n- Test on staging\u002Fdeployed app, not local dev\n- One persona, one session, one report\n",{"name":5,"author":53,"license":14,"version":54,"metadata":55,"description":7},"Omni @ Comelse","1.0.0",{"hermes":56},{"tags":57,"related_skills":59},[34,29,38,28,44,39,58],"user-testing",[44],"main","6746276ba18cb774853eb61b3b9399658bc9bc5c","core\u002Foptional-skills\u002Fdogfood\u002Fadversarial-ux-test","https:\u002F\u002Fgithub.com\u002Fgjbvsjjvgm-sketch\u002FWORM_V2_SOVEREIGN","https:\u002F\u002Fgithub.com\u002Fgjbvsjjvgm-sketch","2026-04-28 17:01:03",{"source":8,"skillName":5,"commands":67,"prompt":77,"zipAvailable":78},[68,71,74],{"tool":69,"command":70},"npx","npx skills add gjbvsjjvgm-sketch\u002FWORM_V2_SOVEREIGN --skill adversarial-ux-test",{"tool":72,"command":73},"bunx","bunx skills add gjbvsjjvgm-sketch\u002FWORM_V2_SOVEREIGN --skill adversarial-ux-test",{"tool":75,"command":76},"pnpm","pnpm dlx skills add gjbvsjjvgm-sketch\u002FWORM_V2_SOVEREIGN --skill adversarial-ux-test","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fgjbvsjjvgm-sketch\u002FWORM_V2_SOVEREIGN\u002Fblob\u002Fmain\u002Fcore\u002Foptional-skills\u002Fdogfood\u002Fadversarial-ux-test\u002FSKILL.md",true,[],[81,119,141,158,177,196],{"skillNo":82,"name":83,"nameZh":6,"description":84,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":85,"categories":86,"keywords":99,"publishedAt":48},"01M71QG27G1R2H2ZWEG4S0WTZT","writing-plans","Write implementation plans: bite-sized tasks, paths, code.","https:\u002F\u002Fgithub.com\u002Fgjbvsjjvgm-sketch\u002FWORM_V2_SOVEREIGN\u002Fblob\u002Fmain\u002Fcore\u002Fskills\u002Fsoftware-development\u002Fwriting-plans\u002FSKILL.md",[87,90,93,96],{"categoryNo":88,"categoryName":89,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":91,"categoryName":92,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":94,"categoryName":95,"taxonomyType":25,"taxonomyTypeDesc":26},"01JBSEEDCAT000000000000030","开发工程师",{"categoryNo":97,"categoryName":98,"taxonomyType":25,"taxonomyTypeDesc":26},"01JBSEEDCAT000000000000036","内容创作者",[100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,31,118],"writing","writing plans","plans","test-driven","test-driven-development","superpowers","design","workflow","code","tasks","subagent","code-review","review","documentation","write","paths","planning","development","implementation",{"skillNo":120,"name":104,"nameZh":6,"description":121,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":122,"categories":123,"keywords":128,"publishedAt":48},"01M71QFZYRTJXMAE551MRAKZ14","TDD: enforce RED-GREEN-REFACTOR, tests before code.","https:\u002F\u002Fgithub.com\u002Fgjbvsjjvgm-sketch\u002FWORM_V2_SOVEREIGN\u002Fblob\u002Fmain\u002Fcore\u002Fskills\u002Fsoftware-development\u002Ftest-driven-development\u002FSKILL.md",[124,127],{"categoryNo":125,"categoryName":126,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},[129,117,31,130,131,132,38,105,100,133,108,110,134,135,136,137,138,102,139,140],"test driven development","driven","green","red-green-refactor","debugging","systematic","refactor","systematic-debugging","enforce","tests","tdd","quality",{"skillNo":142,"name":136,"nameZh":6,"description":143,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":144,"categories":145,"keywords":147,"publishedAt":48},"01M71QFWR5Q8EYEQ6MCS3SM6MC","4-phase root cause debugging: understand bugs before fixing.","https:\u002F\u002Fgithub.com\u002Fgjbvsjjvgm-sketch\u002FWORM_V2_SOVEREIGN\u002Fblob\u002Fmain\u002Fcore\u002Fskills\u002Fsoftware-development\u002Fsystematic-debugging\u002FSKILL.md",[146],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},[148,133,134,103,149,150,104,105,100,110,151,152,117,153,102,154,31,155,156,157],"systematic debugging","problem","problem-solving","phase","bugs","root cause","root-cause","investigation","understand","hermes",{"skillNo":159,"name":160,"nameZh":6,"description":161,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":162,"categories":163,"keywords":169,"publishedAt":48},"01M71QFS9S04MD8JP747W5WM0N","subagent-driven-development","Execute plans via delegate_task subagents (2-stage review).","https:\u002F\u002Fgithub.com\u002Fgjbvsjjvgm-sketch\u002FWORM_V2_SOVEREIGN\u002Fblob\u002Fmain\u002Fcore\u002Fskills\u002Fsoftware-development\u002Fsubagent-driven-development\u002FSKILL.md",[164,165,168],{"categoryNo":91,"categoryName":92,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":166,"categoryName":167,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":97,"categoryName":98,"taxonomyType":25,"taxonomyTypeDesc":26},[170,110,117,130,103,104,171,172,105,100,107,108,111,112,173,174,102,175,176,31],"subagent driven development","delegate","delegation","subagents","parallel","stage","task",{"skillNo":178,"name":179,"nameZh":6,"description":180,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":181,"categories":182,"keywords":185,"publishedAt":48},"01M71QFQ1DBCVAZ511MXFE6T2V","requesting-code-review","Pre-commit review: security scan, quality gates, auto-fix.","https:\u002F\u002Fgithub.com\u002Fgjbvsjjvgm-sketch\u002FWORM_V2_SOVEREIGN\u002Fblob\u002Fmain\u002Fcore\u002Fskills\u002Fsoftware-development\u002Frequesting-code-review\u002FSKILL.md",[183,184],{"categoryNo":125,"categoryName":126,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":94,"categoryName":95,"taxonomyType":25,"taxonomyTypeDesc":26},[186,187,108,112,103,104,188,189,105,190,100,191,192,110,111,193,194,117,195,102],"code review","requesting code review","fix","auto-fix","auto","security scan","commit","verification","security","scan",{"skillNo":197,"name":198,"nameZh":6,"description":199,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":200,"categories":201,"keywords":203,"publishedAt":48},"01M71QFM7KWM540YR67FRN807Q","python-debugpy","Debug Python: pdb REPL + debugpy remote (DAP).","https:\u002F\u002Fgithub.com\u002Fgjbvsjjvgm-sketch\u002FWORM_V2_SOVEREIGN\u002Fblob\u002Fmain\u002Fcore\u002Fskills\u002Fsoftware-development\u002Fpython-debugpy\u002FSKILL.md",[202],{"categoryNo":94,"categoryName":95,"taxonomyType":25,"taxonomyTypeDesc":26},[204,205,206,207,208,209,210,211,133,134,212,213,214,136,215,216,217,218,157,219],"debugpy","python debugpy","python","dap","inspect","post-mortem","pdb","remote","debugger","node","commands","debug","post","breakpoints","node-inspect","tui"]