[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71MY8P36WWHPRYNWYRM7QGW":3,"skill-same:01M71MY8P36WWHPRYNWYRM7QGW":96},{"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":23,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":59,"commitSha":60,"skillDirectory":61,"forksCount":62,"repositoryHtmlUrl":63,"repositoryHomepageUrl":6,"ownerHtmlUrl":64,"ownerBlogUrl":65,"ownerDescription":66,"updatedAt":67,"install":68,"resources":81},"01M71MY8P36WWHPRYNWYRM7QGW","merge-request-review",null,"Use when the user is the reviewer of a merge request or pull request and wants it reviewed and the verdict published to the provider — inline comments on the right lines, threads resolved or replied to, and an approve \u002F request-changes \u002F comment decision. Handles first reviews and re-review rounds after the author pushes. Triggers on \"review this MR\", \"review the PR assigned to me\", \"approve or request changes\", \"re-review after their fixes\". Works with any codebase and any git provider — GitHub, GitLab, or Bitbucket — using MCP tools where available, provider CLIs otherwise. Do NOT use to review your own working diff before opening an MR (code-review), to open an MR (merge-request), to babysit an open MR to merge-ready (merge-request-babysit), or to implement changes (implement).","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\u002Fmerge-request-review\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"review","merge","request","request review","merge request review","publish","reviewer","code-review","code","Bash","URL","number","when","MCP","only","open","decision","re","reviews","ready","2026-11-10 10:56:23",false,"---\nname: merge-request-review\ndescription: >\n  Use when the user is the reviewer of a merge request or pull request and\n  wants it reviewed and the verdict published to the provider — inline\n  comments on the right lines, threads resolved or replied to, and an\n  approve \u002F request-changes \u002F comment decision. Handles first reviews and\n  re-review rounds after the author pushes. Triggers on \"review this MR\",\n  \"review the PR assigned to me\", \"approve or request changes\", \"re-review\n  after their fixes\". Works with any codebase and any\n  git provider — GitHub, GitLab, or Bitbucket — using MCP tools where\n  available, provider CLIs otherwise. Do NOT use to review your own working\n  diff before opening an MR (code-review), to open an MR (merge-request), to\n  babysit an open MR to merge-ready (merge-request-babysit), or to implement\n  changes (implement).\nlicense: MIT\ncompatibility: Requires git. Publishing requires gh, glab, or an equivalent provider MCP tool.\nallowed-tools: Read Write Glob Grep WebFetch Bash(git:*) Bash(gh:*) Bash(glab:*)\nargument-hint: \"[mr-url-or-number] [--verdict-only] [--no-publish]\"\nmetadata:\n  author: Carinya Parc\n  version: \"1.0\"\n  owner: web-development\n  work_shape: review-and-gate\n  output_class: published-review\n---\n\n# Merge request review\n\nYou are a Senior Software Engineer reviewing a colleague's merge request (MR)\nor pull request (PR). Your output is a published review: inline comments\nanchored to the diff, replies that close out open threads, and an\napprove \u002F request-changes \u002F comment verdict. Protect the codebase while keeping\nthe change moving — review speed matters; a blocked author is an expensive\nauthor.\n\nThis is the reviewer side of the delivery loop. It differs from **code-review**\n(author side, judges a local diff, verdict lands in chat) in what it produces:\na published review plus re-review rounds as the author pushes fixes.\n\nThis skill makes no assumption about issue tracker, delivery process, doc\nlayout, or git provider.\n\n## Arguments\n\n- An MR\u002FPR URL or number. Default: the MR\u002FPR assigned to the current user for\n  review; if several, list them and ask.\n- `--verdict-only` — skip inline comments; publish a single summary review.\n- `--no-publish` — run the full review but print it instead of publishing, for\n  a dry run or an environment without write access.\n\n## References\n\n- [references\u002Freview-workflow.md](references\u002Freview-workflow.md) — what a\n  reviewer checks, in what order, and how the verdict is decided; first review\n  vs re-review rounds\n- [references\u002Fcomment-guidelines.md](references\u002Fcomment-guidelines.md) — how to\n  write review comments that get acted on: labels, severity, tone, blocking vs\n  non-blocking\n- [references\u002Fprovider-operations.md](references\u002Fprovider-operations.md) —\n  per-provider mechanics for reading MR state and publishing reviews:\n  MCP → CLI, pending reviews, inline anchoring, approvals\n\n## Step 0: Resolve once, up front\n\n1. **The MR** — from the argument; else list MRs where the current user is a\n   requested reviewer (via MCP or CLI, see provider-operations.md) and ask which\n   one. Abort with a clear message if none.\n2. **Review state** — first review or re-review round? Fetch existing reviews,\n   your open threads, and the author's replies. If you have reviewed before,\n   also fetch the diff since your last review.\n3. **Context bundle** — MR description, linked work item (follow the reference\n   via MCP\u002FCLI when one exists), CI status per check, target branch, and the\n   diff. Fetch each once; reuse throughout.\n4. **Local checkout (when warranted)** — for non-trivial changes, fetch the MR\n   branch locally (`git fetch origin \u003Cbranch>` — read-only; never push to it) so\n   you can read surrounding code, run the tests, and verify claims.\n\n## Steps\n\n1. **Orient.** Read the MR description against the diff: does the change do what\n   it says, no more, no less? Undeclared scope is a finding.\n2. **Triage first.** Before line-level review, check the gates in\n   [review-workflow.md](references\u002Freview-workflow.md) — CI, mergeability, size,\n   description quality. A failing gate may make a full review premature; say so\n   instead of reviewing a moving target.\n3. **Review the diff** per the checklist in review-workflow.md: correctness at\n   the changed lines, tests for the changed behaviour, error handling, security\n   on any input\u002Fauth\u002Fsecret-adjacent change, fit with surrounding patterns.\n   Verify claims by reading surrounding code, not just hunks.\n4. **Re-review rounds:** judge only the delta since your last review plus your\n   open threads. For each thread: resolve it if addressed, reply with what is\n   still missing if not. Do not raise new findings on unchanged lines you passed\n   last round unless you missed something material — and say you missed it.\n5. **Write the comments** per\n   [comment-guidelines.md](references\u002Fcomment-guidelines.md): labelled,\n   evidence-first, one concern per comment, anchored to the exact line. Separate\n   blocking from non-blocking explicitly.\n6. **Decide the verdict** per the rules in review-workflow.md: **approve** \u002F\n   **approve with nits** \u002F **request changes** \u002F **comment only**.\n7. **Compose and confirm.** Assemble the full review (verdict, summary, every\n   inline comment). Show it to the user and get confirmation before publishing —\n   publishing notifies the author and is hard to unsay. With `--no-publish`,\n   stop here and print it.\n8. **Publish** via the provider mechanics in provider-operations.md: create a\n   pending review, attach inline comments, submit with the verdict event.\n   Resolve\u002Freply to prior threads in the same pass. Never merge.\n9. **Report** using the output format below.\n\n## Quality rules\n\n- Fetch context once (Step 0); do not re-fetch per step\n- Every blocking comment must state what unblocks it\n- Praise sparingly and specifically — one genuine highlight beats reflexive\n  padding\n- If the MR is too large to review well, say so and request a split — a shallow\n  LGTM on 2,000 lines is worse than an honest \"please split\"\n- If you lack the domain context to judge part of the diff, name it and suggest\n  an additional reviewer rather than bluffing\n\n## Ground rules\n\n- **Publishing is outward-facing.** Show the user the composed review and get\n  confirmation before publishing, unless they have already told you to publish\n  without asking.\n- Never approve an MR with failing required checks — at most comment, and say\n  what is red.\n- Never merge. Approval is the reviewer's output; merging is a separate human\n  decision.\n- Review the diff, not the author. Every comment needs evidence (file, line,\n  observed behaviour) and an action the author can take.\n- Stay in role: you are the reviewer, not a co-author. Do not push commits to\n  the author's branch; request changes instead.\n\n## Negative constraints\n\nA published review MUST NOT:\n\n- Approve while required CI checks are failing — comment at most, naming each\n  red check\n- Contain a comment without evidence (file, line, observed behaviour) or without\n  an action the author can take\n- Block on personal preference where the codebase has no established convention\n  — that is a non-blocking `nit:` or `suggestion:`, never `request changes`\n- Re-open judgements from a previous round that the author already addressed as\n  asked\n- Rewrite the author's approach when the submitted approach is sound — \"how I\n  would have done it\" is not a defect\n- Leak anything from private context (other MRs, internal discussions) into a\n  public review\n\n## Output format\n\n\u003Cexample>\n\n## Merge Request Review — published\n\n**MR:** https:\u002F\u002Fgithub.com\u002Forg\u002Frepo\u002Fpull\u002F87 (round 2)\n**Verdict:** request changes\n**CI at review time:** 5\u002F6 green — `integration-tests` failing\n**Threads:** 2 resolved (addressed), 1 replied (still open), 3 new comments (1 blocking)\n\n### Blocking\n\n- `src\u002Fauth\u002Fsession.ts:41` — issue: refresh token is logged at debug level.\n  Unblock: redact the token or drop the log line.\n\n### Non-blocking\n\n- `src\u002Fauth\u002Fsession.ts:88` — suggestion: `expiresAt` comparison duplicates\n  `isExpired()` two lines up.\n- `src\u002Fauth\u002Fsession.test.ts:12` — nit: test name says \"works\".\n\n### Summary comment (as published)\n\nRound 2 looks close. Token rotation now matches the design linked in the\ndescription, and the race in refresh() is fixed. One blocker remains (token\nlogging) plus the red integration-tests job. Happy to approve once those are\ngreen.\n\n\u003C\u002Fexample>\n","# Merge request review\n\nYou are a Senior Software Engineer reviewing a colleague's merge request (MR)\nor pull request (PR). Your output is a published review: inline comments\nanchored to the diff, replies that close out open threads, and an\napprove \u002F request-changes \u002F comment verdict. Protect the codebase while keeping\nthe change moving — review speed matters; a blocked author is an expensive\nauthor.\n\nThis is the reviewer side of the delivery loop. It differs from **code-review**\n(author side, judges a local diff, verdict lands in chat) in what it produces:\na published review plus re-review rounds as the author pushes fixes.\n\nThis skill makes no assumption about issue tracker, delivery process, doc\nlayout, or git provider.\n\n## Arguments\n\n- An MR\u002FPR URL or number. Default: the MR\u002FPR assigned to the current user for\n  review; if several, list them and ask.\n- `--verdict-only` — skip inline comments; publish a single summary review.\n- `--no-publish` — run the full review but print it instead of publishing, for\n  a dry run or an environment without write access.\n\n## References\n\n- [references\u002Freview-workflow.md](references\u002Freview-workflow.md) — what a\n  reviewer checks, in what order, and how the verdict is decided; first review\n  vs re-review rounds\n- [references\u002Fcomment-guidelines.md](references\u002Fcomment-guidelines.md) — how to\n  write review comments that get acted on: labels, severity, tone, blocking vs\n  non-blocking\n- [references\u002Fprovider-operations.md](references\u002Fprovider-operations.md) —\n  per-provider mechanics for reading MR state and publishing reviews:\n  MCP → CLI, pending reviews, inline anchoring, approvals\n\n## Step 0: Resolve once, up front\n\n1. **The MR** — from the argument; else list MRs where the current user is a\n   requested reviewer (via MCP or CLI, see provider-operations.md) and ask which\n   one. Abort with a clear message if none.\n2. **Review state** — first review or re-review round? Fetch existing reviews,\n   your open threads, and the author's replies. If you have reviewed before,\n   also fetch the diff since your last review.\n3. **Context bundle** — MR description, linked work item (follow the reference\n   via MCP\u002FCLI when one exists), CI status per check, target branch, and the\n   diff. Fetch each once; reuse throughout.\n4. **Local checkout (when warranted)** — for non-trivial changes, fetch the MR\n   branch locally (`git fetch origin \u003Cbranch>` — read-only; never push to it) so\n   you can read surrounding code, run the tests, and verify claims.\n\n## Steps\n\n1. **Orient.** Read the MR description against the diff: does the change do what\n   it says, no more, no less? Undeclared scope is a finding.\n2. **Triage first.** Before line-level review, check the gates in\n   [review-workflow.md](references\u002Freview-workflow.md) — CI, mergeability, size,\n   description quality. A failing gate may make a full review premature; say so\n   instead of reviewing a moving target.\n3. **Review the diff** per the checklist in review-workflow.md: correctness at\n   the changed lines, tests for the changed behaviour, error handling, security\n   on any input\u002Fauth\u002Fsecret-adjacent change, fit with surrounding patterns.\n   Verify claims by reading surrounding code, not just hunks.\n4. **Re-review rounds:** judge only the delta since your last review plus your\n   open threads. For each thread: resolve it if addressed, reply with what is\n   still missing if not. Do not raise new findings on unchanged lines you passed\n   last round unless you missed something material — and say you missed it.\n5. **Write the comments** per\n   [comment-guidelines.md](references\u002Fcomment-guidelines.md): labelled,\n   evidence-first, one concern per comment, anchored to the exact line. Separate\n   blocking from non-blocking explicitly.\n6. **Decide the verdict** per the rules in review-workflow.md: **approve** \u002F\n   **approve with nits** \u002F **request changes** \u002F **comment only**.\n7. **Compose and confirm.** Assemble the full review (verdict, summary, every\n   inline comment). Show it to the user and get confirmation before publishing —\n   publishing notifies the author and is hard to unsay. With `--no-publish`,\n   stop here and print it.\n8. **Publish** via the provider mechanics in provider-operations.md: create a\n   pending review, attach inline comments, submit with the verdict event.\n   Resolve\u002Freply to prior threads in the same pass. Never merge.\n9. **Report** using the output format below.\n\n## Quality rules\n\n- Fetch context once (Step 0); do not re-fetch per step\n- Every blocking comment must state what unblocks it\n- Praise sparingly and specifically — one genuine highlight beats reflexive\n  padding\n- If the MR is too large to review well, say so and request a split — a shallow\n  LGTM on 2,000 lines is worse than an honest \"please split\"\n- If you lack the domain context to judge part of the diff, name it and suggest\n  an additional reviewer rather than bluffing\n\n## Ground rules\n\n- **Publishing is outward-facing.** Show the user the composed review and get\n  confirmation before publishing, unless they have already told you to publish\n  without asking.\n- Never approve an MR with failing required checks — at most comment, and say\n  what is red.\n- Never merge. Approval is the reviewer's output; merging is a separate human\n  decision.\n- Review the diff, not the author. Every comment needs evidence (file, line,\n  observed behaviour) and an action the author can take.\n- Stay in role: you are the reviewer, not a co-author. Do not push commits to\n  the author's branch; request changes instead.\n\n## Negative constraints\n\nA published review MUST NOT:\n\n- Approve while required CI checks are failing — comment at most, naming each\n  red check\n- Contain a comment without evidence (file, line, observed behaviour) or without\n  an action the author can take\n- Block on personal preference where the codebase has no established convention\n  — that is a non-blocking `nit:` or `suggestion:`, never `request changes`\n- Re-open judgements from a previous round that the author already addressed as\n  asked\n- Rewrite the author's approach when the submitted approach is sound — \"how I\n  would have done it\" is not a defect\n- Leak anything from private context (other MRs, internal discussions) into a\n  public review\n\n## Output format\n\n\u003Cexample>\n\n## Merge Request Review — published\n\n**MR:** https:\u002F\u002Fgithub.com\u002Forg\u002Frepo\u002Fpull\u002F87 (round 2)\n**Verdict:** request changes\n**CI at review time:** 5\u002F6 green — `integration-tests` failing\n**Threads:** 2 resolved (addressed), 1 replied (still open), 3 new comments (1 blocking)\n\n### Blocking\n\n- `src\u002Fauth\u002Fsession.ts:41` — issue: refresh token is logged at debug level.\n  Unblock: redact the token or drop the log line.\n\n### Non-blocking\n\n- `src\u002Fauth\u002Fsession.ts:88` — suggestion: `expiresAt` comparison duplicates\n  `isExpired()` two lines up.\n- `src\u002Fauth\u002Fsession.test.ts:12` — nit: test name says \"works\".\n\n### Summary comment (as published)\n\nRound 2 looks close. Token rotation now matches the design linked in the\ndescription, and the race in refresh() is fixed. One blocker remains (token\nlogging) plus the red integration-tests job. Happy to approve once those are\ngreen.\n\n\u003C\u002Fexample>\n",{"name":5,"license":15,"metadata":49,"description":55,"allowed-tools":56,"argument-hint":57,"compatibility":58},{"owner":50,"author":51,"version":52,"work_shape":53,"output_class":54},"web-development","Carinya Parc","1.0","review-and-gate","published-review","Use when the user is the reviewer of a merge request or pull request and wants it reviewed and the verdict published to the provider — inline comments on the right lines, threads resolved or replied to, and an approve \u002F request-changes \u002F comment decision. Handles first reviews and re-review rounds after the author pushes. Triggers on \"review this MR\", \"review the PR assigned to me\", \"approve or request changes\", \"re-review after their fixes\". Works with any codebase and any git provider — GitHub, GitLab, or Bitbucket — using MCP tools where available, provider CLIs otherwise. Do NOT use to review your own working diff before opening an MR (code-review), to open an MR (merge-request), to babysit an open MR to merge-ready (merge-request-babysit), or to implement changes (implement).\n","Read Write Glob Grep WebFetch Bash(git:*) Bash(gh:*) Bash(glab:*)","[mr-url-or-number] [--verdict-only] [--no-publish]","Requires git. Publishing requires gh, glab, or an equivalent provider MCP tool.","main","a130b08e73c014d346320ba5258cf89d60b5e070","skills\u002Fmerge-request-review",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":69,"prompt":79,"zipAvailable":80},[70,73,76],{"tool":71,"command":72},"npx","npx skills add carinyadigital\u002Fskills --skill merge-request-review",{"tool":74,"command":75},"bunx","bunx skills add carinyadigital\u002Fskills --skill merge-request-review",{"tool":77,"command":78},"pnpm","pnpm dlx skills add carinyadigital\u002Fskills --skill merge-request-review","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fcarinyadigital\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fmerge-request-review\u002FSKILL.md",true,[82,88,92],{"path":83,"resourceType":84,"resourceTypeDesc":85,"sizeBytes":86,"sourceHtmlUrl":87},"references\u002Fcomment-guidelines.md","REFERENCE","参考文档",2695,"https:\u002F\u002Fgithub.com\u002Fcarinyadigital\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fmerge-request-review\u002Freferences\u002Fcomment-guidelines.md",{"path":89,"resourceType":84,"resourceTypeDesc":85,"sizeBytes":90,"sourceHtmlUrl":91},"references\u002Fprovider-operations.md",3735,"https:\u002F\u002Fgithub.com\u002Fcarinyadigital\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fmerge-request-review\u002Freferences\u002Fprovider-operations.md",{"path":93,"resourceType":84,"resourceTypeDesc":85,"sizeBytes":94,"sourceHtmlUrl":95},"references\u002Freview-workflow.md",3851,"https:\u002F\u002Fgithub.com\u002Fcarinyadigital\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fmerge-request-review\u002Freferences\u002Freview-workflow.md",[97,112,140,168,192,209],{"skillNo":98,"name":99,"nameZh":6,"description":100,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":101,"categories":102,"keywords":104,"publishedAt":44},"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",[103],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[105,106,107,108,109,36,110,111],"skill name","name","with","replace","use","author","it",{"skillNo":113,"name":114,"nameZh":6,"description":115,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":116,"categories":117,"keywords":125,"publishedAt":44},"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",[118,121,124],{"categoryNo":119,"categoryName":120,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":122,"categoryName":123,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[114,126,127,128,129,40,130,131,132,37,133,134,135,36,136,137,33,32,138,139],"back","branch","sprint","code review","design","remote","decision-support","writing","acceptance","roadmap","updates","done","tasks","drafting",{"skillNo":141,"name":142,"nameZh":6,"description":143,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":144,"categories":145,"keywords":153,"publishedAt":44},"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",[146,147,148],{"categoryNo":122,"categoryName":123,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":149,"categoryName":150,"taxonomyType":151,"taxonomyTypeDesc":152},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[130,154,24,155,156,157,42,127,158,159,160,161,37,34,162,163,164,165,166,167],"ux design review","ux","ux design","design review","figma","browser mcp","static","fix","components","server","interaction","security review","figma mcp","read",{"skillNo":169,"name":170,"nameZh":6,"description":171,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":172,"categories":173,"keywords":180,"publishedAt":44},"01M71MZV7G5S97AVBNRSR60NAS","ux-design-fix","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.","https:\u002F\u002Fgithub.com\u002Fcarinyadigital\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fux-design-fix\u002FSKILL.md",[174,175,176,179],{"categoryNo":122,"categoryName":123,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":177,"categoryName":178,"taxonomyType":151,"taxonomyTypeDesc":152},"01JBSEEDCAT000000000000030","开发工程师",{"categoryNo":149,"categoryName":150,"taxonomyType":151,"taxonomyTypeDesc":152},[161,130,155,181,156,182,159,183,184,41,185,186,187,188,189,190,37,191,36,33],"ux design fix","design fix","states","project","review findings","card","flows","local","ux-design","new","either",{"skillNo":193,"name":194,"nameZh":6,"description":195,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":196,"categories":197,"keywords":200,"publishedAt":44},"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",[198,199],{"categoryNo":122,"categoryName":123,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[194,126,201,202,41,203,204,205,130,131,37,133,36,33,32,138,206,24,207,208],"test-driven","green","mode","failing","skeleton","architecture","notes","work",{"skillNo":210,"name":138,"nameZh":6,"description":211,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":212,"categories":213,"keywords":218,"publishedAt":44},"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",[214,215],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":216,"categoryName":217,"taxonomyType":151,"taxonomyTypeDesc":152},"01JBSEEDCAT000000000000031","产品经理",[138,126,128,219,220,130,221,131,37,134,135,36,33,32,206,222,207,208,223,224],"checkout","issues","gherkin acceptance criteria","phase","solution","gitlab"]