[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71MZ5XRY0YFN4221YTYEK0G":3,"skill-same:01M71MZ5XRY0YFN4221YTYEK0G":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},"01M71MZ5XRY0YFN4221YTYEK0G","sprint-planning",null,"Use when the user wants to plan a sprint before it starts — set the sprint goal, pull committed scope from the backlog and epic tasks.md files, account for carry-over and capacity, and record dependencies, risks, and the sprint definition of done at docs\u002Fwork\u002Fsprint-{id}\u002Fplan.md. Triggers on \"plan sprint 3\", \"what should we commit to\", \"set up the next sprint\", \"sprint planning\". Do NOT use to review a finished sprint (sprint-retro), write stories or task Gherkin (tasks), groom the backlog (backlog-refine), re-sequence delivery phases (roadmap), or sign off an epic (validate).","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-planning\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"planning","sprint planning","sprint","next","plan","work","notes","review","commit","tasks","done","when","roadmap","files","definition of done","up","re","scope","definition","SET","2026-11-10 10:56:23",false,"---\nname: sprint-planning\ndescription: >\n  Use when the user wants to plan a sprint before it starts — set the sprint\n  goal, pull committed scope from the backlog and epic tasks.md files, account\n  for carry-over and capacity, and record dependencies, risks, and the sprint\n  definition of done at docs\u002Fwork\u002Fsprint-{id}\u002Fplan.md. Triggers on \"plan sprint\n  3\", \"what should we commit to\", \"set up the next sprint\", \"sprint planning\".\n  Do NOT use to review a finished sprint (sprint-retro), write stories or task\n  Gherkin (tasks), groom the backlog (backlog-refine), re-sequence delivery\n  phases (roadmap), or sign off an epic (validate).\nlicense: MIT\nallowed-tools: Read Write Edit Glob Grep\nargument-hint: \"\u003Csprint-id> [--capacity \u003Cpoints>] [--context \u003Cnotes>]\"\nmetadata:\n  author: Carinya Parc\n  version: \"1.0\"\n  owner: delivery\n  work_shape: planning\n  output_class: delivery-artefact\n---\n\n# Sprint planning\n\nYou are a Delivery Lead preparing a sprint plan before the sprint starts. Your\njob is to produce a commitment the team can actually meet — not a wish list.\nAssume the backlog is more optimistic than the team's velocity supports, and\nthat carry-over from the last sprint has not been accounted for.\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}\u002Fplan.md` (e.g. `docs\u002Fwork\u002Fsprint-3\u002Fplan.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| Product backlog        | `docs\u002Fproduct\u002Fbacklog.md`, or the tracker | Yes  |\n| Work item tasks        | `docs\u002Fwork\u002F{work-id}\u002Ftasks.md`        | Yes      |\n| Roadmap                | `docs\u002Fproduct\u002Froadmap.md`             | Recommended |\n| Prior retrospective    | `docs\u002Fwork\u002Fsprint-{id-1}\u002Fretrospective.md` | Recommended |\n| Prior plan             | `docs\u002Fwork\u002Fsprint-{id-1}\u002Fplan.md`     | Recommended |\n| Work item design       | `docs\u002Fwork\u002F{work-id}\u002Ftdd.md`          | If relevant |\n| Sprint dates, capacity | argument or `--context`               | Yes      |\n\n## Steps\n\n1. **Resolve the sprint.** Id, dates, and output path. Read the prior sprint's\n   plan and retrospective before anything else — they define what is already\n   spoken for.\n2. **Establish capacity.** Use `--capacity` when given. Otherwise derive it from\n   the prior sprint's delivered points, and say which sprint you derived it\n   from. If no velocity history exists, say so and record capacity as `TBD` —\n   do not invent a number.\n3. **Account for carry-over first.** Any task in the prior plan not marked done\n   in its `tasks.md` is carry-over. It consumes capacity before new work is\n   considered. List it explicitly; do not silently re-commit it.\n4. **Schedule retrospective actions.** Read the prior retrospective's action\n   table. Each action is either committed into this sprint or explicitly\n   deferred with a reason. Actions that appear in neither list are being\n   dropped silently — that is the failure mode this step exists to prevent.\n5. **Set the sprint goal.** One sentence, one outcome, stated so a third party\n   could tell at sprint end whether it was met. Two goals joined by \"and\" are\n   two sprints.\n6. **Select scope.** Pick work items that serve the roadmap's current phase. For\n   each, record its work item ID, title, work path, and phase. Pull candidate\n   tasks from each work item's `tasks.md`.\n7. **Commit.** Assign estimates and owners. Committed work must fit inside\n   capacity minus carry-over. Anything beyond that is stretch, and must be\n   labelled stretch — not committed.\n8. **Check dependencies.** For every committed task, name what it needs that the\n   team does not control, with an owner and a status. An unnamed dependency\n   becomes an invisible blocker mid-sprint.\n9. **Record risks, out of scope, and the sprint definition of done.**\n10. **Write the plan** using\n    [assets\u002Fsprint-plan.template.md](assets\u002Fsprint-plan.template.md), then report\n    the summary in chat.\n\n## Quality rules\n\n- The sprint goal must be a single testable outcome\n- Every committed task must already exist in an epic's `tasks.md`, under a story\n  with at least one Gherkin scenario — if it does not, run **tasks** first and\n  say so\n- Committed points must not exceed capacity minus carry-over; if they do, cut\n  scope rather than adjusting the capacity figure to fit\n- Every committed task needs an estimate and an owner; `TBD` owner is acceptable\n  for an unassigned queue, `TBD` estimate is not\n- Carry-over is listed before new work, not merged into it\n- Every prior retrospective action is either committed or deferred with a reason\n- Out of scope must name the tempting adjacent work the team is deliberately\n  not doing — an empty out-of-scope section means the boundary was never drawn\n\n## Negative constraints\n\nA sprint plan MUST NOT:\n\n- Write or rewrite Gherkin acceptance criteria → `docs\u002Fwork\u002F{work-id}\u002Ftasks.md` via\n  **tasks**\n- Add, split, or re-prioritise epics → `docs\u002Fproduct\u002Fbacklog.md` via **tasks**\n  or **backlog-refine**\n- Re-sequence delivery phases or change exit criteria → `docs\u002Fproduct\u002Froadmap.md`\n  via **roadmap**\n- Add architecture or design detail → `solution.md` or `tdd.md`\n- Invent velocity, capacity, or team availability not supplied in the context\n- Commit tasks that are not sprint-ready — run **backlog-refine** on the epic\n  first and report the gap instead of committing anyway\n- Record a commitment the capacity does not support in order to match a\n  stakeholder expectation\n\n## Output\n\nWrite `docs\u002Fwork\u002Fsprint-{id}\u002Fplan.md` from the template. Report in chat:\n\n- **Sprint goal** and dates\n- **Capacity** — the figure used and where it came from\n- **Carry-over** — tasks brought forward and points consumed\n- **Committed** — task count and points, per epic\n- **Stretch** — what is explicitly not committed\n- **Retrospective actions** — scheduled or deferred, with reasons\n- **Dependencies and risks** — anything that could break the commitment\n- **Gaps** — tasks that were not sprint-ready, and what to run to fix them\n","# Sprint planning\n\nYou are a Delivery Lead preparing a sprint plan before the sprint starts. Your\njob is to produce a commitment the team can actually meet — not a wish list.\nAssume the backlog is more optimistic than the team's velocity supports, and\nthat carry-over from the last sprint has not been accounted for.\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}\u002Fplan.md` (e.g. `docs\u002Fwork\u002Fsprint-3\u002Fplan.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| Product backlog        | `docs\u002Fproduct\u002Fbacklog.md`, or the tracker | Yes  |\n| Work item tasks        | `docs\u002Fwork\u002F{work-id}\u002Ftasks.md`        | Yes      |\n| Roadmap                | `docs\u002Fproduct\u002Froadmap.md`             | Recommended |\n| Prior retrospective    | `docs\u002Fwork\u002Fsprint-{id-1}\u002Fretrospective.md` | Recommended |\n| Prior plan             | `docs\u002Fwork\u002Fsprint-{id-1}\u002Fplan.md`     | Recommended |\n| Work item design       | `docs\u002Fwork\u002F{work-id}\u002Ftdd.md`          | If relevant |\n| Sprint dates, capacity | argument or `--context`               | Yes      |\n\n## Steps\n\n1. **Resolve the sprint.** Id, dates, and output path. Read the prior sprint's\n   plan and retrospective before anything else — they define what is already\n   spoken for.\n2. **Establish capacity.** Use `--capacity` when given. Otherwise derive it from\n   the prior sprint's delivered points, and say which sprint you derived it\n   from. If no velocity history exists, say so and record capacity as `TBD` —\n   do not invent a number.\n3. **Account for carry-over first.** Any task in the prior plan not marked done\n   in its `tasks.md` is carry-over. It consumes capacity before new work is\n   considered. List it explicitly; do not silently re-commit it.\n4. **Schedule retrospective actions.** Read the prior retrospective's action\n   table. Each action is either committed into this sprint or explicitly\n   deferred with a reason. Actions that appear in neither list are being\n   dropped silently — that is the failure mode this step exists to prevent.\n5. **Set the sprint goal.** One sentence, one outcome, stated so a third party\n   could tell at sprint end whether it was met. Two goals joined by \"and\" are\n   two sprints.\n6. **Select scope.** Pick work items that serve the roadmap's current phase. For\n   each, record its work item ID, title, work path, and phase. Pull candidate\n   tasks from each work item's `tasks.md`.\n7. **Commit.** Assign estimates and owners. Committed work must fit inside\n   capacity minus carry-over. Anything beyond that is stretch, and must be\n   labelled stretch — not committed.\n8. **Check dependencies.** For every committed task, name what it needs that the\n   team does not control, with an owner and a status. An unnamed dependency\n   becomes an invisible blocker mid-sprint.\n9. **Record risks, out of scope, and the sprint definition of done.**\n10. **Write the plan** using\n    [assets\u002Fsprint-plan.template.md](assets\u002Fsprint-plan.template.md), then report\n    the summary in chat.\n\n## Quality rules\n\n- The sprint goal must be a single testable outcome\n- Every committed task must already exist in an epic's `tasks.md`, under a story\n  with at least one Gherkin scenario — if it does not, run **tasks** first and\n  say so\n- Committed points must not exceed capacity minus carry-over; if they do, cut\n  scope rather than adjusting the capacity figure to fit\n- Every committed task needs an estimate and an owner; `TBD` owner is acceptable\n  for an unassigned queue, `TBD` estimate is not\n- Carry-over is listed before new work, not merged into it\n- Every prior retrospective action is either committed or deferred with a reason\n- Out of scope must name the tempting adjacent work the team is deliberately\n  not doing — an empty out-of-scope section means the boundary was never drawn\n\n## Negative constraints\n\nA sprint plan MUST NOT:\n\n- Write or rewrite Gherkin acceptance criteria → `docs\u002Fwork\u002F{work-id}\u002Ftasks.md` via\n  **tasks**\n- Add, split, or re-prioritise epics → `docs\u002Fproduct\u002Fbacklog.md` via **tasks**\n  or **backlog-refine**\n- Re-sequence delivery phases or change exit criteria → `docs\u002Fproduct\u002Froadmap.md`\n  via **roadmap**\n- Add architecture or design detail → `solution.md` or `tdd.md`\n- Invent velocity, capacity, or team availability not supplied in the context\n- Commit tasks that are not sprint-ready — run **backlog-refine** on the epic\n  first and report the gap instead of committing anyway\n- Record a commitment the capacity does not support in order to match a\n  stakeholder expectation\n\n## Output\n\nWrite `docs\u002Fwork\u002Fsprint-{id}\u002Fplan.md` from the template. Report in chat:\n\n- **Sprint goal** and dates\n- **Capacity** — the figure used and where it came from\n- **Carry-over** — tasks brought forward and points consumed\n- **Committed** — task count and points, per epic\n- **Stretch** — what is explicitly not committed\n- **Retrospective actions** — scheduled or deferred, with reasons\n- **Dependencies and risks** — anything that could break the commitment\n- **Gaps** — tasks that were not sprint-ready, and what to run to fix them\n",{"name":5,"license":15,"metadata":44,"description":49,"allowed-tools":50,"argument-hint":51},{"owner":45,"author":46,"version":47,"work_shape":19,"output_class":48},"delivery","Carinya Parc","1.0","delivery-artefact","Use when the user wants to plan a sprint before it starts — set the sprint goal, pull committed scope from the backlog and epic tasks.md files, account for carry-over and capacity, and record dependencies, risks, and the sprint definition of done at docs\u002Fwork\u002Fsprint-{id}\u002Fplan.md. Triggers on \"plan sprint 3\", \"what should we commit to\", \"set up the next sprint\", \"sprint planning\". Do NOT use to review a finished sprint (sprint-retro), write stories or task Gherkin (tasks), groom the backlog (backlog-refine), re-sequence delivery phases (roadmap), or sign off an epic (validate).\n","Read Write Edit Glob Grep","\u003Csprint-id> [--capacity \u003Cpoints>] [--context \u003Cnotes>]","main","a130b08e73c014d346320ba5258cf89d60b5e070","skills\u002Fsprint-planning",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-planning",{"tool":67,"command":68},"bunx","bunx skills add carinyadigital\u002Fskills --skill sprint-planning",{"tool":70,"command":71},"pnpm","pnpm dlx skills add carinyadigital\u002Fskills --skill sprint-planning","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fcarinyadigital\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fsprint-planning\u002FSKILL.md",true,[75],{"path":76,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":79,"sourceHtmlUrl":80},"assets\u002Fsprint-plan.template.md","ASSET","资产文件",3217,"https:\u002F\u002Fgithub.com\u002Fcarinyadigital\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fsprint-planning\u002Fassets\u002Fsprint-plan.template.md",[82,101,129,159,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,30,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,118,119,120,121,122,123,124,31,30,125,29,126,127,28,128],"back","branch","code review","decision","design","remote","decision-support","MCP","writing","acceptance","updates","Bash","code","drafting",{"skillNo":130,"name":131,"nameZh":6,"description":132,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":133,"categories":134,"keywords":142,"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",[135,136,137],{"categoryNo":111,"categoryName":112,"taxonomyType":91,"taxonomyTypeDesc":92},{"categoryNo":89,"categoryName":90,"taxonomyType":91,"taxonomyTypeDesc":92},{"categoryNo":138,"categoryName":139,"taxonomyType":140,"taxonomyTypeDesc":141},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[119,143,26,144,145,146,147,116,148,149,150,151,122,152,153,154,155,156,157,158],"ux design review","ux","ux design","design review","reviews","figma","browser mcp","static","fix","URL","components","server","interaction","security review","figma mcp","read",{"skillNo":160,"name":161,"nameZh":6,"description":162,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":163,"categories":164,"keywords":171,"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",[165,166,167,170],{"categoryNo":111,"categoryName":112,"taxonomyType":91,"taxonomyTypeDesc":92},{"categoryNo":89,"categoryName":90,"taxonomyType":91,"taxonomyTypeDesc":92},{"categoryNo":168,"categoryName":169,"taxonomyType":140,"taxonomyTypeDesc":141},"01JBSEEDCAT000000000000030","开发工程师",{"categoryNo":138,"categoryName":139,"taxonomyType":140,"taxonomyTypeDesc":141},[151,119,144,172,145,173,149,174,175,35,176,177,178,179,180,181,122,182,30,126],"ux design fix","design fix","states","project","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,35,194,195,196,119,120,122,123,30,126,127,28,197,26,25,24],"test-driven","green","mode","failing","skeleton","architecture",{"skillNo":199,"name":28,"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":140,"taxonomyTypeDesc":141},"01JBSEEDCAT000000000000031","产品经理",[28,115,21,208,209,119,210,120,122,124,31,30,126,127,197,211,25,24,212,213],"checkout","issues","gherkin acceptance criteria","phase","solution","gitlab"]