[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6C44WNR4Z7P6FVCV9025548":3,"skill-same:01M6C44WNR4Z7P6FVCV9025548":77},{"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":33,"publishedAt":51,"linkOnly":52,"markdownContent":53,"markdownBody":54,"frontMatter":55,"refName":56,"commitSha":57,"skillDirectory":58,"forksCount":59,"repositoryHtmlUrl":60,"repositoryHomepageUrl":6,"ownerHtmlUrl":61,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":62,"install":63,"resources":76},"01M6C44WNR4Z7P6FVCV9025548","frontend-design",null,"Guide for creating distinctive UI designs that avoid generic templates. Use when designing new UI components, screens, or evaluating designs for uniqueness and purpose. DO NOT USE FOR: architecture decisions or SOLID evaluation (use software-architecture), open-ended exploration (use brainstorming), or React test strategies (use ui-testing).","Grimblaz\u002Fagent-orchestra","Grimblaz","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F74755849?v=4","01M6C430M9XZDHGHPWQVTQ3KMA","01M6C430RJY3MMX0QAZ3X8DR3Y",3,"MIT","https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Ffrontend-design\u002FSKILL.md",[17,22,25,28],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":23,"categoryName":24,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000009","前端开发",{"categoryNo":26,"categoryName":27,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":29,"categoryName":30,"taxonomyType":31,"taxonomyTypeDesc":32},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50],"frontend","design","frontend design","use","testing","guide","decisions","open","templates","Evaluation","ui","brainstorming","architecture","react","components","test","solid","2026-11-10 10:12:30",false,"---\nname: frontend-design\ndescription: \"Guide for creating distinctive UI designs that avoid generic templates. Use when designing new UI components, screens, or evaluating designs for uniqueness and purpose. DO NOT USE FOR: architecture decisions or SOLID evaluation (use software-architecture), open-ended exploration (use brainstorming), or React test strategies (use ui-testing).\"\n---\n\n# Frontend Design Skill\n\nGuide for creating distinctive, purposeful UI designs that avoid cookie-cutter patterns.\n\n## When to Use\n\n- Designing new UI components or screens\n- Evaluating existing designs for uniqueness\n- Reviewing designs that feel \"generic\"\n- Creating brand-aligned interfaces\n- Building memorable user experiences\n\n## Core Principles\n\n### 1. Purpose Over Pattern\n\nEvery design decision should answer: \"Why this, not something else?\"\n\n- **Bad**: Using a card grid because it's common\n- **Good**: Using a card grid because content is comparable and scannable\n\n### 2. Distinctive Identity\n\nYour UI should be recognizable without the logo.\n\nQuestions to ask:\n\n- Would users recognize this as our product?\n- What makes this different from competitors?\n- Does this reflect our brand personality?\n\n### 3. Intentional Defaults\n\nDon't accept framework defaults blindly.\n\n```\n[CUSTOMIZE] Review these common defaults in your stack:\n- Border radius values\n- Shadow depths\n- Spacing scales\n- Color applications\n- Typography scales\n```\n\n## Design Review Checklist\n\n### Visual Distinction\n\n- [ ] Color palette goes beyond primary\u002Fsecondary\u002Fneutral\n- [ ] Typography creates clear hierarchy (not just size changes)\n- [ ] Spacing creates intentional rhythm (not uniform gaps)\n- [ ] Icons have consistent style\u002Fweight\u002Fmeaning\n- [ ] Micro-interactions add personality\n\n### Purposeful Patterns\n\n- [ ] Each component solves a specific user problem\n- [ ] Layout serves content structure (not vice versa)\n- [ ] Navigation reflects user mental models\n- [ ] Empty states guide users (not just \"No data\")\n- [ ] Loading states reduce perceived wait time\n\n### Avoiding Generic Traps\n\n- [ ] Not using component library defaults unchanged\n- [ ] Headers aren't just logo-left, nav-right\n- [ ] Forms have personality beyond labels + inputs\n- [ ] Buttons vary by importance (not just color)\n- [ ] Data displays fit the data (not just tables)\n\n## Breaking Generic Patterns\n\n### Instead of Generic Cards\n\nConsider:\n\n- Asymmetric layouts for visual interest\n- Inline expansion vs. navigation\n- Progressive disclosure of details\n- Content-specific shapes (not all rectangles)\n\n### Instead of Generic Forms\n\nConsider:\n\n- Conversational flows for complex inputs\n- Smart defaults that reduce input\n- Inline validation with helpful context\n- Progress indication for multi-step\n\n### Instead of Generic Tables\n\nConsider:\n\n- Is a table the right pattern at all?\n- Grouped\u002Fnested rows for hierarchy\n- Inline actions vs. row selection\n- Responsive transformations (not just scroll)\n\n### Instead of Generic Dashboards\n\nConsider:\n\n- User goals, not data availability\n- Actionable metrics, not vanity metrics\n- Contextual insights, not just numbers\n- Personalization based on role\u002Fusage\n\n## Design Language Documentation\n\n[CUSTOMIZE] Document your design language:\n\n```markdown\n## Our Design Personality\n\n- [Define 3-5 adjectives: e.g., \"Professional but approachable\"]\n\n## Signature Elements\n\n- [Unique visual elements that define your brand]\n\n## Intentional Constraints\n\n- [Self-imposed rules that create consistency]\n```\n\n## Review Questions\n\nBefore shipping any design:\n\n1. **Is this recognizable?** Would users know it's from us?\n2. **Is this purposeful?** Can we justify every choice?\n3. **Is this necessary?** Does it solve a real problem?\n4. **Is this accessible?** Can all users interact with it?\n5. **Is this maintainable?** Can we scale this pattern?\n\n## Resources\n\n[CUSTOMIZE] Add your project's design resources:\n\n- Design system documentation\n- Brand guidelines\n- Component library\n- Design tokens\n- Approved patterns and templates\n\n## Supplement Skills\n\nA **supplement skill** is a project-specific skill that layers additional constraints, themes, or identity guidance on top of this hub skill. When a project has one, load both together — the hub skill provides the universal design principles and the supplement narrows them for the project.\n\n**Naming convention**: `{project}-{hub-skill-name}` — for example, `windgust-frontend-design` supplements `frontend-design`.\n\n**When to create one**: When your project has a unique visual identity, brand-specific design tokens, or theme customizations that go beyond what the `[CUSTOMIZE]` markers in this skill cover. If you find yourself adding the same project-specific guidance to every session, extract it into a supplement.\n\n**Supplement ≠ replacement**: A supplement adds to the hub skill; it does not replace it. Load both together. Do not contradict hub skill defaults — extend or constrain them instead.\n\n### Worked Example\n\n`windgust-frontend-design` in `Grimblaz-and-Friends\u002FWindgust-Questbook` supplements this skill with the Windgust brand personality, color palette, and component conventions specific to that project.\n\n### Supplement SKILL.md Template\n\n> **Note**: This template is pre-filled for `frontend-design` supplements. When creating a supplement for a different hub skill, replace every occurrence of `frontend-design` with your hub-skill name.\n\n```markdown\n---\nname: {project}-frontend-design\ndescription: Supplements `frontend-design` with {project} brand identity, design tokens, and visual conventions. Use when designing {project} UI components or screens alongside the `frontend-design` hub skill. DO NOT USE FOR: standalone sessions without `frontend-design` loaded (this is a supplement skill; always load `frontend-design` alongside).\n---\n\n# {Project} Frontend Design Supplement\n\nProject-specific design constraints that layer on top of the `frontend-design` hub skill.\n\n## Brand Identity\n\n[CUSTOMIZE] Document brand personality, color palette, and typography rules.\n\n## Design Tokens\n\n[CUSTOMIZE] List token overrides that go beyond `frontend-design` defaults.\n\n## Component Conventions\n\n[CUSTOMIZE] List component conventions that extend `frontend-design` hub skill guidance.\n\n## When to Use\n\n- [CUSTOMIZE] List the conditions when this supplement should be loaded (alongside `frontend-design`).\n\n## Gotchas\n\n| Trigger                          | Gotcha                      | Fix                       |\n| -------------------------------- | --------------------------- | ------------------------- |\n| [CUSTOMIZE] Observable condition | [CUSTOMIZE] What goes wrong | [CUSTOMIZE] How to fix it |\n```\n\n## Gotchas\n\n\u003C!-- [CUSTOMIZE] Add project-specific anti-patterns below -->\n\n| Trigger                                                                            | Gotcha                                                                               | Fix                                                                                              |\n| ---------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------ |\n| Keeping every component library default (border-radius, shadow, spacing) unchanged | Design feels generic — indistinguishable from any other app using the same framework | Audit defaults; make ≥3 intentional overrides per component type                                 |\n| Header layout is logo-left, nav-right without questioning it                       | The invisible default — identical to every SaaS app                                  | Evaluate navigation mental models; consider sidebar, bottom nav, or contextual nav               |\n| \"It's common\" or \"everyone does it\" as design justification                        | Common ≠ purposeful; pattern chosen without intent                                   | Force \"why this, not something else?\" using §1 Purpose Over Pattern                              |\n| Reaching for a table when asked to \"show data\"                                     | Tables rarely fit mobile; rarely surface hierarchy                                   | Ask \"Is a table the right pattern?\" before building; consider cards, timelines, or grouped lists |\n| Shipping without answering the 5 review questions                                  | UI may be polished but not recognizable, purposeful, or accessible                   | Answer all 5 review questions before declaring design done                                       |\n","# Frontend Design Skill\n\nGuide for creating distinctive, purposeful UI designs that avoid cookie-cutter patterns.\n\n## When to Use\n\n- Designing new UI components or screens\n- Evaluating existing designs for uniqueness\n- Reviewing designs that feel \"generic\"\n- Creating brand-aligned interfaces\n- Building memorable user experiences\n\n## Core Principles\n\n### 1. Purpose Over Pattern\n\nEvery design decision should answer: \"Why this, not something else?\"\n\n- **Bad**: Using a card grid because it's common\n- **Good**: Using a card grid because content is comparable and scannable\n\n### 2. Distinctive Identity\n\nYour UI should be recognizable without the logo.\n\nQuestions to ask:\n\n- Would users recognize this as our product?\n- What makes this different from competitors?\n- Does this reflect our brand personality?\n\n### 3. Intentional Defaults\n\nDon't accept framework defaults blindly.\n\n```\n[CUSTOMIZE] Review these common defaults in your stack:\n- Border radius values\n- Shadow depths\n- Spacing scales\n- Color applications\n- Typography scales\n```\n\n## Design Review Checklist\n\n### Visual Distinction\n\n- [ ] Color palette goes beyond primary\u002Fsecondary\u002Fneutral\n- [ ] Typography creates clear hierarchy (not just size changes)\n- [ ] Spacing creates intentional rhythm (not uniform gaps)\n- [ ] Icons have consistent style\u002Fweight\u002Fmeaning\n- [ ] Micro-interactions add personality\n\n### Purposeful Patterns\n\n- [ ] Each component solves a specific user problem\n- [ ] Layout serves content structure (not vice versa)\n- [ ] Navigation reflects user mental models\n- [ ] Empty states guide users (not just \"No data\")\n- [ ] Loading states reduce perceived wait time\n\n### Avoiding Generic Traps\n\n- [ ] Not using component library defaults unchanged\n- [ ] Headers aren't just logo-left, nav-right\n- [ ] Forms have personality beyond labels + inputs\n- [ ] Buttons vary by importance (not just color)\n- [ ] Data displays fit the data (not just tables)\n\n## Breaking Generic Patterns\n\n### Instead of Generic Cards\n\nConsider:\n\n- Asymmetric layouts for visual interest\n- Inline expansion vs. navigation\n- Progressive disclosure of details\n- Content-specific shapes (not all rectangles)\n\n### Instead of Generic Forms\n\nConsider:\n\n- Conversational flows for complex inputs\n- Smart defaults that reduce input\n- Inline validation with helpful context\n- Progress indication for multi-step\n\n### Instead of Generic Tables\n\nConsider:\n\n- Is a table the right pattern at all?\n- Grouped\u002Fnested rows for hierarchy\n- Inline actions vs. row selection\n- Responsive transformations (not just scroll)\n\n### Instead of Generic Dashboards\n\nConsider:\n\n- User goals, not data availability\n- Actionable metrics, not vanity metrics\n- Contextual insights, not just numbers\n- Personalization based on role\u002Fusage\n\n## Design Language Documentation\n\n[CUSTOMIZE] Document your design language:\n\n```markdown\n## Our Design Personality\n\n- [Define 3-5 adjectives: e.g., \"Professional but approachable\"]\n\n## Signature Elements\n\n- [Unique visual elements that define your brand]\n\n## Intentional Constraints\n\n- [Self-imposed rules that create consistency]\n```\n\n## Review Questions\n\nBefore shipping any design:\n\n1. **Is this recognizable?** Would users know it's from us?\n2. **Is this purposeful?** Can we justify every choice?\n3. **Is this necessary?** Does it solve a real problem?\n4. **Is this accessible?** Can all users interact with it?\n5. **Is this maintainable?** Can we scale this pattern?\n\n## Resources\n\n[CUSTOMIZE] Add your project's design resources:\n\n- Design system documentation\n- Brand guidelines\n- Component library\n- Design tokens\n- Approved patterns and templates\n\n## Supplement Skills\n\nA **supplement skill** is a project-specific skill that layers additional constraints, themes, or identity guidance on top of this hub skill. When a project has one, load both together — the hub skill provides the universal design principles and the supplement narrows them for the project.\n\n**Naming convention**: `{project}-{hub-skill-name}` — for example, `windgust-frontend-design` supplements `frontend-design`.\n\n**When to create one**: When your project has a unique visual identity, brand-specific design tokens, or theme customizations that go beyond what the `[CUSTOMIZE]` markers in this skill cover. If you find yourself adding the same project-specific guidance to every session, extract it into a supplement.\n\n**Supplement ≠ replacement**: A supplement adds to the hub skill; it does not replace it. Load both together. Do not contradict hub skill defaults — extend or constrain them instead.\n\n### Worked Example\n\n`windgust-frontend-design` in `Grimblaz-and-Friends\u002FWindgust-Questbook` supplements this skill with the Windgust brand personality, color palette, and component conventions specific to that project.\n\n### Supplement SKILL.md Template\n\n> **Note**: This template is pre-filled for `frontend-design` supplements. When creating a supplement for a different hub skill, replace every occurrence of `frontend-design` with your hub-skill name.\n\n```markdown\n---\nname: {project}-frontend-design\ndescription: Supplements `frontend-design` with {project} brand identity, design tokens, and visual conventions. Use when designing {project} UI components or screens alongside the `frontend-design` hub skill. DO NOT USE FOR: standalone sessions without `frontend-design` loaded (this is a supplement skill; always load `frontend-design` alongside).\n---\n\n# {Project} Frontend Design Supplement\n\nProject-specific design constraints that layer on top of the `frontend-design` hub skill.\n\n## Brand Identity\n\n[CUSTOMIZE] Document brand personality, color palette, and typography rules.\n\n## Design Tokens\n\n[CUSTOMIZE] List token overrides that go beyond `frontend-design` defaults.\n\n## Component Conventions\n\n[CUSTOMIZE] List component conventions that extend `frontend-design` hub skill guidance.\n\n## When to Use\n\n- [CUSTOMIZE] List the conditions when this supplement should be loaded (alongside `frontend-design`).\n\n## Gotchas\n\n| Trigger                          | Gotcha                      | Fix                       |\n| -------------------------------- | --------------------------- | ------------------------- |\n| [CUSTOMIZE] Observable condition | [CUSTOMIZE] What goes wrong | [CUSTOMIZE] How to fix it |\n```\n\n## Gotchas\n\n\u003C!-- [CUSTOMIZE] Add project-specific anti-patterns below -->\n\n| Trigger                                                                            | Gotcha                                                                               | Fix                                                                                              |\n| ---------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------ |\n| Keeping every component library default (border-radius, shadow, spacing) unchanged | Design feels generic — indistinguishable from any other app using the same framework | Audit defaults; make ≥3 intentional overrides per component type                                 |\n| Header layout is logo-left, nav-right without questioning it                       | The invisible default — identical to every SaaS app                                  | Evaluate navigation mental models; consider sidebar, bottom nav, or contextual nav               |\n| \"It's common\" or \"everyone does it\" as design justification                        | Common ≠ purposeful; pattern chosen without intent                                   | Force \"why this, not something else?\" using §1 Purpose Over Pattern                              |\n| Reaching for a table when asked to \"show data\"                                     | Tables rarely fit mobile; rarely surface hierarchy                                   | Ask \"Is a table the right pattern?\" before building; consider cards, timelines, or grouped lists |\n| Shipping without answering the 5 review questions                                  | UI may be polished but not recognizable, purposeful, or accessible                   | Answer all 5 review questions before declaring design done                                       |\n",{"name":5,"description":7},"main","d5486aacc32c9ca1b07173cfd530f8fe75c29e58","skills\u002Ffrontend-design",0,"https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra","https:\u002F\u002Fgithub.com\u002FGrimblaz","2026-08-16 01:12:46",{"source":8,"skillName":5,"commands":64,"prompt":74,"zipAvailable":75},[65,68,71],{"tool":66,"command":67},"npx","npx skills add Grimblaz\u002Fagent-orchestra --skill frontend-design",{"tool":69,"command":70},"bunx","bunx skills add Grimblaz\u002Fagent-orchestra --skill frontend-design",{"tool":72,"command":73},"pnpm","pnpm dlx skills add Grimblaz\u002Fagent-orchestra --skill frontend-design","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Ffrontend-design\u002FSKILL.md",true,[],[78,103,128,144,170,184],{"skillNo":79,"name":80,"nameZh":6,"description":81,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":82,"categories":83,"keywords":86,"publishedAt":51},"01M6C48YMJVFHM7DVGG1WWW5RJ","webapp-testing","Playwright end-to-end testing guidance for web apps, with practical patterns and setup steps. Use when creating or improving browser-based E2E coverage, test stability, and CI execution. DO NOT USE FOR: React component tests (use ui-testing), canvas game interaction (use browser-canvas-testing), TDD workflow (use test-driven-development), debugging failures (use systematic-debugging), or randomized property tests (use property-based-testing).","https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fwebapp-testing\u002FSKILL.md",[84,85],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":23,"categoryName":24,"taxonomyType":20,"taxonomyTypeDesc":21},[38,87,88,89,90,91,92,49,93,47,94,95,96,97,98,99,100,101,102,37],"webapp testing","webapp","canvas","tdd","workflow","playwright","web","component","debugging","development","browser","ci","execution","e2e","game","coverage",{"skillNo":104,"name":105,"nameZh":6,"description":106,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":107,"categories":108,"keywords":109,"publishedAt":51},"01M6C48TNNP2KCSQXV8YK7SK49","verification-before-completion","Evidence-based verification checklist before marking work complete. Use before PRs, releases, marking tickets done, or any \"I'm finished\" declaration; also when naming a baseline commit for a differential suite claim, when designing a mutation campaign or red-run evidence, when making an absence claim, a universal claim, or a one-time demonstration offered as a standing guarantee, when attributing a measurement or claiming a sweep or verification loop is complete, and when stating what a check or a CI suite will do about a change. DO NOT USE FOR: post-merge cleanup or archival (use post-pr-review) or processing GitHub review comments (use code-review-intake).","https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fverification-before-completion\u002FSKILL.md",[],[110,111,112,113,114,115,116,117,118,119,120,121,98,122,123,124,125,37,126,127],"verification","verification before completion","review","change","commit","merge","pr","cleanup","run","code","code-review","intake","loop","verification loop","work","check","evidence","campaign",{"skillNo":129,"name":130,"nameZh":6,"description":131,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":132,"categories":133,"keywords":134,"publishedAt":51},"01M6C48QZWNTP7JGKD32QZAKKX","validation-methodology","Reusable validation and review methodology for staged validation, failure triage, and prosecution-depth setup. Use when running validation ladders, triaging failures, or executing adversarial review passes. DO NOT USE FOR: CE Gate orchestration, specialist dispatch ownership, or step execution flow (keep those in Code-Conductor).","https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fvalidation-methodology\u002FSKILL.md",[],[135,136,137,112,138,139,140,141,119,142,99,37,143],"validation","methodology","validation methodology","triage","orchestration","setup","adversarial review","flow","dispatch",{"skillNo":145,"name":146,"nameZh":6,"description":147,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":148,"categories":149,"keywords":156,"publishedAt":51},"01M6C48MCAHG5Z79BJ369CRYRZ","upstream-onboarding","Shared opening-phase protocol for upstream agents (Experience-Owner, Solution-Designer, Issue-Planner) and Code-Conductor when invoked on an existing GitHub issue. Renders a scaled context brief and runs a standards check on inherited work at each phase boundary. Use when a user-invocable agent receives a request referencing an existing GitHub issue and must load solution-authoring and upstream-onboarding at the opening phase. DO NOT USE FOR: subagent dispatches (which already operate within an assessed session context); post-merge review (use post-pr-review); research or non-tree subagents.","https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fupstream-onboarding\u002FSKILL.md",[150,153],{"categoryNo":151,"categoryName":152,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":154,"categoryName":155,"taxonomyType":31,"taxonomyTypeDesc":32},"01JBSEEDCAT000000000000038","人力资源",[157,158,112,159,160,115,161,116,119,162,163,164,165,166,167,124,125,168,169,37],"onboarding","upstream onboarding","github","research","standards check","protocol","brief","boundary","designer","subagent","planner","user","session",{"skillNo":171,"name":172,"nameZh":6,"description":173,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":174,"categories":175,"keywords":180,"publishedAt":51},"01M6C48GPVE120TGPMD1CS365H","ui-testing","Resilient React component testing strategies focusing on user behavior. Use when writing or reviewing component-level React tests, fixing flaky component tests, or establishing React testing patterns. DO NOT USE FOR: Playwright E2E tests (use webapp-testing), canvas game interaction (use browser-canvas-testing), TDD workflow (use test-driven-development), debugging failures (use systematic-debugging), UI component design (use frontend-design), or randomized property tests (use property-based-testing).","https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fui-testing\u002FSKILL.md",[176,177,178,179],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":23,"categoryName":24,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":26,"categoryName":27,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":29,"categoryName":30,"taxonomyType":31,"taxonomyTypeDesc":32},[38,44,181,34,35,182,89,91,92,49,47,94,95,96,97,183,100,101,37,88],"ui testing","writing","testing patterns",{"skillNo":185,"name":186,"nameZh":6,"description":187,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":188,"categories":189,"keywords":192,"publishedAt":51},"01M6C48DRJ9XBDR2FW0W37DY53","ui-iteration","Reusable screenshot-driven UI polish workflow for iterative visual refinement. Use when improving layout, hierarchy, spacing, feedback, or Tailwind-based presentation through repeated review-and-adjust passes. DO NOT USE FOR: functional bug fixing, accessibility-only audits, or major redesign strategy work (use Code-Smith or frontend-design).","https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fui-iteration\u002FSKILL.md",[190,191],{"categoryNo":23,"categoryName":24,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":29,"categoryName":30,"taxonomyType":31,"taxonomyTypeDesc":32},[44,193,34,35,112,91,194,119,195,196,197,198,199,124,200,201,37,202],"ui iteration","accessibility","screenshot","Tailwind","polish","ui polish","feedback","redesign","strategy","only"]