[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6MGD3CDTJVV0ERJVFS63607":3,"skill-same:01M6MGD3CDTJVV0ERJVFS63607":78},{"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":28,"publishedAt":49,"linkOnly":50,"markdownContent":51,"markdownBody":52,"frontMatter":53,"refName":54,"commitSha":55,"skillDirectory":56,"forksCount":57,"repositoryHtmlUrl":58,"repositoryHomepageUrl":59,"ownerHtmlUrl":60,"ownerBlogUrl":61,"ownerDescription":62,"updatedAt":63,"install":64,"resources":77},"01M6MGD3CDTJVV0ERJVFS63607","ux-design",null,"Use when the user asks for UX, product flow, user journey, wireframes, usability, conversion, onboarding, checkout, signup, navigation, forms, state design, dashboard workflows, command palettes, settings, permissions, long-running task progress, admin\u002Finternal tools, activation, retention, or making an app easier to use over time. Designs and audits user experience flows, information architecture, content hierarchy, forms, onboarding, dashboards, settings, empty\u002Floading\u002Ferror\u002Fpermission\u002Fsuccess states, recovery paths, and repeated-use product ergonomics before visual polish. Pair with platform UI skills after the UX flow is clear.","hashgraph-online\u002Fawesome-codex-plugins","hashgraph-online","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F160371962?v=4","01M6CNB6NRJVNNGN14TR01Q6D3","HOL (Hashgraph Online)","01M6JT1HSKKG9V68KQAQGBA7XP",1575,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ff0d010c\u002Fstark\u002Fskills\u002Fux-design\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48],"ux design","ux","design","time","hierarchy","information architecture","ergonomics","information","paths","app","platform","signup","forms","usability","command","polish","ui","permissions","architecture","workflows","2026-11-10 10:12:30",false,"---\nname: ux-design\ndescription: Use when the user asks for UX, product flow, user journey, wireframes, usability, conversion, onboarding, checkout, signup, navigation, forms, state design, dashboard workflows, command palettes, settings, permissions, long-running task progress, admin\u002Finternal tools, activation, retention, or making an app easier to use over time. Designs and audits user experience flows, information architecture, content hierarchy, forms, onboarding, dashboards, settings, empty\u002Floading\u002Ferror\u002Fpermission\u002Fsuccess states, recovery paths, and repeated-use product ergonomics before visual polish. Pair with platform UI skills after the UX flow is clear.\n---\n\n# ux-design - product flow before pixels\n\nUse this skill when the product has to be understandable and usable, not just attractive. The output should make the user path clearer, reduce unnecessary decisions, and define states that survive real use.\n\n## What This Skill Can Do\n\n- Map core user journeys, task paths, branching flows, and recovery paths.\n- Define information architecture, navigation, labels, content groups, and page\u002Fscreen inventory.\n- Design onboarding, activation, checkout, signup, forms, settings, dashboards, command palettes, and internal workflows.\n- Specify empty, loading, error, permission, success, stale, retry, resume, and audit states.\n- Define task ergonomics: frequency, risk, cognitive load, control model, speed paths, error prevention, recovery, and evidence tasks.\n- Choose usable workflow patterns: guided setup, wizard with review, command surface, priority queue, master\u002Fdetail, monitoring board, workbench, settings, permission matrix, transparent checkout, task-led docs, agent progress, collaboration thread, and mobile priority stack.\n- Evaluate polished UI with heuristic review, cognitive walkthrough prompts, severity ranking, evidence, first repair, and re-check.\n- Validate usability with scenario tests for first-run, returning-user, error\u002Frecovery, keyboard-only, and mobile\u002Ftouch paths.\n- Audit an existing UI for usability, hierarchy, conversion, repeated-use friction, accessibility risks, and missing states.\n- Hand a compact UX decision brief to platform skills so visual design does not erase the product job.\n\n## Step 1 - Identify the job and user mode\n\nBefore designing screens, state the smallest useful context:\n\n- Primary job: what the user is trying to finish.\n- User mode: first-time, returning, power user, admin, buyer, creator, operator, or support.\n- Frequency: one-time, occasional, daily, or high-volume repeated use.\n- Risk: low-risk browse, reversible edit, money\u002Fdata\u002Fsecurity impact, or destructive action.\n\nIf any of these are unclear and materially affect the flow, ask one short question. If the answer is easy to infer from the request, infer it and continue.\n\nDo not interrogate the user with a product-strategy questionnaire before helping. The skill should make useful assumptions, name them briefly, and move.\n\n## Step 2 - Map the flow\n\nWrite the minimum useful path:\n\n1. Entry point\n2. First meaningful action\n3. Required decision\n4. Feedback after action\n5. Success state\n6. Recovery path when something fails\n\nPrefer fewer screens when the user is trying to finish one job. Prefer separate steps when the user is making risky, costly, or hard-to-reverse decisions.\n\n## Step 2.5 - Produce the UX decision brief\n\nBefore visual design or code, write a compact brief. Keep it short enough to pass into another skill:\n\n```md\nUX decision brief\n- Job: ...\n- User mode: ...\n- Frequency\u002Frisk: ...\n- Pattern: ...\n- Primary action: ...\n- Secondary actions: ...\n- Core path: entry -> action -> feedback -> success\n- Recovery path: ...\n- Required states: empty, loading, partial, error, permission, success, long-running\n- Handoff constraints: ...\n```\n\nThis brief is the contract. The platform skill may change visual treatment, but it must not erase the chosen job, action hierarchy, state coverage, or recovery path.\n\n## Step 2.6 - Produce the task ergonomics contract\n\nFor serious product UI, repeated-use workflows, risky actions, forms, checkout, dashboards, editors, agent runs, admin tools, settings, or any request that says \"usable\", \"ergonomic\", \"not only good looking\", or \"real product\", read `..\u002F..\u002Freferences\u002Fux-patterns\u002Ftask-ergonomics.md`.\n\nWrite the compact contract before visual design:\n\n```md\nTask ergonomics contract\n- Core task:\n- User mode:\n- Frequency\u002Frisk:\n- Success metric:\n- Cognitive load:\n- Control model:\n- Speed path:\n- Error prevention:\n- Recovery:\n- State matrix:\n- Evidence plan:\n```\n\nThis is stricter than the UX decision brief. It protects the tenth use, the error path, and the risky action path.\n\nFor forms, settings, checkout, onboarding, signup, admin configuration, filters, generation prompts, or any user input that can fail, also read `..\u002F..\u002Freferences\u002Fui-patterns\u002Fform-state-validation-system.md` before visual design or implementation. Add the form job, risk, pattern, field anatomy, validation timing, state model, preservation\u002Frecovery, review\u002Fconfirmation, schema\u002Flibrary ownership, accessibility, responsive behavior, and QA checks to the UX handoff.\n\nFor onboarding, activation, empty dashboards, no-results screens, setup\u002Fimport flows, permission gates, trial starts, workspace creation, or first project creation, read `..\u002F..\u002Freferences\u002Fux-patterns\u002Ffirst-run-empty-state-system.md` before visual design. Define user promise, first value action, minimum\u002Fdeferrable setup, sample\u002Fdemo content, empty-state type, CTAs, permission timing, progress\u002Fresume model, recovery states, contextual teaching, success handoff, and QA evidence.\n\nFor navigation, information architecture, app shells, docs platforms, dashboards, admin\u002Fsettings, workspaces, command palettes, breadcrumbs, tabs, or multi-route products, also read `..\u002F..\u002Freferences\u002Fui-patterns\u002Fnavigation-information-architecture.md` before visual design or implementation. Add the primary objects, route map, navigation model, current-location model, search\u002Fcommand model, breadcrumb\u002Ftab behavior, deep-link\u002Fstate model, route states, mobile replacement, focus\u002Fscroll restoration, and QA checks to the UX handoff.\n\n## Step 3 - Design the states\n\nEvery production UI needs these states:\n\n- Empty: what the user sees before data exists.\n- Loading: what changes while the system is working.\n- Partial: some data exists, some is missing.\n- Error: what failed, why it matters, and the next action.\n- Permission: what is blocked and how to request access.\n- Success: what happened and what the user can do next.\n- Long-running: progress, cancellation, retry, and resume behavior.\n\nDo not ship only the happy path.\n\nFor public demos and generated proof projects, include at least one non-happy state in the visible UI: an empty state, blocked permission, failed sync, queued job, retry panel, stale data banner, or partial result. This makes the output feel like a real product instead of a polished poster.\n\n## Step 3.5 - Choose the usability pattern\n\nFor serious product UI or any request that says \"usable\", \"not only good looking\", \"real product\", \"ergonomic\", \"dashboard\", \"editor\", \"checkout\", \"agent run\", \"settings\", \"permissions\", \"docs\", or \"mobile task\", read `..\u002F..\u002Freferences\u002Fux-patterns\u002Fusability-pattern-matrix.md` after `task-ergonomics.md`.\n\nWrite the compact pattern brief before visual design:\n\n```md\nUsability pattern brief\n- Product job:\n- User mode:\n- Frequency\u002Frisk:\n- Pattern chosen:\n- Why this pattern fits:\n- Primary action:\n- Secondary actions:\n- Speed path:\n- Error prevention:\n- Recovery path:\n- Required states:\n- Keyboard\u002Ftouch model:\n- Rejected patterns:\n- Evidence tasks:\n```\n\nThe selected pattern should reduce the riskiest failure mode. Reject patterns that optimize the wrong use, such as a marketing hero for repeated operations, a wizard for high-volume triage, a grid of cards for comparison, or a dashboard for a single linear task.\n\n## Step 3.6 - Define usability scenario tests\n\nFor serious product UI, \"not only good looking\" work, UX audits, risky\u002Frepeated workflows, attractive-but-confusing UI, or final QA, read `..\u002F..\u002Freferences\u002Fux-patterns\u002Fusability-heuristic-evaluation.md` after the usability pattern matrix and before scenario testing. Rank findings with severity, name evidence, choose the first repair, and re-check the same task step.\n\nThen read `..\u002F..\u002Freferences\u002Fux-patterns\u002Fusability-scenario-testing.md` after the heuristic evaluation.\n\nWrite the compact scenario test before final visual polish or delivery:\n\n```md\nUsability scenario test\n- Surface:\n- User persona\u002Fmode:\n- Core task:\n- First-run scenario:\n- Returning-user scenario:\n- Error\u002Frecovery scenario:\n- Keyboard-only scenario:\n- Mobile\u002Ftouch scenario:\n- Success criteria:\n- Friction budget:\n- Evidence captured:\n- Usability failures:\n- Fix applied:\n- Re-check:\n- Remaining risk:\n```\n\nThe scenario test is the proof layer. A screen is not \"usable\" just because the task ergonomics contract sounds good; the main task, recovery path, keyboard path, and mobile path need evidence or clearly named remaining risk.\n\n## Step 4 - Reduce cognitive load\n\nApply these rules:\n\n- Put the next action where the user's eye already is.\n- Use one primary action per surface.\n- Group by task, not by database object.\n- Prefer progressive disclosure over dense first screens.\n- Keep labels concrete: \"Invite teammate\", not \"Manage\".\n- Make defaults safe and visible.\n- Keep destructive actions separated, confirmed, and undoable when possible.\n- Make repeated actions faster than first-time actions.\n\nFor high-frequency tools, optimize scan speed, keyboard flow, saved filters, bulk actions, and stable layout. For consumer onboarding, optimize motivation, trust, and the shortest path to first value.\n\n## Step 4.5 - Match the product type\n\nUse the product type to decide what \"good UX\" means:\n\n| Product type | Optimize for | Avoid |\n|---|---|---|\n| SaaS dashboard | fast scanning, saved filters, drilldowns, clear priority, visible operational thesis | marketing-page spacing, decorative cards, hidden filters, generic CRM furniture |\n| CRM\u002Fadmin\u002Finternal tool | repeat speed, bulk actions, auditability, permissions, domain-specific task language | oversized empty space, playful copy, modal chains, interchangeable labels |\n| Creative\u002Feditor tool | canvas focus, tool discoverability, undo\u002Fredo, stable panels | layout shifts, buried controls, destructive defaults |\n| Marketplace\u002Fecommerce | trust, comparison, price\u002Fshipping clarity, recovery | surprise costs, forced account creation, vague stock states |\n| Onboarding\u002Fsetup | first value, motivation, resumability, skip paths | long forms before value, fake progress, no return path |\n| AI agent\u002Ftool run | plan preview, progress, artifacts, retry, stop\u002Fresume | invisible work, ambiguous completion, no trace of outputs |\n\nIf the request sounds like a real product people will use repeatedly, bias toward operational density and predictable navigation. If it is a one-off marketing page, bias toward clarity, brand memory, and conversion path.\n\n## Step 4.6 - Load a contextual pattern brief\n\nIf the product type clearly matches one of these contexts, read the matching brief before choosing the final UX pattern:\n\n| Context | Read |\n|---|---|\n| Any serious product surface, repeated workflow, risky action, form, checkout, dashboard, editor, agent run, or usability audit | `..\u002F..\u002Freferences\u002Fux-patterns\u002Ftask-ergonomics.md` |\n| Workflow structure, usability pattern choice, repeated\u002Frisky\u002Fstateful product work, or \"not only good looking\" | `..\u002F..\u002Freferences\u002Fux-patterns\u002Fusability-pattern-matrix.md` |\n| Onboarding, activation, empty dashboards, no-results, setup\u002Fimport, permission gates, trials, workspace\u002Fproject creation | `..\u002F..\u002Freferences\u002Fux-patterns\u002Ffirst-run-empty-state-system.md` |\n| Heuristic review, cognitive walkthrough, severity triage, attractive-but-confusing UI, or polished surfaces that may still fail the task | `..\u002F..\u002Freferences\u002Fux-patterns\u002Fusability-heuristic-evaluation.md` |\n| Scenario validation, final usability QA, keyboard\u002Fmobile\u002Ferror path proof, or \"is this actually usable?\" | `..\u002F..\u002Freferences\u002Fux-patterns\u002Fusability-scenario-testing.md` |\n| Navigation, information architecture, app shell, docs, dashboards, settings, workspaces, command\u002Fsearch, breadcrumbs, or tabs | `..\u002F..\u002Freferences\u002Fui-patterns\u002Fnavigation-information-architecture.md` |\n| Agent\u002Ftool run, background automation, long-running export\u002Fimport | `..\u002F..\u002Freferences\u002Fux-patterns\u002Fai-agent-run.md` |\n| SaaS dashboard, CRM, admin panel, internal tool, support queue | `..\u002F..\u002Freferences\u002Fux-patterns\u002Foperational-dashboard.md` |\n| First-run setup, trial activation, import\u002Fsetup flow | `..\u002F..\u002Freferences\u002Fux-patterns\u002Factivation-onboarding.md` + `..\u002F..\u002Freferences\u002Fux-patterns\u002Ffirst-run-empty-state-system.md` |\n| Checkout, paywall, pricing, upgrade, plan comparison | `..\u002F..\u002Freferences\u002Fux-patterns\u002Fcheckout-upgrade.md` |\n| Editor, builder, canvas, creative tool, IDE-like surface | `..\u002F..\u002Freferences\u002Fux-patterns\u002Feditor-canvas.md` |\n\nUse a brief only when the context fits. If no brief fits, proceed from the product type table and the user's actual constraints.\n\nThe brief should influence the UX decision brief, especially:\n\n- Pattern\n- Primary and secondary actions\n- Required states\n- Recovery path\n- Frequency\u002Frisk treatment\n- Speed path\n- Error prevention\n- Evidence tasks\n- Scenario tests\n- Handoff constraints\n\nDo not copy a referenced app or blindly apply a pattern because it is common. A shipped screen is evidence that a real product team used a decision, not proof that it is best for every product.\n\n## Step 5 - Choose the UX pattern\n\nPick one pattern and name it before visual design:\n\n| Need | Pattern |\n|---|---|\n| First run | Guided setup with skip\u002Fresume |\n| Complex creation | Wizard with review step |\n| Frequent operations | Command surface + saved views |\n| Data-heavy work | Master\u002Fdetail + filters + bulk actions |\n| Monitoring | Dashboard with priority stack and drilldown |\n| Settings | Searchable grouped settings + inline validation |\n| Checkout\u002Fsignup | Short form + transparent cost\u002Frisk + recovery |\n| Collaboration | Activity timeline + comments + ownership |\n| AI\u002Ftool execution | Plan preview + progress + artifacts + retry |\n| Public demo\u002Fproof project | Product-specific job + proof surface + one non-happy state |\n\nIf two patterns fit, pick the one that reduces the riskiest failure mode. For example, choose a wizard over a single dense form when errors are costly, but choose command surface + saved views for repeated internal operations.\n\n## Step 6 - Hand off to UI\n\nAfter the UX shape is clear, route to the platform skill:\n\n- Web visuals: `..\u002Fweb-design\u002FSKILL.md`\n- Windows visuals: `..\u002Fwindows-design\u002FSKILL.md`\n- Apple visuals: `..\u002Fapple-design\u002FSKILL.md`\n- Android visuals: `..\u002Fandroid-design\u002FSKILL.md`\n- Cross-platform translation: `..\u002Fcross-platform-design\u002FSKILL.md`\n\nPass the UX decisions into that skill as constraints. Do not let visual direction erase task flow, state coverage, or platform idioms.\n\nWhen a contextual pattern brief was used, include its name in the handoff constraints so the platform skill knows which product behavior must survive visual design.\n\n## UX audit checklist\n\nBefore final delivery, check:\n\n1. Is the primary job obvious in the first screen?\n2. Can a new user reach first value without reading documentation?\n3. Can a returning user repeat the core task faster?\n4. Are empty, loading, error, permission, and success states defined?\n5. Is there one clear primary action per surface?\n6. Are risky actions confirmed, separated, or undoable?\n7. Do form errors appear near the fields they describe?\n8. Does the layout support scanning, not just looking good in a screenshot?\n9. Does navigation match the user's mental model?\n10. Is the next step clear after every action?\n11. Does the repeated path get faster after first use?\n12. Are focus, touch targets, and keyboard paths usable for the selected surface?\n13. Are validation and recovery close to the user's input\u002Faction and is user input preserved?\n14. Is friction applied only where risk justifies it?\n\nIf any answer is no, fix the flow before polishing visuals.\n","# ux-design - product flow before pixels\n\nUse this skill when the product has to be understandable and usable, not just attractive. The output should make the user path clearer, reduce unnecessary decisions, and define states that survive real use.\n\n## What This Skill Can Do\n\n- Map core user journeys, task paths, branching flows, and recovery paths.\n- Define information architecture, navigation, labels, content groups, and page\u002Fscreen inventory.\n- Design onboarding, activation, checkout, signup, forms, settings, dashboards, command palettes, and internal workflows.\n- Specify empty, loading, error, permission, success, stale, retry, resume, and audit states.\n- Define task ergonomics: frequency, risk, cognitive load, control model, speed paths, error prevention, recovery, and evidence tasks.\n- Choose usable workflow patterns: guided setup, wizard with review, command surface, priority queue, master\u002Fdetail, monitoring board, workbench, settings, permission matrix, transparent checkout, task-led docs, agent progress, collaboration thread, and mobile priority stack.\n- Evaluate polished UI with heuristic review, cognitive walkthrough prompts, severity ranking, evidence, first repair, and re-check.\n- Validate usability with scenario tests for first-run, returning-user, error\u002Frecovery, keyboard-only, and mobile\u002Ftouch paths.\n- Audit an existing UI for usability, hierarchy, conversion, repeated-use friction, accessibility risks, and missing states.\n- Hand a compact UX decision brief to platform skills so visual design does not erase the product job.\n\n## Step 1 - Identify the job and user mode\n\nBefore designing screens, state the smallest useful context:\n\n- Primary job: what the user is trying to finish.\n- User mode: first-time, returning, power user, admin, buyer, creator, operator, or support.\n- Frequency: one-time, occasional, daily, or high-volume repeated use.\n- Risk: low-risk browse, reversible edit, money\u002Fdata\u002Fsecurity impact, or destructive action.\n\nIf any of these are unclear and materially affect the flow, ask one short question. If the answer is easy to infer from the request, infer it and continue.\n\nDo not interrogate the user with a product-strategy questionnaire before helping. The skill should make useful assumptions, name them briefly, and move.\n\n## Step 2 - Map the flow\n\nWrite the minimum useful path:\n\n1. Entry point\n2. First meaningful action\n3. Required decision\n4. Feedback after action\n5. Success state\n6. Recovery path when something fails\n\nPrefer fewer screens when the user is trying to finish one job. Prefer separate steps when the user is making risky, costly, or hard-to-reverse decisions.\n\n## Step 2.5 - Produce the UX decision brief\n\nBefore visual design or code, write a compact brief. Keep it short enough to pass into another skill:\n\n```md\nUX decision brief\n- Job: ...\n- User mode: ...\n- Frequency\u002Frisk: ...\n- Pattern: ...\n- Primary action: ...\n- Secondary actions: ...\n- Core path: entry -> action -> feedback -> success\n- Recovery path: ...\n- Required states: empty, loading, partial, error, permission, success, long-running\n- Handoff constraints: ...\n```\n\nThis brief is the contract. The platform skill may change visual treatment, but it must not erase the chosen job, action hierarchy, state coverage, or recovery path.\n\n## Step 2.6 - Produce the task ergonomics contract\n\nFor serious product UI, repeated-use workflows, risky actions, forms, checkout, dashboards, editors, agent runs, admin tools, settings, or any request that says \"usable\", \"ergonomic\", \"not only good looking\", or \"real product\", read `..\u002F..\u002Freferences\u002Fux-patterns\u002Ftask-ergonomics.md`.\n\nWrite the compact contract before visual design:\n\n```md\nTask ergonomics contract\n- Core task:\n- User mode:\n- Frequency\u002Frisk:\n- Success metric:\n- Cognitive load:\n- Control model:\n- Speed path:\n- Error prevention:\n- Recovery:\n- State matrix:\n- Evidence plan:\n```\n\nThis is stricter than the UX decision brief. It protects the tenth use, the error path, and the risky action path.\n\nFor forms, settings, checkout, onboarding, signup, admin configuration, filters, generation prompts, or any user input that can fail, also read `..\u002F..\u002Freferences\u002Fui-patterns\u002Fform-state-validation-system.md` before visual design or implementation. Add the form job, risk, pattern, field anatomy, validation timing, state model, preservation\u002Frecovery, review\u002Fconfirmation, schema\u002Flibrary ownership, accessibility, responsive behavior, and QA checks to the UX handoff.\n\nFor onboarding, activation, empty dashboards, no-results screens, setup\u002Fimport flows, permission gates, trial starts, workspace creation, or first project creation, read `..\u002F..\u002Freferences\u002Fux-patterns\u002Ffirst-run-empty-state-system.md` before visual design. Define user promise, first value action, minimum\u002Fdeferrable setup, sample\u002Fdemo content, empty-state type, CTAs, permission timing, progress\u002Fresume model, recovery states, contextual teaching, success handoff, and QA evidence.\n\nFor navigation, information architecture, app shells, docs platforms, dashboards, admin\u002Fsettings, workspaces, command palettes, breadcrumbs, tabs, or multi-route products, also read `..\u002F..\u002Freferences\u002Fui-patterns\u002Fnavigation-information-architecture.md` before visual design or implementation. Add the primary objects, route map, navigation model, current-location model, search\u002Fcommand model, breadcrumb\u002Ftab behavior, deep-link\u002Fstate model, route states, mobile replacement, focus\u002Fscroll restoration, and QA checks to the UX handoff.\n\n## Step 3 - Design the states\n\nEvery production UI needs these states:\n\n- Empty: what the user sees before data exists.\n- Loading: what changes while the system is working.\n- Partial: some data exists, some is missing.\n- Error: what failed, why it matters, and the next action.\n- Permission: what is blocked and how to request access.\n- Success: what happened and what the user can do next.\n- Long-running: progress, cancellation, retry, and resume behavior.\n\nDo not ship only the happy path.\n\nFor public demos and generated proof projects, include at least one non-happy state in the visible UI: an empty state, blocked permission, failed sync, queued job, retry panel, stale data banner, or partial result. This makes the output feel like a real product instead of a polished poster.\n\n## Step 3.5 - Choose the usability pattern\n\nFor serious product UI or any request that says \"usable\", \"not only good looking\", \"real product\", \"ergonomic\", \"dashboard\", \"editor\", \"checkout\", \"agent run\", \"settings\", \"permissions\", \"docs\", or \"mobile task\", read `..\u002F..\u002Freferences\u002Fux-patterns\u002Fusability-pattern-matrix.md` after `task-ergonomics.md`.\n\nWrite the compact pattern brief before visual design:\n\n```md\nUsability pattern brief\n- Product job:\n- User mode:\n- Frequency\u002Frisk:\n- Pattern chosen:\n- Why this pattern fits:\n- Primary action:\n- Secondary actions:\n- Speed path:\n- Error prevention:\n- Recovery path:\n- Required states:\n- Keyboard\u002Ftouch model:\n- Rejected patterns:\n- Evidence tasks:\n```\n\nThe selected pattern should reduce the riskiest failure mode. Reject patterns that optimize the wrong use, such as a marketing hero for repeated operations, a wizard for high-volume triage, a grid of cards for comparison, or a dashboard for a single linear task.\n\n## Step 3.6 - Define usability scenario tests\n\nFor serious product UI, \"not only good looking\" work, UX audits, risky\u002Frepeated workflows, attractive-but-confusing UI, or final QA, read `..\u002F..\u002Freferences\u002Fux-patterns\u002Fusability-heuristic-evaluation.md` after the usability pattern matrix and before scenario testing. Rank findings with severity, name evidence, choose the first repair, and re-check the same task step.\n\nThen read `..\u002F..\u002Freferences\u002Fux-patterns\u002Fusability-scenario-testing.md` after the heuristic evaluation.\n\nWrite the compact scenario test before final visual polish or delivery:\n\n```md\nUsability scenario test\n- Surface:\n- User persona\u002Fmode:\n- Core task:\n- First-run scenario:\n- Returning-user scenario:\n- Error\u002Frecovery scenario:\n- Keyboard-only scenario:\n- Mobile\u002Ftouch scenario:\n- Success criteria:\n- Friction budget:\n- Evidence captured:\n- Usability failures:\n- Fix applied:\n- Re-check:\n- Remaining risk:\n```\n\nThe scenario test is the proof layer. A screen is not \"usable\" just because the task ergonomics contract sounds good; the main task, recovery path, keyboard path, and mobile path need evidence or clearly named remaining risk.\n\n## Step 4 - Reduce cognitive load\n\nApply these rules:\n\n- Put the next action where the user's eye already is.\n- Use one primary action per surface.\n- Group by task, not by database object.\n- Prefer progressive disclosure over dense first screens.\n- Keep labels concrete: \"Invite teammate\", not \"Manage\".\n- Make defaults safe and visible.\n- Keep destructive actions separated, confirmed, and undoable when possible.\n- Make repeated actions faster than first-time actions.\n\nFor high-frequency tools, optimize scan speed, keyboard flow, saved filters, bulk actions, and stable layout. For consumer onboarding, optimize motivation, trust, and the shortest path to first value.\n\n## Step 4.5 - Match the product type\n\nUse the product type to decide what \"good UX\" means:\n\n| Product type | Optimize for | Avoid |\n|---|---|---|\n| SaaS dashboard | fast scanning, saved filters, drilldowns, clear priority, visible operational thesis | marketing-page spacing, decorative cards, hidden filters, generic CRM furniture |\n| CRM\u002Fadmin\u002Finternal tool | repeat speed, bulk actions, auditability, permissions, domain-specific task language | oversized empty space, playful copy, modal chains, interchangeable labels |\n| Creative\u002Feditor tool | canvas focus, tool discoverability, undo\u002Fredo, stable panels | layout shifts, buried controls, destructive defaults |\n| Marketplace\u002Fecommerce | trust, comparison, price\u002Fshipping clarity, recovery | surprise costs, forced account creation, vague stock states |\n| Onboarding\u002Fsetup | first value, motivation, resumability, skip paths | long forms before value, fake progress, no return path |\n| AI agent\u002Ftool run | plan preview, progress, artifacts, retry, stop\u002Fresume | invisible work, ambiguous completion, no trace of outputs |\n\nIf the request sounds like a real product people will use repeatedly, bias toward operational density and predictable navigation. If it is a one-off marketing page, bias toward clarity, brand memory, and conversion path.\n\n## Step 4.6 - Load a contextual pattern brief\n\nIf the product type clearly matches one of these contexts, read the matching brief before choosing the final UX pattern:\n\n| Context | Read |\n|---|---|\n| Any serious product surface, repeated workflow, risky action, form, checkout, dashboard, editor, agent run, or usability audit | `..\u002F..\u002Freferences\u002Fux-patterns\u002Ftask-ergonomics.md` |\n| Workflow structure, usability pattern choice, repeated\u002Frisky\u002Fstateful product work, or \"not only good looking\" | `..\u002F..\u002Freferences\u002Fux-patterns\u002Fusability-pattern-matrix.md` |\n| Onboarding, activation, empty dashboards, no-results, setup\u002Fimport, permission gates, trials, workspace\u002Fproject creation | `..\u002F..\u002Freferences\u002Fux-patterns\u002Ffirst-run-empty-state-system.md` |\n| Heuristic review, cognitive walkthrough, severity triage, attractive-but-confusing UI, or polished surfaces that may still fail the task | `..\u002F..\u002Freferences\u002Fux-patterns\u002Fusability-heuristic-evaluation.md` |\n| Scenario validation, final usability QA, keyboard\u002Fmobile\u002Ferror path proof, or \"is this actually usable?\" | `..\u002F..\u002Freferences\u002Fux-patterns\u002Fusability-scenario-testing.md` |\n| Navigation, information architecture, app shell, docs, dashboards, settings, workspaces, command\u002Fsearch, breadcrumbs, or tabs | `..\u002F..\u002Freferences\u002Fui-patterns\u002Fnavigation-information-architecture.md` |\n| Agent\u002Ftool run, background automation, long-running export\u002Fimport | `..\u002F..\u002Freferences\u002Fux-patterns\u002Fai-agent-run.md` |\n| SaaS dashboard, CRM, admin panel, internal tool, support queue | `..\u002F..\u002Freferences\u002Fux-patterns\u002Foperational-dashboard.md` |\n| First-run setup, trial activation, import\u002Fsetup flow | `..\u002F..\u002Freferences\u002Fux-patterns\u002Factivation-onboarding.md` + `..\u002F..\u002Freferences\u002Fux-patterns\u002Ffirst-run-empty-state-system.md` |\n| Checkout, paywall, pricing, upgrade, plan comparison | `..\u002F..\u002Freferences\u002Fux-patterns\u002Fcheckout-upgrade.md` |\n| Editor, builder, canvas, creative tool, IDE-like surface | `..\u002F..\u002Freferences\u002Fux-patterns\u002Feditor-canvas.md` |\n\nUse a brief only when the context fits. If no brief fits, proceed from the product type table and the user's actual constraints.\n\nThe brief should influence the UX decision brief, especially:\n\n- Pattern\n- Primary and secondary actions\n- Required states\n- Recovery path\n- Frequency\u002Frisk treatment\n- Speed path\n- Error prevention\n- Evidence tasks\n- Scenario tests\n- Handoff constraints\n\nDo not copy a referenced app or blindly apply a pattern because it is common. A shipped screen is evidence that a real product team used a decision, not proof that it is best for every product.\n\n## Step 5 - Choose the UX pattern\n\nPick one pattern and name it before visual design:\n\n| Need | Pattern |\n|---|---|\n| First run | Guided setup with skip\u002Fresume |\n| Complex creation | Wizard with review step |\n| Frequent operations | Command surface + saved views |\n| Data-heavy work | Master\u002Fdetail + filters + bulk actions |\n| Monitoring | Dashboard with priority stack and drilldown |\n| Settings | Searchable grouped settings + inline validation |\n| Checkout\u002Fsignup | Short form + transparent cost\u002Frisk + recovery |\n| Collaboration | Activity timeline + comments + ownership |\n| AI\u002Ftool execution | Plan preview + progress + artifacts + retry |\n| Public demo\u002Fproof project | Product-specific job + proof surface + one non-happy state |\n\nIf two patterns fit, pick the one that reduces the riskiest failure mode. For example, choose a wizard over a single dense form when errors are costly, but choose command surface + saved views for repeated internal operations.\n\n## Step 6 - Hand off to UI\n\nAfter the UX shape is clear, route to the platform skill:\n\n- Web visuals: `..\u002Fweb-design\u002FSKILL.md`\n- Windows visuals: `..\u002Fwindows-design\u002FSKILL.md`\n- Apple visuals: `..\u002Fapple-design\u002FSKILL.md`\n- Android visuals: `..\u002Fandroid-design\u002FSKILL.md`\n- Cross-platform translation: `..\u002Fcross-platform-design\u002FSKILL.md`\n\nPass the UX decisions into that skill as constraints. Do not let visual direction erase task flow, state coverage, or platform idioms.\n\nWhen a contextual pattern brief was used, include its name in the handoff constraints so the platform skill knows which product behavior must survive visual design.\n\n## UX audit checklist\n\nBefore final delivery, check:\n\n1. Is the primary job obvious in the first screen?\n2. Can a new user reach first value without reading documentation?\n3. Can a returning user repeat the core task faster?\n4. Are empty, loading, error, permission, and success states defined?\n5. Is there one clear primary action per surface?\n6. Are risky actions confirmed, separated, or undoable?\n7. Do form errors appear near the fields they describe?\n8. Does the layout support scanning, not just looking good in a screenshot?\n9. Does navigation match the user's mental model?\n10. Is the next step clear after every action?\n11. Does the repeated path get faster after first use?\n12. Are focus, touch targets, and keyboard paths usable for the selected surface?\n13. Are validation and recovery close to the user's input\u002Faction and is user input preserved?\n14. Is friction applied only where risk justifies it?\n\nIf any answer is no, fix the flow before polishing visuals.\n",{"name":5,"description":7},"main","2b63f856ce19c2a797929cacabd9e0fc936812fa","plugins\u002Ff0d010c\u002Fstark\u002Fskills\u002Fux-design",491,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins","https:\u002F\u002Fhol.org\u002Fplugins\u002Fbest-codex-plugins","https:\u002F\u002Fgithub.com\u002Fhashgraph-online","https:\u002F\u002Fhol.org","Open-source standards and developer tools for interoperable AI agents: discovery, identity, communication, payments, privacy and security.","2026-11-14 14:06:13",{"source":8,"skillName":5,"commands":65,"prompt":75,"zipAvailable":76},[66,69,72],{"tool":67,"command":68},"npx","npx skills add hashgraph-online\u002Fawesome-codex-plugins --skill ux-design",{"tool":70,"command":71},"bunx","bunx skills add hashgraph-online\u002Fawesome-codex-plugins --skill ux-design",{"tool":73,"command":74},"pnpm","pnpm dlx skills add hashgraph-online\u002Fawesome-codex-plugins --skill ux-design","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ff0d010c\u002Fstark\u002Fskills\u002Fux-design\u002FSKILL.md",true,[],[79,87,94,101,127,152],{"skillNo":80,"name":81,"nameZh":6,"description":82,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":83,"categories":84,"keywords":85,"publishedAt":86},"01M746ZWACVKMZ1BJXJZHYJSSX","migrate-to-e2e","Moves an existing Playwright, Cypress, Selenium, Appium, Detox, Maestro, or TesterArmy suite to e2e one slice at a time, with the old suite running beside the new one until each ported test is proven. Keeps a MIGRATION.md progress file so any later session resumes where the last stopped. Optionally plants a defect to show both suites catch it. Use for \u002Fmigrate-to-e2e, \"migrate our tests to e2e\", \"port these Maestro flows\", \"move our TesterArmy tests\", or when a project has an e2e config and an older suite still running.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftester-army\u002Fe2e\u002Fskills\u002Fmigrate-to-e2e\u002FSKILL.md",[],[],"2026-11-11 15:11:14",{"skillNo":88,"name":89,"nameZh":6,"description":90,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":91,"categories":92,"keywords":93,"publishedAt":86},"01M746ZPTAX1Q0FBKAB1CYND7E","e2e","Writes, runs, and debugs end-to-end tests for web and mobile apps with e2e, the agentic test runner, which mixes agent.act goals with exact locator assertions on a Playwright browser or an iOS or Android device. Also drives a project's running app live over the e2e MCP server to look at a screen, check a UI change, take a screenshot or record a video, and try a locator; and runs bug bashes, parallel e2e explore runs with each bug proven by a repro test. Use when a project depends on e2e or has an e2e.config.ts, when asked for end-to-end, browser, mobile, or agentic UI tests, to check a change in the running app, to QA or bug bash an app or branch, or when an e2e run fails.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftester-army\u002Fe2e\u002Fskills\u002Fe2e\u002FSKILL.md",[],[],{"skillNo":95,"name":96,"nameZh":6,"description":97,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":98,"categories":99,"keywords":100,"publishedAt":86},"01M746ZJN784HVHMDP9MQGCSGG","create-verification-skill","Generate a project-local verify-\u003Capp> skill on top of e2e, so any coding agent can launch the app, check it is worth driving, exercise a feature the way a user does, keep evidence, and bug bash it. Writes the skill, a feature map with one explore charter per feature, and proves it once. Use for \u002Fcreate-verification-skill, \"make a verification skill for this repo\", or when a project has no scripted way to prove UI behavior.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftester-army\u002Fe2e\u002Fskills\u002Fcreate-verification-skill\u002FSKILL.md",[],[],{"skillNo":102,"name":103,"nameZh":6,"description":104,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":105,"categories":106,"keywords":107,"publishedAt":49},"01M716A6ETNB9B1SQ3GXZC75VR","deja-search","deja-vu memory — search the user's past AI coding sessions with the deja CLI. Holds what they already settled and never wrote into the repo (naming rules, banned or already-tried tools, required checks before merge, preferred values, who owns what). Use before your first edit in a task, before you call a change done or ready to merge, before you recommend a tool, library, design or reviewer, before re-debugging an error that may already be solved, when they say 'didn't we fix this before', 'what did we decide about X' or 'I already have that', and before telling them something on this machine does not exist.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fvshulcz\u002Fdeja-vu\u002Fskills\u002Fdeja-search\u002FSKILL.md",[],[108,109,110,111,112,113,114,115,116,31,117,118,119,120,121,122,123,124,125,126],"search","deja search","never","error","ready","memory","re","decide","fix","debugging","when","you","done","reviewer","io","change","cli","merge","past",{"skillNo":128,"name":129,"nameZh":6,"description":130,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":131,"categories":132,"keywords":133,"publishedAt":49},"01M716A3J2W5SENSE9VGMXB375","deja-reflect","End-of-session reflection and memory curation with deja-vu. Review what was decided, what commands broke and what repaired them, and record durable project rules or decisions with deja remember so the next session starts with them.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fvshulcz\u002Fdeja-vu\u002Fskills\u002Fdeja-reflect\u002FSKILL.md",[],[134,135,136,122,137,138,139,140,141,142,143,144,145,146,113,147,148,149,150,151],"deja reflect","reflect","review","with","record","github","next","https","node","Rules","decisions","brew","remember","project rules","project","session","end","reflection",{"skillNo":153,"name":154,"nameZh":6,"description":155,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":156,"categories":157,"keywords":167,"publishedAt":49},"01M715T3RR4BAYSR57HPPTJ0PF","revid","Make, edit, export and post AI videos with Revid (revid.ai) through the Revid MCP server. Use whenever the user wants a short-form or long-form video made (from an idea, a script, a URL, an article, a PDF, a tweet, a product page, their own clips, or a song), wants to find what is going viral on TikTok, YouTube, Instagram or X before making something, wants to edit or re-export an existing Revid project, generate a standalone AI image or clip, make a series episode, or publish and schedule a finished video to connected social accounts. Covers setup (hosted MCP with OAuth, or an API key), the 36 tools, credits, polling and the rules for publishing. Routes to the more specific revid-* skills when one fits.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftmakersas\u002Frevid-skills\u002Fskills\u002Frevid\u002FSKILL.md",[158,161,164],{"categoryNo":159,"categoryName":160,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000016","图像与多媒体",{"categoryNo":162,"categoryName":163,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":165,"categoryName":166,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口",[154,168,169,170,171,172,173,148,174,114,175,176,177,178,118,179,180,181,182,183],"URL","Video","short-form","standalone","PDF","viral","tiktok","short","social","MCP","song","image","mcp server","schedule","api","publish"]