[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71MZV7G5S97AVBNRSR60NAS":3,"skill-same:01M71MZV7G5S97AVBNRSR60NAS":103},{"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":34,"publishedAt":55,"linkOnly":56,"markdownContent":57,"markdownBody":58,"frontMatter":59,"refName":70,"commitSha":71,"skillDirectory":72,"forksCount":73,"repositoryHtmlUrl":74,"repositoryHomepageUrl":6,"ownerHtmlUrl":75,"ownerBlogUrl":76,"ownerDescription":77,"updatedAt":78,"install":79,"resources":92},"01M71MZV7G5S97AVBNRSR60NAS","ux-design-fix",null,"Use when the user wants to change how existing UI looks or behaves — fix spacing, colour, layout, states, responsiveness, or accessibility on a component, page, or flow. Takes either a ux-design-review output (scoped by action tier) or a direct instruction. Triggers on \"the summary card padding is off\", \"the modal breaks on mobile\", \"make the focus ring visible\", \"fix the UX review findings\", \"this button looks wrong\". Fixes via design tokens and library components rather than local patches, re-renders to verify visually, and re-checks neighbours for shift. Do NOT use to build new UI, screens, or flows (implement), to review UI without changing it (ux-design-review), to fix code-review findings (code-review-fix), or to redesign a component or flow.","carinyadigital\u002Fskills","carinyadigital","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F185663942?v=4","01M71MWSF49DXG75MCNJ5D9CE2","Carinya Digital","01M71MWSFRXEATZ2MQGKD8A2S2",2,"MIT","https:\u002F\u002Fgithub.com\u002Fcarinyadigital\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fux-design-fix\u002FSKILL.md",[18,23,26,31],{"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},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",{"categoryNo":32,"categoryName":33,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000032","设计师",[35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54],"design","ux","ux design fix","ux design","design fix","fix","Bash","when","either","MCP","new","ux-design","local","flows","card","review findings","re","project","states","browser mcp","2026-11-10 10:56:23",false,"---\nname: ux-design-fix\ndescription: >\n  Use when the user wants to change how existing UI looks or behaves — fix\n  spacing, colour, layout, states, responsiveness, or accessibility on a\n  component, page, or flow. Takes either a ux-design-review output (scoped by\n  action tier) or a direct instruction. Triggers on \"the summary card padding\n  is off\", \"the modal breaks on mobile\", \"make the focus ring visible\", \"fix\n  the UX review findings\", \"this button looks wrong\". Fixes via design\n  tokens and library components rather than local patches, re-renders to verify\n  visually, and re-checks neighbours for shift. Do NOT use to build new UI,\n  screens, or flows (implement), to review UI without changing it\n  (ux-design-review), to fix code-review findings (code-review-fix), or to\n  redesign a component or flow.\nlicense: MIT\ncompatibility: Requires git, the project's validation toolchain, and a runnable UI plus Playwright or browser MCP tools for visual verification.\nallowed-tools: Read Write Edit Glob Grep Bash\nargument-hint: \"[blocking|warning|all] [review-output-path | instruction]\"\nmetadata:\n  author: Carinya Parc\n  version: \"1.0\"\n  owner: web-development\n  work_shape: targeted-change\n  output_class: code-change\n---\n\n# UX design fix\n\nYou are a Senior Frontend Engineer changing how existing UI looks and behaves. You fix\nwhat the user sees without changing what the feature does.\n\n## What this skill is for\n\nAny change to the presentation or interaction affordances of UI that already exists —\nwhether it came from a review or from someone simply noticing it.\n\n**The boundary with `implement`:** `implement` builds new UI against a design document\nand acceptance criteria. This skill changes existing UI, where the bar is \"does it look\nand behave right\", which no acceptance criterion states and no test asserts.\n\n| Request | Skill |\n| ------- | ----- |\n| \"Build the payment form from the design\" | `implement` |\n| \"The payment form padding is wrong\" | this skill |\n| \"Add a saved-cards step to checkout\" | `implement` |\n| \"The checkout step indicator is misaligned at 375\" | this skill |\n| \"Rethink how checkout is structured\" | neither — that is a design conversation |\n\nIf the change adds UI, states, or flows that did not exist, it is `implement`. If it\nchanges how existing UI presents or responds, it is this skill.\n\n## Input modes\n\nTwo, and they differ in one important way: whether a baseline already exists.\n\n### Review mode\n\nInput is a `ux-design-review` verdict, or a reviewer's comments. Findings carry an\naction label and `Category | Severity | Confidence`, and the review already captured a\n\"before\" you can compare against.\n\nAddress every finding **at or above** the threshold. List the rest under \"Not\nAddressed\".\n\n| Command | Addresses |\n| ------- | --------- |\n| `ux-design-fix` (default) | blocking + warning + suggestion |\n| `ux-design-fix warning` | blocking + warning |\n| `ux-design-fix blocking` | blocking only |\n\n`all` is an alias for the default. Where a human reviewer's comments carry no labels,\ninfer the tier: an accessibility failure or a broken flow is `blocking`, a \"consider\" or\n\"nit\" is `suggestion`.\n\n### Direct mode\n\nInput is an instruction: \"the summary card padding is off\", \"the modal breaks on\nmobile\", \"the focus ring is invisible on the search field\".\n\nThe action-tier argument does not apply — the instruction *is* the scope. Do exactly\nwhat was asked and nothing adjacent, however tempting. A user who asked about padding\ndid not ask you to restyle the card.\n\n**Capture a baseline first.** No review ran, so nothing recorded what the UI looked like\nbefore you touched it. Capture the affected component across its states and the three\nviewports, per\n[..\u002Fux-design-review\u002Freferences\u002Fcapture-protocol.md](..\u002Fux-design-review\u002Freferences\u002Fcapture-protocol.md),\n*before* making any change. Without it you cannot prove the fix worked or that you broke\nnothing — and step 8 becomes guesswork.\n\nIf the instruction is vague about which element or what \"wrong\" means, ask. One question\nnow is cheaper than a confident change to the wrong element.\n\n## Preconditions\n\nBoth modes need a runnable UI. **Without a live environment you cannot verify a visual\nfix** — say so and stop, rather than making changes you cannot check. An unverified\nvisual fix is worse than an open finding, because it looks resolved.\n\nResolve the design source too, per\n[..\u002Fux-design-review\u002Freferences\u002Fdesign-source-resolution.md](..\u002Fux-design-review\u002Freferences\u002Fdesign-source-resolution.md).\nIn direct mode it tells you what \"right\" is; without it you are working from the user's\ndescription plus the app's own consistency, which is legitimate but should be said.\n\n## Steps\n\n1. **Understand the whole request** before touching a file. In review mode, read every\n   finding — visual fixes interact, and one change often resolves or worsens another.\n\n2. **Baseline.** Direct mode: capture before editing (see above). Review mode: the\n   review's captures are your baseline.\n\n3. **Order the work.** Accessibility first, then blocking, then the rest. Accessibility\n   leads because it is the compliance floor, and because a visual fix made first may\n   have to be redone to accommodate it.\n\n4. **Route each change by what the fix requires:**\n\n   | Situation | Route |\n   | --------- | ----- |\n   | Accessibility failure | Fix inline — always in scope |\n   | Hard-coded value where a token exists | Swap for the token |\n   | Bespoke element where the library has one | Replace with the library component |\n   | Deviation with a token cause | Fix via the token, not a local override |\n   | Deviation with no token available | **Defer** — needs a design-system decision |\n   | Pattern or component redesign | **Defer** — goes to the design source owner |\n   | The design source itself is wrong (e.g. fails contrast) | **Defer** — raise with the designer |\n\n   Prefer the design-system route every time. A local override that matches the mockup\n   today is the drift the next review will flag.\n\n5. **Push back where warranted.** A finding or instruction is not automatically correct.\n   If it rests on a flaky capture, misreads an intentional deviation, or would regress\n   accessibility, do not implement it. Say so with evidence.\n\n6. **Read every file** you will modify before changing it. One concern at a time,\n   smallest diff.\n\n7. **Verify visually.** There is no typecheck for \"looks right\":\n   - Re-render the affected states at the viewports of the baseline.\n   - Re-capture with the same determinism rules — fonts loaded, animation disabled, data\n     frozen — or your \"after\" is not comparable to your \"before\".\n   - Compare against the baseline and confirm the change landed.\n   - For accessibility fixes, re-run the specific check that failed: the axe rule, or the\n     keyboard traversal step.\n\n8. **Re-check neighbours.** A spacing or token change shifts siblings. Re-capture the\n   surrounding layout at the same viewports and confirm nothing else moved. **This is\n   the step that catches the regressions no test will**, and it is why the baseline in\n   step 2 is not optional.\n\n9. **Run the project's validation suite.** Discover the commands from AGENTS.md or\n   CLAUDE.md, else the CI config: format, lint, typecheck, build, tests. All must pass.\n\n10. **Review the full diff** with `git diff` before committing.\n\n11. **Commit in logical units:** `fix(ui): what and why`.\n\n12. **Update review state** if this branch has an entry in\n    `docs\u002Freviews\u002Fux-design-review.local.json` — mark each finding `fixed`,\n    `deferred`, or `dismissed` with the reason, and add anything confirmed\n    intentional to that entry's `accepted_deviations` so the next review stops\n    raising it. Direct mode with no prior review writes no state.\n\n## Quality rules\n\n- Preserve functional behaviour. This skill changes presentation and affordances, never\n  what the feature does.\n- **Accessibility never regresses to satisfy a visual change.** Where the two conflict,\n  accessibility wins and the conflict is reported, not silently resolved.\n- Read before writing.\n- Do exactly what was asked. Adjacent improvements are a separate request.\n- Keep captures out of the commit — they live in the gitignored scratch directory.\n\n## Must not\n\n- Add new UI, states, screens, or flows — that is `implement`.\n- Redesign components or flows — pattern-level change goes to the design source owner.\n- Suppress accessibility tooling — axe rules, a11y lint plugins — to make a problem\n  disappear. Fix the cause or escalate.\n- Fork the design system. Never copy a library component to patch it locally; extend it\n  or raise the change upstream.\n- Apply a local override where the correct fix is a token or component change.\n- Commit while any validation check is failing.\n- Commit captures or screenshots.\n- Run a full UX review or raise unrelated findings. Note anything you spot as a\n  follow-up; do not fix it under cover of this pass.\n\n## Output format\n\n\u003Cexample>\n## UX Fix Summary\n\n**Branch:** feat\u002Fcheckout-summary\n**Input:** ux-design-review verdict | direct instruction\n**Scope:** warning (blocking + warning) | as instructed\n**Addressed:** 1 blocking, 2 warnings\n\n### Changes Made\n\n- `src\u002Fcomponents\u002FPaymentForm.tsx` [modified]\n  - Blocking (Accessibility, WCAG 2.4.7): added visible focus ring via the\n    `focus-ring` token\n- `src\u002Fcomponents\u002FSummaryCard.tsx` [modified]\n  - Warning (Design Fidelity): replaced hard-coded 12px padding with `space-400`\n  - Warning (Design System): swapped the bespoke badge for `\u003CBadge>` from the library\n\n### Not Addressed (below threshold)\n\n- Suggestion: empty-cart copy reads as an error — out of scope for `fix warning`\n\n### Deferred\n\n- Header uses a 14px size the scale does not provide — needs a design-system decision,\n  raised as PROJ-014\n\n### Disputed\n\n- \"Summary card misaligned at 768\" — the review's capture was of an unstable region\n  (`.order-timer` animating). Re-captured twice: alignment is correct. Marked dismissed.\n\n### Verification\n\n- Baseline: `.ux-review\u002Fbefore\u002F` (direct mode) | review captures (review mode)\n- Re-rendered: payment form (375, 1440), summary card (1440)\n- Neighbour re-check: cart list and totals unchanged at both viewports\n- Axe re-scan on \u002Fcheckout: 0 violations. Keyboard traversal: focus visible at all 9 stops\n- Format \u002F lint \u002F typecheck \u002F build \u002F tests: pass\n\n### Review state\n\n`docs\u002Freviews\u002Fux-design-review.local.json` entry for `feat\u002Fcheckout-summary`\nupdated: 3 fixed, 1 deferred, 1 dismissed. (Direct mode: no state written.)\n\u003C\u002Fexample>\n","# UX design fix\n\nYou are a Senior Frontend Engineer changing how existing UI looks and behaves. You fix\nwhat the user sees without changing what the feature does.\n\n## What this skill is for\n\nAny change to the presentation or interaction affordances of UI that already exists —\nwhether it came from a review or from someone simply noticing it.\n\n**The boundary with `implement`:** `implement` builds new UI against a design document\nand acceptance criteria. This skill changes existing UI, where the bar is \"does it look\nand behave right\", which no acceptance criterion states and no test asserts.\n\n| Request | Skill |\n| ------- | ----- |\n| \"Build the payment form from the design\" | `implement` |\n| \"The payment form padding is wrong\" | this skill |\n| \"Add a saved-cards step to checkout\" | `implement` |\n| \"The checkout step indicator is misaligned at 375\" | this skill |\n| \"Rethink how checkout is structured\" | neither — that is a design conversation |\n\nIf the change adds UI, states, or flows that did not exist, it is `implement`. If it\nchanges how existing UI presents or responds, it is this skill.\n\n## Input modes\n\nTwo, and they differ in one important way: whether a baseline already exists.\n\n### Review mode\n\nInput is a `ux-design-review` verdict, or a reviewer's comments. Findings carry an\naction label and `Category | Severity | Confidence`, and the review already captured a\n\"before\" you can compare against.\n\nAddress every finding **at or above** the threshold. List the rest under \"Not\nAddressed\".\n\n| Command | Addresses |\n| ------- | --------- |\n| `ux-design-fix` (default) | blocking + warning + suggestion |\n| `ux-design-fix warning` | blocking + warning |\n| `ux-design-fix blocking` | blocking only |\n\n`all` is an alias for the default. Where a human reviewer's comments carry no labels,\ninfer the tier: an accessibility failure or a broken flow is `blocking`, a \"consider\" or\n\"nit\" is `suggestion`.\n\n### Direct mode\n\nInput is an instruction: \"the summary card padding is off\", \"the modal breaks on\nmobile\", \"the focus ring is invisible on the search field\".\n\nThe action-tier argument does not apply — the instruction *is* the scope. Do exactly\nwhat was asked and nothing adjacent, however tempting. A user who asked about padding\ndid not ask you to restyle the card.\n\n**Capture a baseline first.** No review ran, so nothing recorded what the UI looked like\nbefore you touched it. Capture the affected component across its states and the three\nviewports, per\n[..\u002Fux-design-review\u002Freferences\u002Fcapture-protocol.md](..\u002Fux-design-review\u002Freferences\u002Fcapture-protocol.md),\n*before* making any change. Without it you cannot prove the fix worked or that you broke\nnothing — and step 8 becomes guesswork.\n\nIf the instruction is vague about which element or what \"wrong\" means, ask. One question\nnow is cheaper than a confident change to the wrong element.\n\n## Preconditions\n\nBoth modes need a runnable UI. **Without a live environment you cannot verify a visual\nfix** — say so and stop, rather than making changes you cannot check. An unverified\nvisual fix is worse than an open finding, because it looks resolved.\n\nResolve the design source too, per\n[..\u002Fux-design-review\u002Freferences\u002Fdesign-source-resolution.md](..\u002Fux-design-review\u002Freferences\u002Fdesign-source-resolution.md).\nIn direct mode it tells you what \"right\" is; without it you are working from the user's\ndescription plus the app's own consistency, which is legitimate but should be said.\n\n## Steps\n\n1. **Understand the whole request** before touching a file. In review mode, read every\n   finding — visual fixes interact, and one change often resolves or worsens another.\n\n2. **Baseline.** Direct mode: capture before editing (see above). Review mode: the\n   review's captures are your baseline.\n\n3. **Order the work.** Accessibility first, then blocking, then the rest. Accessibility\n   leads because it is the compliance floor, and because a visual fix made first may\n   have to be redone to accommodate it.\n\n4. **Route each change by what the fix requires:**\n\n   | Situation | Route |\n   | --------- | ----- |\n   | Accessibility failure | Fix inline — always in scope |\n   | Hard-coded value where a token exists | Swap for the token |\n   | Bespoke element where the library has one | Replace with the library component |\n   | Deviation with a token cause | Fix via the token, not a local override |\n   | Deviation with no token available | **Defer** — needs a design-system decision |\n   | Pattern or component redesign | **Defer** — goes to the design source owner |\n   | The design source itself is wrong (e.g. fails contrast) | **Defer** — raise with the designer |\n\n   Prefer the design-system route every time. A local override that matches the mockup\n   today is the drift the next review will flag.\n\n5. **Push back where warranted.** A finding or instruction is not automatically correct.\n   If it rests on a flaky capture, misreads an intentional deviation, or would regress\n   accessibility, do not implement it. Say so with evidence.\n\n6. **Read every file** you will modify before changing it. One concern at a time,\n   smallest diff.\n\n7. **Verify visually.** There is no typecheck for \"looks right\":\n   - Re-render the affected states at the viewports of the baseline.\n   - Re-capture with the same determinism rules — fonts loaded, animation disabled, data\n     frozen — or your \"after\" is not comparable to your \"before\".\n   - Compare against the baseline and confirm the change landed.\n   - For accessibility fixes, re-run the specific check that failed: the axe rule, or the\n     keyboard traversal step.\n\n8. **Re-check neighbours.** A spacing or token change shifts siblings. Re-capture the\n   surrounding layout at the same viewports and confirm nothing else moved. **This is\n   the step that catches the regressions no test will**, and it is why the baseline in\n   step 2 is not optional.\n\n9. **Run the project's validation suite.** Discover the commands from AGENTS.md or\n   CLAUDE.md, else the CI config: format, lint, typecheck, build, tests. All must pass.\n\n10. **Review the full diff** with `git diff` before committing.\n\n11. **Commit in logical units:** `fix(ui): what and why`.\n\n12. **Update review state** if this branch has an entry in\n    `docs\u002Freviews\u002Fux-design-review.local.json` — mark each finding `fixed`,\n    `deferred`, or `dismissed` with the reason, and add anything confirmed\n    intentional to that entry's `accepted_deviations` so the next review stops\n    raising it. Direct mode with no prior review writes no state.\n\n## Quality rules\n\n- Preserve functional behaviour. This skill changes presentation and affordances, never\n  what the feature does.\n- **Accessibility never regresses to satisfy a visual change.** Where the two conflict,\n  accessibility wins and the conflict is reported, not silently resolved.\n- Read before writing.\n- Do exactly what was asked. Adjacent improvements are a separate request.\n- Keep captures out of the commit — they live in the gitignored scratch directory.\n\n## Must not\n\n- Add new UI, states, screens, or flows — that is `implement`.\n- Redesign components or flows — pattern-level change goes to the design source owner.\n- Suppress accessibility tooling — axe rules, a11y lint plugins — to make a problem\n  disappear. Fix the cause or escalate.\n- Fork the design system. Never copy a library component to patch it locally; extend it\n  or raise the change upstream.\n- Apply a local override where the correct fix is a token or component change.\n- Commit while any validation check is failing.\n- Commit captures or screenshots.\n- Run a full UX review or raise unrelated findings. Note anything you spot as a\n  follow-up; do not fix it under cover of this pass.\n\n## Output format\n\n\u003Cexample>\n## UX Fix Summary\n\n**Branch:** feat\u002Fcheckout-summary\n**Input:** ux-design-review verdict | direct instruction\n**Scope:** warning (blocking + warning) | as instructed\n**Addressed:** 1 blocking, 2 warnings\n\n### Changes Made\n\n- `src\u002Fcomponents\u002FPaymentForm.tsx` [modified]\n  - Blocking (Accessibility, WCAG 2.4.7): added visible focus ring via the\n    `focus-ring` token\n- `src\u002Fcomponents\u002FSummaryCard.tsx` [modified]\n  - Warning (Design Fidelity): replaced hard-coded 12px padding with `space-400`\n  - Warning (Design System): swapped the bespoke badge for `\u003CBadge>` from the library\n\n### Not Addressed (below threshold)\n\n- Suggestion: empty-cart copy reads as an error — out of scope for `fix warning`\n\n### Deferred\n\n- Header uses a 14px size the scale does not provide — needs a design-system decision,\n  raised as PROJ-014\n\n### Disputed\n\n- \"Summary card misaligned at 768\" — the review's capture was of an unstable region\n  (`.order-timer` animating). Re-captured twice: alignment is correct. Marked dismissed.\n\n### Verification\n\n- Baseline: `.ux-review\u002Fbefore\u002F` (direct mode) | review captures (review mode)\n- Re-rendered: payment form (375, 1440), summary card (1440)\n- Neighbour re-check: cart list and totals unchanged at both viewports\n- Axe re-scan on \u002Fcheckout: 0 violations. Keyboard traversal: focus visible at all 9 stops\n- Format \u002F lint \u002F typecheck \u002F build \u002F tests: pass\n\n### Review state\n\n`docs\u002Freviews\u002Fux-design-review.local.json` entry for `feat\u002Fcheckout-summary`\nupdated: 3 fixed, 1 deferred, 1 dismissed. (Direct mode: no state written.)\n\u003C\u002Fexample>\n",{"name":5,"license":15,"metadata":60,"description":66,"allowed-tools":67,"argument-hint":68,"compatibility":69},{"owner":61,"author":62,"version":63,"work_shape":64,"output_class":65},"web-development","Carinya Parc","1.0","targeted-change","code-change","Use when the user wants to change how existing UI looks or behaves — fix spacing, colour, layout, states, responsiveness, or accessibility on a component, page, or flow. Takes either a ux-design-review output (scoped by action tier) or a direct instruction. Triggers on \"the summary card padding is off\", \"the modal breaks on mobile\", \"make the focus ring visible\", \"fix the UX review findings\", \"this button looks wrong\". Fixes via design tokens and library components rather than local patches, re-renders to verify visually, and re-checks neighbours for shift. Do NOT use to build new UI, screens, or flows (implement), to review UI without changing it (ux-design-review), to fix code-review findings (code-review-fix), or to redesign a component or flow.\n","Read Write Edit Glob Grep Bash","[blocking|warning|all] [review-output-path | instruction]","Requires git, the project's validation toolchain, and a runnable UI plus Playwright or browser MCP tools for visual verification.","main","a130b08e73c014d346320ba5258cf89d60b5e070","skills\u002Fux-design-fix",0,"https:\u002F\u002Fgithub.com\u002Fcarinyadigital\u002Fskills","https:\u002F\u002Fgithub.com\u002Fcarinyadigital","carinyadigital.com","AI agents and agentic operations for small and medium businesses.","2026-08-20 06:13:13",{"source":8,"skillName":5,"commands":80,"prompt":90,"zipAvailable":91},[81,84,87],{"tool":82,"command":83},"npx","npx skills add carinyadigital\u002Fskills --skill ux-design-fix",{"tool":85,"command":86},"bunx","bunx skills add carinyadigital\u002Fskills --skill ux-design-fix",{"tool":88,"command":89},"pnpm","pnpm dlx skills add carinyadigital\u002Fskills --skill ux-design-fix","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fcarinyadigital\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fux-design-fix\u002FSKILL.md",true,[93,99],{"path":94,"resourceType":95,"resourceTypeDesc":96,"sizeBytes":97,"sourceHtmlUrl":98},"evals\u002Fevals.json","REFERENCE","参考文档",4259,"https:\u002F\u002Fgithub.com\u002Fcarinyadigital\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fux-design-fix\u002Fevals\u002Fevals.json",{"path":100,"resourceType":95,"resourceTypeDesc":96,"sizeBytes":101,"sourceHtmlUrl":102},"evals\u002Ftrigger-queries.json",2110,"https:\u002F\u002Fgithub.com\u002Fcarinyadigital\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fux-design-fix\u002Fevals\u002Ftrigger-queries.json",[104,119,146,169,186,202],{"skillNo":105,"name":106,"nameZh":6,"description":107,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":108,"categories":109,"keywords":111,"publishedAt":55},"01M71N0PD9RJD79MXQR54DART2","skill-name","Replace with description of the skill and when the agent should use it.","https:\u002F\u002Fgithub.com\u002Fcarinyadigital\u002Fskills\u002Fblob\u002Fmain\u002Ftemplate\u002FSKILL.md",[110],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[112,113,114,115,116,42,117,118],"skill name","name","with","replace","use","author","it",{"skillNo":120,"name":121,"nameZh":6,"description":122,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":123,"categories":124,"keywords":130,"publishedAt":55},"01M71N0D9N2NSX040S4WST3TG3","validate","Use when the user wants final completion sign-off on any work item — epic, story, bug, or spike: every task in docs\u002Fwork\u002F{work-id}\u002Ftasks.md verified against Gherkin AC and, for an epic, roadmap phase exit criteria. Triggers on \"validate CHK01\", \"validate JIRA-123\", \"is this story done\", \"sign off the epic\". Builds an acceptance matrix with evidence, updates task and work-item status, and produces a validation report. Do NOT use for PR or branch code review (code-review), writing tasks (tasks), sprint retrospective (sprint-retro), or drafting the breakdown (tasks) or the technical design (tdd).","https:\u002F\u002Fgithub.com\u002Fcarinyadigital\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fvalidate\u002FSKILL.md",[125,128,129],{"categoryNo":126,"categoryName":127,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[121,131,132,133,134,135,35,136,137,44,138,139,140,42,141,142,41,143,144,145],"back","branch","sprint","code review","decision","remote","decision-support","writing","acceptance","roadmap","updates","done","code","tasks","drafting",{"skillNo":147,"name":148,"nameZh":6,"description":149,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":150,"categories":151,"keywords":155,"publishedAt":55},"01M71N056DQWSSSYHSWYF7MNM6","ux-design-review","Use when the user wants a UX or design review of implemented UI — components, pages, or flows — against its design source, covering accessibility (WCAG 2.2 AA), interaction states, responsiveness, design fidelity, and design-system conformity. Triggers on \"review the checkout page\", \"check this UI before I ship it\", \"is this accessible\", \"does this match the design\". Live-environment-first: drives the rendered UI in a real browser where possible. Works with any framework or design tooling. Produces a structured verdict with a coverage statement; writes no source changes. Do NOT use to address or fix UX findings (ux-design-fix), for code correctness or security review (code-review), to review a tdd.md document (docs-review), or to implement features (implement).","https:\u002F\u002Fgithub.com\u002Fcarinyadigital\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fux-design-review\u002FSKILL.md",[152,153,154],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":32,"categoryName":33,"taxonomyType":29,"taxonomyTypeDesc":30},[35,156,157,36,38,158,159,132,160,54,161,40,44,162,163,164,165,166,167,168],"ux design review","review","design review","reviews","figma","static","URL","components","server","interaction","security review","figma mcp","read",{"skillNo":170,"name":171,"nameZh":6,"description":172,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":173,"categories":174,"keywords":177,"publishedAt":55},"01M71MZNT1G9Q83P374S8KCPTY","tdd","Use when the user wants a technical design document (TDD) for any work item — epic, story, bug, or spike — at docs\u002Fwork\u002F{work-id}\u002Ftdd.md, in skeleton or full mode. Pass a work item ID (CHK01, or a Linear\u002FJira\u002FGitHub key like JIRA-123). Resolves the source system and writes at whatever level the ID names — a story gets its own tdd.md beside its parent epic's, not nested inside it. Cite solution.md — do not re-narrate architecture. Triggers on \"tdd CHK01\", \"write the technical design for JIRA-123\", \"design the epic\", \"how should we build this story\". For reviewing an existing tdd.md, use docs-review instead. Do NOT use for test-driven development — writing a failing test first, red\u002Fgreen\u002Frefactor, or any test-authoring task is implement. Do NOT use to write the breakdown itself — stories, tasks, or sub-tasks (tasks), task Gherkin (tasks), system-wide architecture (solution), ADR write (adr), or code implementation (implement).","https:\u002F\u002Fgithub.com\u002Fcarinyadigital\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Ftdd\u002FSKILL.md",[175,176],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[171,131,178,179,51,180,181,182,35,136,44,138,42,41,143,144,183,157,184,185],"test-driven","green","mode","failing","skeleton","architecture","notes","work",{"skillNo":187,"name":144,"nameZh":6,"description":188,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":189,"categories":190,"keywords":195,"publishedAt":55},"01M71MZCPYDVZQCS12F54SJHHS","Use to decompose anything into delivery work — a product strategy and roadmap into epics, an epic into stories and tasks with Gherkin acceptance criteria, a story into sub-tasks, or an external spec, RFC, or PRD into both in one pass. Resolves the work item's source system (Linear, Jira, GitHub\u002FGitLab issues, or filesystem) and its type first. Writes docs\u002Fproduct\u002Fbacklog.md and docs\u002Fwork\u002F{work-id}\u002Ftasks.md, or the tracker directly when one is resolved. Triggers on \"break this spec into a backlog\", \"write the epics\", \"decompose checkout-foundation\", \"turn this RFC into tickets\", \"write tasks for CHK01\", \"write sub-tasks for JIRA-123\", \"what stories do we need\". EARS with --ears. Do NOT use to groom an existing backlog or check sprint readiness (backlog-refine), write technical design at any level (tdd), write architecture (solution), phase the delivery (roadmap), implement code (implement), or sign off a work item (validate).","https:\u002F\u002Fgithub.com\u002Fcarinyadigital\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Ftasks\u002FSKILL.md",[191,192],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":193,"categoryName":194,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000031","产品经理",[144,131,133,196,197,35,198,136,44,139,140,42,41,143,183,199,184,185,200,201],"checkout","issues","gherkin acceptance criteria","phase","solution","gitlab",{"skillNo":203,"name":204,"nameZh":6,"description":205,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":206,"categories":207,"keywords":208,"publishedAt":55},"01M71MZ97K2FPF3HHYMKM4WRCV","sprint-retro","Use when the user wants to run a retrospective after a sprint ends — compare what was committed in plan.md against what actually shipped, surface themes with evidence, and record actions with owners routed to the skill that will action them, at docs\u002Fwork\u002Fsprint-{id}\u002Fretrospective.md. Triggers on \"run the retro\", \"sprint retrospective\", \"what went wrong last sprint\", \"how did sprint 3 go\". Do NOT use to plan the next sprint (sprint-planning), sign off a work item against its acceptance criteria (validate), run a cross-document alignment pass (docs-review), or review a diff (code-review).","https:\u002F\u002Fgithub.com\u002Fcarinyadigital\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fsprint-retro\u002FSKILL.md",[],[133,209,210,211,212,135,137,213,139,42,143,214,157,184,185,215,216,217,218,219],"sprint retro","retro","alignment","actions","themes","code-review","sprint-planning","plan","next","how","support"]