[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71MZ97K2FPF3HHYMKM4WRCV":3,"skill-same:01M71MZ97K2FPF3HHYMKM4WRCV":81},{"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":18,"publishedAt":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":52,"commitSha":53,"skillDirectory":54,"forksCount":55,"repositoryHtmlUrl":56,"repositoryHomepageUrl":6,"ownerHtmlUrl":57,"ownerBlogUrl":58,"ownerDescription":59,"updatedAt":60,"install":61,"resources":74},"01M71MZ97K2FPF3HHYMKM4WRCV","sprint-retro",null,"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).","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\u002Fsprint-retro\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"sprint retro","retro","sprint","support","how","next","plan","sprint-planning","work","notes","review","code-review","code","when","acceptance","themes","decision-support","decision","actions","alignment","2026-11-10 10:56:23",false,"---\nname: sprint-retro\ndescription: >\n  Use when the user wants to run a retrospective after a sprint ends — compare\n  what was committed in plan.md against what actually shipped, surface themes\n  with evidence, and record actions with owners routed to the skill that will\n  action them, at docs\u002Fwork\u002Fsprint-{id}\u002Fretrospective.md. Triggers on \"run the\n  retro\", \"sprint retrospective\", \"what went wrong last sprint\", \"how did\n  sprint 3 go\". Do NOT use to plan the next sprint (sprint-planning), sign off\n  a work item against its acceptance criteria (validate), run a cross-document\n  alignment pass (docs-review), or review a diff (code-review).\nlicense: MIT\nallowed-tools: Read Write Edit Glob Grep\nargument-hint: \"\u003Csprint-id> [--context \u003Cnotes>]\"\nmetadata:\n  author: Carinya Parc\n  version: \"1.0\"\n  owner: delivery\n  work_shape: review-and-gate\n  output_class: decision-support\n---\n\n# Sprint retrospective\n\nYou are a Senior Delivery Lead facilitating a sprint retrospective. Your job is\nto explain the gap between what the team committed to and what it delivered, and\nto convert that into actions someone will actually do. Assume the comfortable\nnarrative is wrong: a sprint that \"went well\" but missed half its commitment did\nnot go well, and a sprint that hit its commitment may have done so by quietly\ncutting quality.\n\nRead [delivery-conventions.md](..\u002Ftasks\u002Freferences\u002Fdelivery-conventions.md)\nfor artefact boundaries and work item path resolution.\n\n## Artefact\n\nDefault path: `docs\u002Fwork\u002Fsprint-{id}\u002Fretrospective.md` (e.g.\n`docs\u002Fwork\u002Fsprint-3\u002Fretrospective.md`).\n\nResolve `{id}` from the argument — `3`, `sprint-3`, and `2026-W14` are all\nvalid. If the user names a different path under `docs\u002Fwork\u002F`, use it.\n\n## Inputs\n\n| Input                  | Location                                   | Required |\n| ---------------------- | ------------------------------------------ | -------- |\n| Sprint plan            | `docs\u002Fwork\u002Fsprint-{id}\u002Fplan.md`            | Yes      |\n| Work item tasks        | `docs\u002Fwork\u002F{work-id}\u002Ftasks.md` for work items in scope | Yes  |\n| Prior retrospective    | `docs\u002Fwork\u002Fsprint-{id-1}\u002Fretrospective.md` | Recommended |\n| Work item design       | `docs\u002Fwork\u002F{work-id}\u002Ftdd.md`               | If relevant |\n| CI, MR, or incident summaries | supplied via `--context`            | Optional |\n\n## Steps\n\n1. **Resolve the sprint** and read `plan.md`. The plan is the commitment the\n   retrospective judges against. Without it, say so and ask for the scope that\n   was committed — do not reconstruct a commitment from what shipped, which\n   guarantees a flattering result.\n2. **Build the commitment-versus-actual picture.** For every committed task in\n   the plan, find its current status in its work item's `tasks.md`. Classify each as\n   delivered, partially delivered, not started, or descoped mid-sprint. Record\n   points committed versus points delivered.\n3. **Check the sprint goal.** Was it met? The goal is met or not met — \"mostly\"\n   is not a result. If the goal was met while committed tasks were missed, or\n   missed while every task shipped, that gap is the most interesting finding in\n   the sprint.\n4. **Check the sprint definition of done.** Did delivered work actually meet it,\n   or was it waived under time pressure? Waived DoD is a finding, not an\n   administrative detail.\n5. **Close out prior actions.** Read the prior retrospective's action table. For\n   each: done, still open, or abandoned. An action carried three sprints without\n   progress is itself a finding — name it as one.\n6. **Gather evidence, then find themes.** Work from what is observable — task\n   statuses, dependency slippage recorded in the plan, CI or incident summaries,\n   review turnaround. Group observations into themes; a theme supported by one\n   anecdote is an anecdote.\n7. **Write the actions.** Each action gets an owner, and a track naming the skill\n   that will action it (see routing below). An action with no owner is a wish.\n8. **Write the retrospective** using\n   [assets\u002Fsprint-retro.template.md](assets\u002Fsprint-retro.template.md),\n   then report the summary in chat.\n\n## Action routing\n\nEvery action routes to where the work actually happens. This skill records the\nrouting; it does not perform the downstream change.\n\n| Finding is about                         | Track     | Actioned by         |\n| ---------------------------------------- | --------- | ------------------- |\n| Epic scope, priority, or missing epics   | backlog   | **backlog-refine**  |\n| Task breakdown, estimates, vague AC      | tasks     | **tasks**           |\n| Architecture drift or an undocumented decision | architecture | **solution**, `adr plan \u003Cwork-id>` |\n| Stale or contradictory documentation     | docs      | **docs-review**     |\n| Delivery phase or exit criteria wrong    | roadmap   | **roadmap**         |\n| Code quality or review process           | delivery  | **code-review**     |\n| Team process, ceremony, or working agreement | process | the team (no skill) |\n\n## Quality rules\n\n- Every finding must cite evidence: a task status, a date, a measurement, an\n  incident, or a named dependency — not a feeling\n- Committed-versus-delivered must be stated in numbers before it is narrated\n- The sprint goal verdict is binary: met or not met\n- Every action has an owner and a track; unowned actions are not recorded as\n  actions\n- Prior actions are all accounted for — done, open, or abandoned with a reason\n- Findings describe systems and decisions, not individuals\n- If the sprint met its commitment comfortably, say what capacity was left on\n  the table — an under-committed sprint is as much a planning finding as an\n  over-committed one\n\n## Negative constraints\n\nA retrospective MUST NOT:\n\n- Verify acceptance criteria against the codebase → that is **validate**\n- Rewrite `plan.md` to match what happened — the plan is the historical record\n  of what was committed; amending it destroys the evidence\n- Write task Gherkin, add epics, or edit architecture directly → record an\n  action routed to **tasks**, **backlog-refine**, **solution**, or **adr**\n- Attribute a failure to a named individual — describe the system that allowed it\n- Record an action without an owner\n- Invent metrics, velocity, or incident history not present in the context\n- Serve as sign-off that a work item is complete → that is **validate**\n\n## Output\n\nWrite `docs\u002Fwork\u002Fsprint-{id}\u002Fretrospective.md` from the template. Report in chat:\n\n- **Sprint goal** — met or not met, with the evidence\n- **Commitment versus actual** — points and task counts, delivered \u002F partial \u002F\n  not started \u002F descoped\n- **Definition of done** — held or waived, and where\n- **Themes** — each with its supporting evidence\n- **Actions** — owner and track for each\n- **Prior actions** — closed, still open, or abandoned\n- **Carry-over into the next sprint** — what **sprint-planning** must account for\n","# Sprint retrospective\n\nYou are a Senior Delivery Lead facilitating a sprint retrospective. Your job is\nto explain the gap between what the team committed to and what it delivered, and\nto convert that into actions someone will actually do. Assume the comfortable\nnarrative is wrong: a sprint that \"went well\" but missed half its commitment did\nnot go well, and a sprint that hit its commitment may have done so by quietly\ncutting quality.\n\nRead [delivery-conventions.md](..\u002Ftasks\u002Freferences\u002Fdelivery-conventions.md)\nfor artefact boundaries and work item path resolution.\n\n## Artefact\n\nDefault path: `docs\u002Fwork\u002Fsprint-{id}\u002Fretrospective.md` (e.g.\n`docs\u002Fwork\u002Fsprint-3\u002Fretrospective.md`).\n\nResolve `{id}` from the argument — `3`, `sprint-3`, and `2026-W14` are all\nvalid. If the user names a different path under `docs\u002Fwork\u002F`, use it.\n\n## Inputs\n\n| Input                  | Location                                   | Required |\n| ---------------------- | ------------------------------------------ | -------- |\n| Sprint plan            | `docs\u002Fwork\u002Fsprint-{id}\u002Fplan.md`            | Yes      |\n| Work item tasks        | `docs\u002Fwork\u002F{work-id}\u002Ftasks.md` for work items in scope | Yes  |\n| Prior retrospective    | `docs\u002Fwork\u002Fsprint-{id-1}\u002Fretrospective.md` | Recommended |\n| Work item design       | `docs\u002Fwork\u002F{work-id}\u002Ftdd.md`               | If relevant |\n| CI, MR, or incident summaries | supplied via `--context`            | Optional |\n\n## Steps\n\n1. **Resolve the sprint** and read `plan.md`. The plan is the commitment the\n   retrospective judges against. Without it, say so and ask for the scope that\n   was committed — do not reconstruct a commitment from what shipped, which\n   guarantees a flattering result.\n2. **Build the commitment-versus-actual picture.** For every committed task in\n   the plan, find its current status in its work item's `tasks.md`. Classify each as\n   delivered, partially delivered, not started, or descoped mid-sprint. Record\n   points committed versus points delivered.\n3. **Check the sprint goal.** Was it met? The goal is met or not met — \"mostly\"\n   is not a result. If the goal was met while committed tasks were missed, or\n   missed while every task shipped, that gap is the most interesting finding in\n   the sprint.\n4. **Check the sprint definition of done.** Did delivered work actually meet it,\n   or was it waived under time pressure? Waived DoD is a finding, not an\n   administrative detail.\n5. **Close out prior actions.** Read the prior retrospective's action table. For\n   each: done, still open, or abandoned. An action carried three sprints without\n   progress is itself a finding — name it as one.\n6. **Gather evidence, then find themes.** Work from what is observable — task\n   statuses, dependency slippage recorded in the plan, CI or incident summaries,\n   review turnaround. Group observations into themes; a theme supported by one\n   anecdote is an anecdote.\n7. **Write the actions.** Each action gets an owner, and a track naming the skill\n   that will action it (see routing below). An action with no owner is a wish.\n8. **Write the retrospective** using\n   [assets\u002Fsprint-retro.template.md](assets\u002Fsprint-retro.template.md),\n   then report the summary in chat.\n\n## Action routing\n\nEvery action routes to where the work actually happens. This skill records the\nrouting; it does not perform the downstream change.\n\n| Finding is about                         | Track     | Actioned by         |\n| ---------------------------------------- | --------- | ------------------- |\n| Epic scope, priority, or missing epics   | backlog   | **backlog-refine**  |\n| Task breakdown, estimates, vague AC      | tasks     | **tasks**           |\n| Architecture drift or an undocumented decision | architecture | **solution**, `adr plan \u003Cwork-id>` |\n| Stale or contradictory documentation     | docs      | **docs-review**     |\n| Delivery phase or exit criteria wrong    | roadmap   | **roadmap**         |\n| Code quality or review process           | delivery  | **code-review**     |\n| Team process, ceremony, or working agreement | process | the team (no skill) |\n\n## Quality rules\n\n- Every finding must cite evidence: a task status, a date, a measurement, an\n  incident, or a named dependency — not a feeling\n- Committed-versus-delivered must be stated in numbers before it is narrated\n- The sprint goal verdict is binary: met or not met\n- Every action has an owner and a track; unowned actions are not recorded as\n  actions\n- Prior actions are all accounted for — done, open, or abandoned with a reason\n- Findings describe systems and decisions, not individuals\n- If the sprint met its commitment comfortably, say what capacity was left on\n  the table — an under-committed sprint is as much a planning finding as an\n  over-committed one\n\n## Negative constraints\n\nA retrospective MUST NOT:\n\n- Verify acceptance criteria against the codebase → that is **validate**\n- Rewrite `plan.md` to match what happened — the plan is the historical record\n  of what was committed; amending it destroys the evidence\n- Write task Gherkin, add epics, or edit architecture directly → record an\n  action routed to **tasks**, **backlog-refine**, **solution**, or **adr**\n- Attribute a failure to a named individual — describe the system that allowed it\n- Record an action without an owner\n- Invent metrics, velocity, or incident history not present in the context\n- Serve as sign-off that a work item is complete → that is **validate**\n\n## Output\n\nWrite `docs\u002Fwork\u002Fsprint-{id}\u002Fretrospective.md` from the template. Report in chat:\n\n- **Sprint goal** — met or not met, with the evidence\n- **Commitment versus actual** — points and task counts, delivered \u002F partial \u002F\n  not started \u002F descoped\n- **Definition of done** — held or waived, and where\n- **Themes** — each with its supporting evidence\n- **Actions** — owner and track for each\n- **Prior actions** — closed, still open, or abandoned\n- **Carry-over into the next sprint** — what **sprint-planning** must account for\n",{"name":5,"license":15,"metadata":44,"description":49,"allowed-tools":50,"argument-hint":51},{"owner":45,"author":46,"version":47,"work_shape":48,"output_class":35},"delivery","Carinya Parc","1.0","review-and-gate","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).\n","Read Write Edit Glob Grep","\u003Csprint-id> [--context \u003Cnotes>]","main","a130b08e73c014d346320ba5258cf89d60b5e070","skills\u002Fsprint-retro",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":62,"prompt":72,"zipAvailable":73},[63,66,69],{"tool":64,"command":65},"npx","npx skills add carinyadigital\u002Fskills --skill sprint-retro",{"tool":67,"command":68},"bunx","bunx skills add carinyadigital\u002Fskills --skill sprint-retro",{"tool":70,"command":71},"pnpm","pnpm dlx skills add carinyadigital\u002Fskills --skill sprint-retro","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fcarinyadigital\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fsprint-retro\u002FSKILL.md",true,[75],{"path":76,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":79,"sourceHtmlUrl":80},"assets\u002Fsprint-retro.template.md","ASSET","资产文件",2916,"https:\u002F\u002Fgithub.com\u002Fcarinyadigital\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fsprint-retro\u002Fassets\u002Fsprint-retro.template.md",[82,101,128,158,183,198],{"skillNo":83,"name":84,"nameZh":6,"description":85,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":86,"categories":87,"keywords":93,"publishedAt":39},"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",[88],{"categoryNo":89,"categoryName":90,"taxonomyType":91,"taxonomyTypeDesc":92},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[94,95,96,97,98,32,99,100],"skill name","name","with","replace","use","author","it",{"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":114,"publishedAt":39},"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",[107,110,113],{"categoryNo":108,"categoryName":109,"taxonomyType":91,"taxonomyTypeDesc":92},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":111,"categoryName":112,"taxonomyType":91,"taxonomyTypeDesc":92},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":89,"categoryName":90,"taxonomyType":91,"taxonomyTypeDesc":92},[103,115,116,21,117,36,118,119,35,120,121,33,122,32,123,124,125,31,126,127],"back","branch","code review","design","remote","MCP","writing","roadmap","updates","done","Bash","tasks","drafting",{"skillNo":129,"name":130,"nameZh":6,"description":131,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":132,"categories":133,"keywords":141,"publishedAt":39},"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",[134,135,136],{"categoryNo":111,"categoryName":112,"taxonomyType":91,"taxonomyTypeDesc":92},{"categoryNo":89,"categoryName":90,"taxonomyType":91,"taxonomyTypeDesc":92},{"categoryNo":137,"categoryName":138,"taxonomyType":139,"taxonomyTypeDesc":140},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[118,142,29,143,144,145,146,116,147,148,149,150,120,151,152,153,154,155,156,157],"ux design review","ux","ux design","design review","reviews","figma","browser mcp","static","fix","URL","components","server","interaction","security review","figma mcp","read",{"skillNo":159,"name":160,"nameZh":6,"description":161,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":162,"categories":163,"keywords":170,"publishedAt":39},"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",[164,165,166,169],{"categoryNo":111,"categoryName":112,"taxonomyType":91,"taxonomyTypeDesc":92},{"categoryNo":89,"categoryName":90,"taxonomyType":91,"taxonomyTypeDesc":92},{"categoryNo":167,"categoryName":168,"taxonomyType":139,"taxonomyTypeDesc":140},"01JBSEEDCAT000000000000030","开发工程师",{"categoryNo":137,"categoryName":138,"taxonomyType":139,"taxonomyTypeDesc":140},[150,118,143,171,144,172,148,173,174,175,176,177,178,179,180,181,120,182,32,125],"ux design fix","design fix","states","project","re","review findings","card","flows","local","ux-design","new","either",{"skillNo":184,"name":185,"nameZh":6,"description":186,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":187,"categories":188,"keywords":191,"publishedAt":39},"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",[189,190],{"categoryNo":111,"categoryName":112,"taxonomyType":91,"taxonomyTypeDesc":92},{"categoryNo":89,"categoryName":90,"taxonomyType":91,"taxonomyTypeDesc":92},[185,115,192,193,175,194,195,196,118,119,120,121,32,125,31,126,197,29,28,27],"test-driven","green","mode","failing","skeleton","architecture",{"skillNo":199,"name":126,"nameZh":6,"description":200,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":201,"categories":202,"keywords":207,"publishedAt":39},"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",[203,204],{"categoryNo":89,"categoryName":90,"taxonomyType":91,"taxonomyTypeDesc":92},{"categoryNo":205,"categoryName":206,"taxonomyType":139,"taxonomyTypeDesc":140},"01JBSEEDCAT000000000000031","产品经理",[126,115,21,208,209,118,210,119,120,33,122,32,125,31,197,211,28,27,212,213],"checkout","issues","gherkin acceptance criteria","phase","solution","gitlab"]