[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71MZNT1G9Q83P374S8KCPTY":3,"skill-same:01M71MZNT1G9Q83P374S8KCPTY":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":26,"publishedAt":46,"linkOnly":47,"markdownContent":48,"markdownBody":49,"frontMatter":50,"refName":60,"commitSha":61,"skillDirectory":62,"forksCount":63,"repositoryHtmlUrl":64,"repositoryHomepageUrl":6,"ownerHtmlUrl":65,"ownerBlogUrl":66,"ownerDescription":67,"updatedAt":68,"install":69,"resources":82},"01M71MZNT1G9Q83P374S8KCPTY","tdd",null,"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).","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\u002Ftdd\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[5,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45],"MCP","work","notes","review","architecture","tasks","code","Bash","when","writing","remote","design","skeleton","failing","mode","re","green","test-driven","back","2026-11-10 10:56:23",false,"---\nname: tdd\ndescription: >\n  Use when the user wants a technical design document (TDD) for any work item —\n  epic, story, bug, or spike — at docs\u002Fwork\u002F{work-id}\u002Ftdd.md, in skeleton or\n  full mode. Pass a work item ID (CHK01, or a Linear\u002FJira\u002FGitHub key like\n  JIRA-123). Resolves the source system and writes at whatever level the ID\n  names — a story gets its own tdd.md beside its parent epic's, not nested\n  inside it. Cite solution.md — do not re-narrate architecture. Triggers on\n  \"tdd CHK01\", \"write the technical design for JIRA-123\", \"design the epic\",\n  \"how should we build this story\". For reviewing an existing tdd.md, use\n  docs-review instead. Do NOT use for test-driven development — writing a\n  failing test first, red\u002Fgreen\u002Frefactor, or any test-authoring task is\n  implement. Do NOT use to write the breakdown itself — stories, tasks, or\n  sub-tasks (tasks), task Gherkin (tasks), system-wide architecture (solution),\n  ADR write (adr), or code implementation (implement).\nlicense: MIT\ncompatibility: Tracker resolution uses Linear, Atlassian (Jira), or GitHub\u002FGitLab MCP tools when available, or `git remote`\u002F`gh`\u002F`glab`; falls back to the filesystem when none are reachable.\nallowed-tools: Read Write Edit Glob Grep Bash(git remote:*) Bash(git mv:*) Bash(gh:*) Bash(glab:*)\nargument-hint: \"\u003Cwork-id> [--mode skeleton|full] [--context \u003Cnotes>]\"\nmetadata:\n  author: Carinya Parc\n  version: \"4.0\"\n  owner: architecture\n  work_shape: authoring\n  output_class: delivery-artefact\n---\n\n# Technical design document\n\nYou are a Software Architect writing a technical design document at\n`docs\u002Fwork\u002F{work-id}\u002Ftdd.md`, for whatever work item the argument names —\nan epic, a story, a bug, or a spike. Read\n[work-item-resolution.md](..\u002Ftasks\u002Freferences\u002Fwork-item-resolution.md)\n**first** — it resolves the source system and canonical ID before you touch\nthe backlog or the tracker. If the ID resolves to a story, bug, or spike, also\nread its parent epic's context (backlog row or tracker epic, and its\n`tdd.md` if one exists) — cite it by ID rather than re-narrating it.\n\nThis skill writes design documents. It is **not** test-driven development —\nrequests to write a failing test first, or to drive code through red\u002Fgreen\u002F\nrefactor, belong to **implement**.\n\n## Conventions\n\nRead [delivery-conventions.md](..\u002Ftasks\u002Freferences\u002Fdelivery-conventions.md)\nwhen resolving `{work-id}` or checking artefact boundaries.\n\n## Artefact\n\n`docs\u002Fwork\u002F{work-id}\u002Ftdd.md` — implementation specification for one work\nitem (skeleton or full), keyed by *that item's own* canonical ID. A\nstory's TDD sits at `docs\u002Fwork\u002F{story-id}\u002Ftdd.md`, alongside its parent\nepic's folder, not inside it.\n\n## Path resolution\n\nDefault: `docs\u002Fwork\u002F{work-id}\u002Ftdd.md`. User-named paths under `docs\u002Fwork\u002F` override.\n\nRepos written before this skill was renamed from `design` hold the same\nartefact at `docs\u002Fwork\u002F{work-id}\u002Fdesign.md`. When that file exists and\n`tdd.md` does not, say so, `git mv` it to `tdd.md`, and update it in place —\nnever leave two copies of the same design side by side.\n\n## Mode (`--mode`)\n\n- `skeleton` — walking skeleton, Phase 0, 2–4 pages\n- `full` — Sprint 2+, 5–10 pages\n\n## Negative constraints\n\nDo NOT put in tdd.md:\n\n- Architecture-wide patterns already in solution.md — cite `solution.md §{N.M}`\n- Business strategy → `docs\u002Fproduct\u002Fproduct.md`\n- Phase sequencing → `docs\u002Fproduct\u002Froadmap.md`\n- Task-level Gherkin → `docs\u002Fwork\u002F{work-id}\u002Ftasks.md` via **tasks**\n\n## Context\n\n[Work item row in backlog.md or the tracker, solution.md, parent epic's\ntdd.md if this is a story\u002Fbug\u002Fspike, existing tdd.md (or legacy design.md)\nif updating, codebase]\n\n## Steps (skeleton)\n\n1. Read solution.md and the work item's row (backlog.md or the tracker); if\n   it is a story, bug, or spike, also read its parent epic's tdd.md\n2. Draft §1–§6 per template\n3. §4 must list what this work item did **not** ship\n\n## Steps (full)\n\n1. Read all context\n2. Draft §1–§12 per template\n\n## Pre-save validation\n\n- [ ] Work item resolved per work-item-resolution.md — asked the user on any\n  ambiguity in source system or ID\n- [ ] Path is `docs\u002Fwork\u002F{work-id}\u002Ftdd.md` keyed by this item's own\n  canonical ID (filesystem-only: correct slug, ≤2 words, not the internal ID)\n- [ ] A legacy `design.md` for this work item was moved, not duplicated\n- [ ] A story\u002Fbug\u002Fspike TDD cites its parent epic by ID rather than\n  duplicating its tdd.md\n- [ ] Solution cited by section; no duplicated architecture narrative\n- [ ] No Gherkin task scenarios (gates\u002Fslice only)\n- [ ] Mode-appropriate sections only (skeleton vs full)\n- [ ] DRAFTING AIDE block removed\n\n## Output format\n\nSave to `docs\u002Fwork\u002F{work-id}\u002Ftdd.md`. Use [assets\u002Ftdd.template.md](assets\u002Ftdd.template.md).\n\n## Gotchas\n\n- **Do not copy solution.md** — cite `solution.md §{N.M}` instead.\n- **Task Gherkin** belongs in `tasks.md`, not the TDD (gates\u002Fslice scope only).\n- **`skeleton`** is 2–4 pages; **`full`** is 5–10 — do not mix section sets.\n- **§4 Out of scope** must list what this work item explicitly did not ship.\n\n## ADR candidates\n\nDecisions recorded in `tdd.md` do not reach the architecture register on\ntheir own. After the work item ships, run `adr plan \u003Cwork-id>` to harvest\nthem — it triages each candidate into promote, inline, or defer, and hands\nthe promoted ones to **adr write**.\n\n## Supporting files\n\n- [assets\u002Ftdd.template.md](assets\u002Ftdd.template.md)\n- [examples\u002Fcheckout-foundation.md](examples\u002Fcheckout-foundation.md)\n\n## Related skills\n\n- `tasks`, `solution`, `adr`\n- `implement` — test-driven development, i.e. actually writing the tests and code\n- `docs-review` — review or critique an existing tdd.md\n","# Technical design document\n\nYou are a Software Architect writing a technical design document at\n`docs\u002Fwork\u002F{work-id}\u002Ftdd.md`, for whatever work item the argument names —\nan epic, a story, a bug, or a spike. Read\n[work-item-resolution.md](..\u002Ftasks\u002Freferences\u002Fwork-item-resolution.md)\n**first** — it resolves the source system and canonical ID before you touch\nthe backlog or the tracker. If the ID resolves to a story, bug, or spike, also\nread its parent epic's context (backlog row or tracker epic, and its\n`tdd.md` if one exists) — cite it by ID rather than re-narrating it.\n\nThis skill writes design documents. It is **not** test-driven development —\nrequests to write a failing test first, or to drive code through red\u002Fgreen\u002F\nrefactor, belong to **implement**.\n\n## Conventions\n\nRead [delivery-conventions.md](..\u002Ftasks\u002Freferences\u002Fdelivery-conventions.md)\nwhen resolving `{work-id}` or checking artefact boundaries.\n\n## Artefact\n\n`docs\u002Fwork\u002F{work-id}\u002Ftdd.md` — implementation specification for one work\nitem (skeleton or full), keyed by *that item's own* canonical ID. A\nstory's TDD sits at `docs\u002Fwork\u002F{story-id}\u002Ftdd.md`, alongside its parent\nepic's folder, not inside it.\n\n## Path resolution\n\nDefault: `docs\u002Fwork\u002F{work-id}\u002Ftdd.md`. User-named paths under `docs\u002Fwork\u002F` override.\n\nRepos written before this skill was renamed from `design` hold the same\nartefact at `docs\u002Fwork\u002F{work-id}\u002Fdesign.md`. When that file exists and\n`tdd.md` does not, say so, `git mv` it to `tdd.md`, and update it in place —\nnever leave two copies of the same design side by side.\n\n## Mode (`--mode`)\n\n- `skeleton` — walking skeleton, Phase 0, 2–4 pages\n- `full` — Sprint 2+, 5–10 pages\n\n## Negative constraints\n\nDo NOT put in tdd.md:\n\n- Architecture-wide patterns already in solution.md — cite `solution.md §{N.M}`\n- Business strategy → `docs\u002Fproduct\u002Fproduct.md`\n- Phase sequencing → `docs\u002Fproduct\u002Froadmap.md`\n- Task-level Gherkin → `docs\u002Fwork\u002F{work-id}\u002Ftasks.md` via **tasks**\n\n## Context\n\n[Work item row in backlog.md or the tracker, solution.md, parent epic's\ntdd.md if this is a story\u002Fbug\u002Fspike, existing tdd.md (or legacy design.md)\nif updating, codebase]\n\n## Steps (skeleton)\n\n1. Read solution.md and the work item's row (backlog.md or the tracker); if\n   it is a story, bug, or spike, also read its parent epic's tdd.md\n2. Draft §1–§6 per template\n3. §4 must list what this work item did **not** ship\n\n## Steps (full)\n\n1. Read all context\n2. Draft §1–§12 per template\n\n## Pre-save validation\n\n- [ ] Work item resolved per work-item-resolution.md — asked the user on any\n  ambiguity in source system or ID\n- [ ] Path is `docs\u002Fwork\u002F{work-id}\u002Ftdd.md` keyed by this item's own\n  canonical ID (filesystem-only: correct slug, ≤2 words, not the internal ID)\n- [ ] A legacy `design.md` for this work item was moved, not duplicated\n- [ ] A story\u002Fbug\u002Fspike TDD cites its parent epic by ID rather than\n  duplicating its tdd.md\n- [ ] Solution cited by section; no duplicated architecture narrative\n- [ ] No Gherkin task scenarios (gates\u002Fslice only)\n- [ ] Mode-appropriate sections only (skeleton vs full)\n- [ ] DRAFTING AIDE block removed\n\n## Output format\n\nSave to `docs\u002Fwork\u002F{work-id}\u002Ftdd.md`. Use [assets\u002Ftdd.template.md](assets\u002Ftdd.template.md).\n\n## Gotchas\n\n- **Do not copy solution.md** — cite `solution.md §{N.M}` instead.\n- **Task Gherkin** belongs in `tasks.md`, not the TDD (gates\u002Fslice scope only).\n- **`skeleton`** is 2–4 pages; **`full`** is 5–10 — do not mix section sets.\n- **§4 Out of scope** must list what this work item explicitly did not ship.\n\n## ADR candidates\n\nDecisions recorded in `tdd.md` do not reach the architecture register on\ntheir own. After the work item ships, run `adr plan \u003Cwork-id>` to harvest\nthem — it triages each candidate into promote, inline, or defer, and hands\nthe promoted ones to **adr write**.\n\n## Supporting files\n\n- [assets\u002Ftdd.template.md](assets\u002Ftdd.template.md)\n- [examples\u002Fcheckout-foundation.md](examples\u002Fcheckout-foundation.md)\n\n## Related skills\n\n- `tasks`, `solution`, `adr`\n- `implement` — test-driven development, i.e. actually writing the tests and code\n- `docs-review` — review or critique an existing tdd.md\n",{"name":5,"license":15,"metadata":51,"description":56,"allowed-tools":57,"argument-hint":58,"compatibility":59},{"owner":31,"author":52,"version":53,"work_shape":54,"output_class":55},"Carinya Parc","4.0","authoring","delivery-artefact","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).\n","Read Write Edit Glob Grep Bash(git remote:*) Bash(git mv:*) Bash(gh:*) Bash(glab:*)","\u003Cwork-id> [--mode skeleton|full] [--context \u003Cnotes>]","Tracker resolution uses Linear, Atlassian (Jira), or GitHub\u002FGitLab MCP tools when available, or `git remote`\u002F`gh`\u002F`glab`; falls back to the filesystem when none are reachable.","main","a130b08e73c014d346320ba5258cf89d60b5e070","skills\u002Ftdd",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":70,"prompt":80,"zipAvailable":81},[71,74,77],{"tool":72,"command":73},"npx","npx skills add carinyadigital\u002Fskills --skill tdd",{"tool":75,"command":76},"bunx","bunx skills add carinyadigital\u002Fskills --skill tdd",{"tool":78,"command":79},"pnpm","pnpm dlx skills add carinyadigital\u002Fskills --skill tdd","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fcarinyadigital\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Ftdd\u002FSKILL.md",true,[83,89,95,99],{"path":84,"resourceType":85,"resourceTypeDesc":86,"sizeBytes":87,"sourceHtmlUrl":88},"assets\u002Ftdd.template.md","ASSET","资产文件",3421,"https:\u002F\u002Fgithub.com\u002Fcarinyadigital\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Ftdd\u002Fassets\u002Ftdd.template.md",{"path":90,"resourceType":91,"resourceTypeDesc":92,"sizeBytes":93,"sourceHtmlUrl":94},"evals\u002Fevals.json","REFERENCE","参考文档",1187,"https:\u002F\u002Fgithub.com\u002Fcarinyadigital\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Ftdd\u002Fevals\u002Fevals.json",{"path":96,"resourceType":91,"resourceTypeDesc":92,"sizeBytes":97,"sourceHtmlUrl":98},"evals\u002Ftrigger-queries.json",1157,"https:\u002F\u002Fgithub.com\u002Fcarinyadigital\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Ftdd\u002Fevals\u002Ftrigger-queries.json",{"path":100,"resourceType":91,"resourceTypeDesc":92,"sizeBytes":101,"sourceHtmlUrl":102},"examples\u002Fcheckout-foundation.md",825,"https:\u002F\u002Fgithub.com\u002Fcarinyadigital\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Ftdd\u002Fexamples\u002Fcheckout-foundation.md",[104,119,141,171,195,211],{"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":46},"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,35,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":46},"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,45,131,132,133,134,38,37,135,27,36,136,137,35,138,139,34,33,32,140],"branch","sprint","code review","decision","decision-support","acceptance","roadmap","updates","done","drafting",{"skillNo":142,"name":143,"nameZh":6,"description":144,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":145,"categories":146,"keywords":154,"publishedAt":46},"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",[147,148,149],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":150,"categoryName":151,"taxonomyType":152,"taxonomyTypeDesc":153},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[38,155,30,156,157,158,159,131,160,161,162,163,27,164,165,166,167,168,169,170],"ux design review","ux","ux design","design review","reviews","figma","browser mcp","static","fix","URL","components","server","interaction","security review","figma mcp","read",{"skillNo":172,"name":173,"nameZh":6,"description":174,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":175,"categories":176,"keywords":183,"publishedAt":46},"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",[177,178,179,182],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":180,"categoryName":181,"taxonomyType":152,"taxonomyTypeDesc":153},"01JBSEEDCAT000000000000030","开发工程师",{"categoryNo":150,"categoryName":151,"taxonomyType":152,"taxonomyTypeDesc":153},[163,38,156,184,157,185,161,186,187,42,188,189,190,191,192,193,27,194,35,34],"ux design fix","design fix","states","project","review findings","card","flows","local","ux-design","new","either",{"skillNo":196,"name":32,"nameZh":6,"description":197,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":198,"categories":199,"keywords":204,"publishedAt":46},"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",[200,201],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":202,"categoryName":203,"taxonomyType":152,"taxonomyTypeDesc":153},"01JBSEEDCAT000000000000031","产品经理",[32,45,132,205,206,38,207,37,27,136,137,35,34,33,31,208,29,28,209,210],"checkout","issues","gherkin acceptance criteria","phase","solution","gitlab",{"skillNo":212,"name":213,"nameZh":6,"description":214,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":215,"categories":216,"keywords":217,"publishedAt":46},"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",[],[132,218,219,220,221,134,135,222,136,35,33,223,30,29,28,224,225,226,227,228],"sprint retro","retro","alignment","actions","themes","code-review","sprint-planning","plan","next","how","support"]