[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6JPFGWCZQK7X8QZPJFJ8FBT":3,"skill-same:01M6JPFGWCZQK7X8QZPJFJ8FBT":88},{"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":31,"publishedAt":52,"linkOnly":53,"markdownContent":54,"markdownBody":55,"frontMatter":56,"refName":57,"commitSha":58,"skillDirectory":59,"forksCount":14,"repositoryHtmlUrl":60,"repositoryHomepageUrl":6,"ownerHtmlUrl":61,"ownerBlogUrl":6,"ownerDescription":62,"updatedAt":63,"install":64,"resources":77},"01M6JPFGWCZQK7X8QZPJFJ8FBT","accessibility-design",null,"Design and implement accessible web\u002Fmobile apps to WCAG 2.1\u002F2.2 — semantic HTML, ARIA patterns, keyboard navigation, focus management, color contrast, screen readers, accessible forms. Triggers: accessibility, a11y, WCAG, screen reader, keyboard navigation, ARIA, focus management, color contrast, alt text, semantic HTML, tab order, focus trap, skip link, announce. Build it in, don't bolt it on.","SWEStash\u002Fswe-workflow-skills","SWEStash","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F272895713?v=4","01M6JNRQ84JN5WFK9S1V5H4G46","SWE Stash","01M6JNRQCM45X8WPNHY30TSAB0",1,"MIT","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fplugins\u002Ffrontend\u002Fskills\u002Faccessibility-design\u002FSKILL.md",[18,23,26],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":27,"categoryName":28,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51],"design","accessibility","accessibility design","announce","contrast","color","screen","keyboard","apps","triggers","focus","forms","patterns","aria","mobile","html","bolt","text","WCAG","implement","2026-11-10 10:12:30",false,"---\nname: accessibility-design\ndescription: \"Design and implement accessible web\u002Fmobile apps to WCAG 2.1\u002F2.2 — semantic HTML, ARIA patterns, keyboard navigation, focus management, color contrast, screen readers, accessible forms. Triggers: accessibility, a11y, WCAG, screen reader, keyboard navigation, ARIA, focus management, color contrast, alt text, semantic HTML, tab order, focus trap, skip link, announce. Build it in, don't bolt it on.\"\n---\n\n# Accessibility Design\n\nBuild accessibility into applications from the start. Accessibility is not a feature — it's a quality attribute, like performance or security. Retrofitting it is 10x harder than building it in.\n\n## Core Principle\n\n**Use semantic HTML first, ARIA second, custom JavaScript last.** A native `\u003Cbutton>` gives you keyboard support, focus management, and screen reader announcement for free. A `\u003Cdiv onClick>` gives you none of that and requires manual reimplementation of every behavior the browser provides natively.\n\n## Workflow\n\n### Step 1: Understand the Requirements\n\nDetermine the target compliance level:\n\n- **WCAG 2.1 Level A**: Minimum baseline (avoid lawsuits, but still inaccessible)\n- **WCAG 2.1 Level AA**: Industry standard (recommended minimum for all projects)\n- **WCAG 2.2 Level AA**: Current standard, adds mobile and cognitive accessibility\n- **WCAG Level AAA**: Aspirational — few sites achieve this fully\n\nFor most projects, **target WCAG 2.1 AA** as the minimum. Level AAA for specific features where feasible.\n\n### Step 2: Apply Semantic HTML\n\nBefore reaching for ARIA, use the right HTML element:\n\n| Instead of... | Use... | You get for free... |\n|--------------|--------|---------------------|\n| `\u003Cdiv onClick>` | `\u003Cbutton>` | Focus, Enter\u002FSpace activation, role announcement |\n| `\u003Cdiv>` for navigation | `\u003Cnav>` | Landmark for screen reader navigation |\n| `\u003Cspan>` for heading | `\u003Ch1>`-`\u003Ch6>` | Document outline, heading navigation |\n| `\u003Cdiv>` for list | `\u003Cul>\u002F\u003Col>` | List count announcement, list navigation |\n| `\u003Cdiv>` for input | `\u003Cinput>` + `\u003Clabel>` | Label association, auto-focus, form submission |\n| `\u003Cdiv>` for table | `\u003Ctable>` | Row\u002Fcolumn navigation, header association |\n| Custom dropdown | `\u003Cselect>` or `\u003Cdetails>` | Keyboard navigation, screen reader support |\n\nSee [references\u002Faccessibility-patterns.md](references\u002Faccessibility-patterns.md) for comprehensive patterns.\n\n### Step 3: Design Keyboard Navigation\n\nEvery interactive element must be operable by keyboard alone:\n\n**Tab order:** Interactive elements should follow a logical reading order. Don't use `tabindex` values > 0 (they override the natural order). Use `tabindex=\"0\"` to add non-interactive elements to the tab order when needed, and `tabindex=\"-1\"` to make elements focusable programmatically but not in the tab sequence.\n\n**Focus visibility:** Focused elements must have a visible indicator. Never `outline: none` without providing an alternative. Use `:focus-visible` (shows focus ring only for keyboard users, not mouse clicks).\n\n**Keyboard shortcuts for common patterns:**\n\n| Pattern | Keys |\n|---------|------|\n| Buttons | Enter or Space to activate |\n| Links | Enter to follow |\n| Menus | Arrow keys to navigate, Enter to select, Escape to close |\n| Tabs | Arrow keys between tabs, Tab to move focus into panel |\n| Modals | Tab cycles within modal (focus trap), Escape to close |\n| Autocomplete | Arrow keys to navigate suggestions, Enter to select |\n\n### Step 4: Design Focus Management\n\nFocus management is critical for dynamic content. When the page changes without a full reload, focus must move to the right place:\n\n| Scenario | Focus should go to... |\n|----------|----------------------|\n| Modal opens | First focusable element inside the modal |\n| Modal closes | The element that triggered the modal |\n| Item deleted from list | Next item in list, or previous if last was deleted |\n| Error after form submit | First field with an error |\n| Page\u002Froute change | Main content area or page heading |\n| Toast notification | Do NOT move focus (announce with aria-live instead) |\n\n### Step 5: Handle Dynamic Content\n\nWhen content changes without page reload, screen readers need to be notified:\n\n**aria-live regions:**\n- `aria-live=\"polite\"` — Announce when the screen reader is idle (status messages, search results count)\n- `aria-live=\"assertive\"` — Interrupt immediately (errors, critical alerts)\n\n**Common announcements:**\n- Form errors: \"3 errors found. First error: Email is required.\"\n- Search results: \"24 results found for 'react'.\"\n- Toast: \"Settings saved successfully.\"\n- Loading: \"Loading your dashboard...\" → \"Dashboard loaded.\"\n\n### Step 6: Ensure Visual Accessibility\n\n**Color contrast:**\n- Normal text: 4.5:1 ratio minimum (AA)\n- Large text (18px+ or 14px+ bold): 3:1 ratio minimum (AA)\n- UI components and graphical objects: 3:1 ratio minimum\n- Don't convey information by color alone — use icons, patterns, or text labels alongside color\n\n**Typography and spacing:**\n- Body text: minimum 16px (1rem)\n- Line height: at least 1.5 for body text\n- Paragraph spacing: at least 2x font size\n- Users must be able to zoom to 200% without horizontal scrolling\n\n### Step 7: Validate\n\nAutomated testing catches ~30% of accessibility issues. Manual testing catches the rest.\n\n**Automated:**\n- Run axe-core or Lighthouse accessibility audit\n- Add eslint-plugin-jsx-a11y to catch common React issues at build time\n- Include @axe-core\u002Freact in development mode for runtime warnings\n\n**Manual:**\n- [ ] Navigate the entire flow using only keyboard (no mouse)\n- [ ] Test with a screen reader (VoiceOver on Mac, NVDA on Windows)\n- [ ] Verify all images have meaningful alt text (or `alt=\"\"` for decorative)\n- [ ] Verify color contrast with a contrast checker tool\n- [ ] Test at 200% zoom — no horizontal scroll, no overlapping text\n- [ ] Verify all form fields have associated labels\n- [ ] Verify error messages are announced to screen readers\n- [ ] Submit an invalid form: focus must move to the first error (or an error summary), not stay on the submit button\n\n## Principles Applied\n\n- **KISS**: Use native HTML first. Every custom ARIA widget is code you have to maintain and test.\n- **Progressive enhancement**: Build the accessible version first, then enhance for visual design. Not the other way around.\n- **DRY**: Accessible patterns in shared components (Button, Input, Modal) mean every consumer gets accessibility for free.\n- **Defense in depth**: Automated linting + automated testing + manual testing. No single method catches everything.\n","# Accessibility Design\n\nBuild accessibility into applications from the start. Accessibility is not a feature — it's a quality attribute, like performance or security. Retrofitting it is 10x harder than building it in.\n\n## Core Principle\n\n**Use semantic HTML first, ARIA second, custom JavaScript last.** A native `\u003Cbutton>` gives you keyboard support, focus management, and screen reader announcement for free. A `\u003Cdiv onClick>` gives you none of that and requires manual reimplementation of every behavior the browser provides natively.\n\n## Workflow\n\n### Step 1: Understand the Requirements\n\nDetermine the target compliance level:\n\n- **WCAG 2.1 Level A**: Minimum baseline (avoid lawsuits, but still inaccessible)\n- **WCAG 2.1 Level AA**: Industry standard (recommended minimum for all projects)\n- **WCAG 2.2 Level AA**: Current standard, adds mobile and cognitive accessibility\n- **WCAG Level AAA**: Aspirational — few sites achieve this fully\n\nFor most projects, **target WCAG 2.1 AA** as the minimum. Level AAA for specific features where feasible.\n\n### Step 2: Apply Semantic HTML\n\nBefore reaching for ARIA, use the right HTML element:\n\n| Instead of... | Use... | You get for free... |\n|--------------|--------|---------------------|\n| `\u003Cdiv onClick>` | `\u003Cbutton>` | Focus, Enter\u002FSpace activation, role announcement |\n| `\u003Cdiv>` for navigation | `\u003Cnav>` | Landmark for screen reader navigation |\n| `\u003Cspan>` for heading | `\u003Ch1>`-`\u003Ch6>` | Document outline, heading navigation |\n| `\u003Cdiv>` for list | `\u003Cul>\u002F\u003Col>` | List count announcement, list navigation |\n| `\u003Cdiv>` for input | `\u003Cinput>` + `\u003Clabel>` | Label association, auto-focus, form submission |\n| `\u003Cdiv>` for table | `\u003Ctable>` | Row\u002Fcolumn navigation, header association |\n| Custom dropdown | `\u003Cselect>` or `\u003Cdetails>` | Keyboard navigation, screen reader support |\n\nSee [references\u002Faccessibility-patterns.md](references\u002Faccessibility-patterns.md) for comprehensive patterns.\n\n### Step 3: Design Keyboard Navigation\n\nEvery interactive element must be operable by keyboard alone:\n\n**Tab order:** Interactive elements should follow a logical reading order. Don't use `tabindex` values > 0 (they override the natural order). Use `tabindex=\"0\"` to add non-interactive elements to the tab order when needed, and `tabindex=\"-1\"` to make elements focusable programmatically but not in the tab sequence.\n\n**Focus visibility:** Focused elements must have a visible indicator. Never `outline: none` without providing an alternative. Use `:focus-visible` (shows focus ring only for keyboard users, not mouse clicks).\n\n**Keyboard shortcuts for common patterns:**\n\n| Pattern | Keys |\n|---------|------|\n| Buttons | Enter or Space to activate |\n| Links | Enter to follow |\n| Menus | Arrow keys to navigate, Enter to select, Escape to close |\n| Tabs | Arrow keys between tabs, Tab to move focus into panel |\n| Modals | Tab cycles within modal (focus trap), Escape to close |\n| Autocomplete | Arrow keys to navigate suggestions, Enter to select |\n\n### Step 4: Design Focus Management\n\nFocus management is critical for dynamic content. When the page changes without a full reload, focus must move to the right place:\n\n| Scenario | Focus should go to... |\n|----------|----------------------|\n| Modal opens | First focusable element inside the modal |\n| Modal closes | The element that triggered the modal |\n| Item deleted from list | Next item in list, or previous if last was deleted |\n| Error after form submit | First field with an error |\n| Page\u002Froute change | Main content area or page heading |\n| Toast notification | Do NOT move focus (announce with aria-live instead) |\n\n### Step 5: Handle Dynamic Content\n\nWhen content changes without page reload, screen readers need to be notified:\n\n**aria-live regions:**\n- `aria-live=\"polite\"` — Announce when the screen reader is idle (status messages, search results count)\n- `aria-live=\"assertive\"` — Interrupt immediately (errors, critical alerts)\n\n**Common announcements:**\n- Form errors: \"3 errors found. First error: Email is required.\"\n- Search results: \"24 results found for 'react'.\"\n- Toast: \"Settings saved successfully.\"\n- Loading: \"Loading your dashboard...\" → \"Dashboard loaded.\"\n\n### Step 6: Ensure Visual Accessibility\n\n**Color contrast:**\n- Normal text: 4.5:1 ratio minimum (AA)\n- Large text (18px+ or 14px+ bold): 3:1 ratio minimum (AA)\n- UI components and graphical objects: 3:1 ratio minimum\n- Don't convey information by color alone — use icons, patterns, or text labels alongside color\n\n**Typography and spacing:**\n- Body text: minimum 16px (1rem)\n- Line height: at least 1.5 for body text\n- Paragraph spacing: at least 2x font size\n- Users must be able to zoom to 200% without horizontal scrolling\n\n### Step 7: Validate\n\nAutomated testing catches ~30% of accessibility issues. Manual testing catches the rest.\n\n**Automated:**\n- Run axe-core or Lighthouse accessibility audit\n- Add eslint-plugin-jsx-a11y to catch common React issues at build time\n- Include @axe-core\u002Freact in development mode for runtime warnings\n\n**Manual:**\n- [ ] Navigate the entire flow using only keyboard (no mouse)\n- [ ] Test with a screen reader (VoiceOver on Mac, NVDA on Windows)\n- [ ] Verify all images have meaningful alt text (or `alt=\"\"` for decorative)\n- [ ] Verify color contrast with a contrast checker tool\n- [ ] Test at 200% zoom — no horizontal scroll, no overlapping text\n- [ ] Verify all form fields have associated labels\n- [ ] Verify error messages are announced to screen readers\n- [ ] Submit an invalid form: focus must move to the first error (or an error summary), not stay on the submit button\n\n## Principles Applied\n\n- **KISS**: Use native HTML first. Every custom ARIA widget is code you have to maintain and test.\n- **Progressive enhancement**: Build the accessible version first, then enhance for visual design. Not the other way around.\n- **DRY**: Accessible patterns in shared components (Button, Input, Modal) mean every consumer gets accessibility for free.\n- **Defense in depth**: Automated linting + automated testing + manual testing. No single method catches everything.\n",{"name":5,"description":7},"main","800dc9ad0ca2914d6ad15b8c5159d9b57bb104c2","plugins\u002Ffrontend\u002Fskills\u002Faccessibility-design","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills","https:\u002F\u002Fgithub.com\u002FSWEStash","A stash of things we felt like building","2026-11-12 00:14:33",{"source":8,"skillName":5,"commands":65,"prompt":75,"zipAvailable":76},[66,69,72],{"tool":67,"command":68},"npx","npx skills add SWEStash\u002Fswe-workflow-skills --skill accessibility-design",{"tool":70,"command":71},"bunx","bunx skills add SWEStash\u002Fswe-workflow-skills --skill accessibility-design",{"tool":73,"command":74},"pnpm","pnpm dlx skills add SWEStash\u002Fswe-workflow-skills --skill accessibility-design","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fplugins\u002Ffrontend\u002Fskills\u002Faccessibility-design\u002FSKILL.md",true,[78,84],{"path":79,"resourceType":80,"resourceTypeDesc":81,"sizeBytes":82,"sourceHtmlUrl":83},"evals\u002Fevals.json","REFERENCE","参考文档",4906,"https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fplugins\u002Ffrontend\u002Fskills\u002Faccessibility-design\u002Fevals\u002Fevals.json",{"path":85,"resourceType":80,"resourceTypeDesc":81,"sizeBytes":86,"sourceHtmlUrl":87},"references\u002Faccessibility-patterns.md",9451,"https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fplugins\u002Ffrontend\u002Fskills\u002Faccessibility-design\u002Freferences\u002Faccessibility-patterns.md",[89,128,155,178,204,234],{"skillNo":90,"name":91,"nameZh":6,"description":92,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":93,"categories":94,"keywords":108,"publishedAt":52},"01M6JQFADV3T1MS9V1BNZS1232","writing-skills","Use when authoring, editing, or reviewing a skill in this library — a new SKILL.md, one that under-triggers, or hardening an existing one. Covers description and listing-budget rules, frontmatter, progressive disclosure, the 3-eval rule, and pressure-testing against rationalizations.","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Fwriting-skills\u002FSKILL.md",[95,98,101,102,105],{"categoryNo":96,"categoryName":97,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":99,"categoryName":100,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":103,"categoryName":104,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000036","内容创作者",{"categoryNo":106,"categoryName":107,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000040","财务",[109,110,111,112,113,114,115,116,117,118,119,120,41,121,122,123,124,125,126,127],"writing","writing skills","testing","eval","write","edit","Budget","authoring","new skill","library","frontmatter","editing","use","Existing","Rules","write a skill","when","listing","progressive disclosure",{"skillNo":129,"name":130,"nameZh":6,"description":131,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":132,"categories":133,"keywords":135,"publishedAt":52},"01M6JQF5DGMXPMQQVZBP8DH9SY","working-agreement","Define and validate how a multi-session project is run — where plans, status and decisions live, session routines, new work, milestone close. README\u002FCONTRIBUTING → project-documentation.","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Fworking-agreement\u002FSKILL.md",[134],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[136,137,138,139,140,141,142,143,144,145,146,147,148,149,150,151,152,153,41,154],"working agreement","project","definition of done","done","milestone","documentation","work","progress","how","contributing","close","run","sync","status","live","do","README","session","routines",{"skillNo":156,"name":157,"nameZh":6,"description":158,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":159,"categories":160,"keywords":162,"publishedAt":52},"01M6JQF0SMRHN82RBSWMABC4J0","verification-before-completion","Evidence gate before any claim that work is done, fixed, passing, or deployed. Route here when a message declares the work finished or asks to commit, push, merge, ship, or close it out, including a brief sign-off, and before git-workflow or release-management act on it. Writing the commit message or PR text itself → git-workflow.","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Fverification-before-completion\u002FSKILL.md",[161],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[163,164,165,166,167,168,109,169,139,170,49,171,142,172,146,173,174,175,176,177],"verification","verification before completion","brief","ready","fix","claim","workflow","commit","route","message","merge","release","git","act","ship",{"skillNo":179,"name":180,"nameZh":6,"description":181,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":182,"categories":183,"keywords":187,"publishedAt":52},"01M6JQEVGE9NJZ11DV60AE6VWC","ui-ux-design","Design user experiences from an engineer's perspective — user flows, wireframes, interaction patterns, responsive strategy, navigation, loading\u002Ferror\u002Fempty states. Triggers: design the UI, user flow, wireframe, how should this screen look, loading state, error state, empty state, responsive design, navigation, page layout, form design, mockup.","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Fui-ux-design\u002FSKILL.md",[184,185,186],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":27,"categoryName":28,"taxonomyType":29,"taxonomyTypeDesc":30},[32,188,189,190,191,192,193,194,195,196,197,198,144,38,199,44,200,201,202,203],"ux","ui","ui ux design","error","states","loading","flows","engineer","interaction","layout","responsive design","flow","mockup","responsive","form","page",{"skillNo":205,"name":206,"nameZh":6,"description":207,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":208,"categories":209,"keywords":214,"publishedAt":52},"01M6JQEN4HVFTZWQYWGTDS76K9","threat-modeling","Design-time security analysis of a system or feature before it's built — trust boundaries, attack surface, STRIDE per element, abuse cases, prioritized mitigations that become security requirements. Triggers: threat model, STRIDE, trust boundary, attack surface, what could go wrong security-wise, security design review, abuse case, secure this design, security requirements. Reviewing EXISTING code\u002Fconfig for vulnerabilities → security-audit; use this skill while the design is still on the whiteboard.","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Fthreat-modeling\u002FSKILL.md",[210,211],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":212,"categoryName":213,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000030","开发工程师",[215,216,217,218,219,220,32,221,222,223,224,225,226,227,228,229,230,231,232,233],"modeling","threat modeling","threat","model","time","element","whiteboard","security analysis","analysis","code","review","threat model","audit","security-audit","secure","config","go","security","trust",{"skillNo":235,"name":236,"nameZh":6,"description":237,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":238,"categories":239,"keywords":245,"publishedAt":52},"01M6JQEFT7VT3FQM16170EG9FW","test-suite-design","Design comprehensive test suites for existing code — strategy across unit\u002Fintegration\u002Fe2e, fixtures, factories, helpers. Triggers: add tests, write tests for, increase coverage, test this module, testing strategy, test plan, what tests do I need, test infrastructure, test helpers, this has no tests. Not for TDD — use tdd-workflow.","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Ftest-suite-design\u002FSKILL.md",[240,241,242,243,244],{"categoryNo":96,"categoryName":97,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":212,"categoryName":213,"taxonomyType":29,"taxonomyTypeDesc":30},{"categoryNo":27,"categoryName":28,"taxonomyType":29,"taxonomyTypeDesc":30},[32,246,247,248,249,250,111,251,252,169,224,253,254,113,255,256,151,257,258,41],"test suite","test","test suite design","coverage","unit","write tests","testing strategy","across","plan","add","infrastructure","test plan","for"]