[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71MZCPYDVZQCS12F54SJHHS":3,"skill-same:01M71MZCPYDVZQCS12F54SJHHS":140},{"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":28,"publishedAt":48,"linkOnly":49,"markdownContent":50,"markdownBody":51,"frontMatter":52,"refName":63,"commitSha":64,"skillDirectory":65,"forksCount":66,"repositoryHtmlUrl":67,"repositoryHomepageUrl":6,"ownerHtmlUrl":68,"ownerBlogUrl":69,"ownerDescription":70,"updatedAt":71,"install":72,"resources":85},"01M71MZCPYDVZQCS12F54SJHHS","tasks",null,"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).","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\u002Ftasks\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000031","产品经理","PROFESSION","适用职业",[5,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47],"roadmap","gitlab","solution","work","notes","phase","architecture","code","Bash","when","acceptance","MCP","remote","gherkin acceptance criteria","design","issues","checkout","sprint","back","2026-11-10 10:56:23",false,"---\nname: tasks\ndescription: >\n  Use to decompose anything into delivery work — a product strategy and roadmap\n  into epics, an epic into stories and tasks with Gherkin acceptance criteria,\n  a story into sub-tasks, or an external spec, RFC, or PRD into both in one\n  pass. Resolves the work item's source system (Linear, Jira, GitHub\u002FGitLab\n  issues, or filesystem) and its type first. Writes docs\u002Fproduct\u002Fbacklog.md\n  and docs\u002Fwork\u002F{work-id}\u002Ftasks.md, or the tracker directly when one is\n  resolved. Triggers on \"break this spec into a\n  backlog\", \"write the epics\", \"decompose checkout-foundation\", \"turn this\n  RFC into tickets\", \"write tasks for CHK01\", \"write sub-tasks for JIRA-123\",\n  \"what stories do we need\". EARS with --ears. Do NOT use to groom an existing\n  backlog or check sprint readiness (backlog-refine), write technical design at\n  any level (tdd), write architecture (solution), phase the delivery (roadmap),\n  implement code (implement), or sign off a work item (validate).\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(gh:*) Bash(glab:*)\nargument-hint: \"\u003Cwork-id|spec-path|--product> [--ears] [--depth full] [--context \u003Cnotes>]\"\nmetadata:\n  author: Carinya Parc\n  version: \"3.0\"\n  owner: delivery\n  work_shape: decomposition\n  output_class: delivery-artefact\n---\n\n# Tasks\n\nYou are a Business Analyst decomposing work into a delivery backlog. One method\napplies at every level: find the vertical slices, order them by dependency, and\ngive each one acceptance criteria a third party could test. What changes between\nlevels is only the size of the slice, the resolved type, and the artefact it\nlands in.\n\nRead [references\u002Fwork-item-resolution.md](references\u002Fwork-item-resolution.md)\n**first**, on every argument — it resolves the source system (Linear, Jira,\nGitHub\u002FGitLab issues, or filesystem), the canonical ID, and the type before\nyou decide what to write. Read\n[references\u002Fdelivery-conventions.md](references\u002Fdelivery-conventions.md) for\npaths and artefact boundaries.\n\n## What you are decomposing\n\nResolve the work item first (per work-item-resolution.md) — its **type**\ndetermines which artefacts you write.\n\n| Resolved type | Source | Writes |\n| ---- | ------ | ------ |\n| `--product` or no argument | `product.md`, `roadmap.md`, `solution.md` | `docs\u002Fproduct\u002Fbacklog.md` (epics) — filesystem-only; tracker-backed repos create epics\u002Finitiatives in the tracker instead |\n| `epic` | Backlog row or tracker epic + `docs\u002Fwork\u002F{work-id}\u002Ftdd.md` (or a legacy `design.md`) | `docs\u002Fwork\u002F{work-id}\u002Ftasks.md` (stories + tasks) |\n| `story` | Its parent epic's context + the story itself | Sub-tasks — as tracker sub-issues when a tracker resolved, else `docs\u002Fwork\u002F{story-id}\u002Ftasks.md` in its own folder (alongside, not nested inside, its parent epic's) |\n| `task`, `bug`, `spike` | The item itself | Nothing to decompose by default — see below |\n| Path to a spec, RFC, PRD, or design doc | that file | **both** — epic row (or tracker epic) *and* its `tasks.md` |\n| Pasted or described spec | `--context` | **both** |\n\n**`task`, `bug`, `spike` arguments.** These are leaf types (see\n[work-item-schema.md §Type](references\u002Fwork-item-schema.md#type)). Do not\ndecompose them by default — confirm intent first: \"CHK01-04 is a task, not a\nstory or epic — did you mean to break it into sub-tasks anyway, or run\n`implement CHK01-04`?\" A bug that genuinely spans more than one integration\nboundary is a legitimate exception; ask rather than assume either way.\n\nWhen a spec has no matching epic: **filesystem-only** — derive the slug\n(kebab-case, at most two words), assign the next internal ID in sequence, add\nthe epic row to `backlog.md`, then write its `tasks.md`. Never invent an ID\nthat collides with an existing one — read the backlog first. **Tracker\nresolved** — ask whether to create the epic in the tracker (if write access\nexists) or ask the user for the ID once they create it; never assign an\ninternal ID to tracker-backed work.\n\nIf the user names a different output path, use it.\n\n## References\n\n- [references\u002Fwork-item-resolution.md](references\u002Fwork-item-resolution.md) —\n  source system detection, the `TASKS.local.md` pointer, canonical ID rules,\n  and the ask-first checklist. Read this before resolving any argument.\n- [references\u002Fwork-item-schema.md](references\u002Fwork-item-schema.md) — epic,\n  story, task, bug, and spike definitions with the legal value of every field\n- [references\u002Facceptance-criteria.md](references\u002Facceptance-criteria.md) —\n  Gherkin rules, the five EARS patterns, and when each is the right tool\n- [references\u002Fdelivery-conventions.md](references\u002Fdelivery-conventions.md) —\n  paths and artefact boundaries\n\n## Decomposition method\n\nThe same six rules apply whether you are cutting a product into epics, an\nepic into stories, or a story into sub-tasks.\n\n1. **Vertical slices, never horizontal layers.** Every slice delivers\n   observable behaviour end to end. \"Build all the API endpoints\" is a layer,\n   not a slice — it cannot be demonstrated and it cannot be independently\n   released. Split by user outcome, then let each slice reach through whatever\n   layers it needs.\n2. **Independently testable.** State, for each slice, what a reviewer can\n   demonstrate to confirm it is done. If you cannot write that sentence, the\n   slice is wrong.\n3. **Size.** 4–8 epics per product phase; 3–7 stories per epic; 2–5 tasks per\n   story; a task should be roughly a day. Outside those bounds, say so and\n   propose a split rather than silently producing 40 tasks.\n4. **Split when** a slice crosses two integration boundaries, needs two\n   specialties, or cannot be demonstrated on its own.\n5. **Order** foundational work → slices by priority → cross-cutting work.\n   Within a phase, dependency order. Mark `[P]` on any task that touches\n   different files from its siblings and depends on nothing incomplete.\n6. **Name the MVP.** The first story is the thinnest thing that proves the epic\n   works. Say so explicitly.\n\n## Document shape\n\n**Epics** (`backlog.md`, filesystem-only) — epic table, Now-phase detail,\ndependency graph, delivery risks. Later phases stay as placeholders unless\n`--depth full`. Use [assets\u002Fbacklog.template.md](assets\u002Fbacklog.template.md).\nTracker-backed repos skip this artefact — the tracker holds the epic list.\n\n**Stories and tasks** (`tasks.md`) — use\n[assets\u002Ftasks.template.md](assets\u002Ftasks.template.md):\n\n```\n1. Summary            work item, phase, source, scope, out of scope\n2. Conventions        ID scheme, AC policy, estimate unit\n3. Foundational       blocking prerequisites — no story label\n4. Stories            one subsection per story, priority order:\n                        story statement → independent test criterion\n                        → Gherkin AC → its tasks\n5. Cross-cutting      polish, docs, observability\n6. Dependencies       graph and parallel opportunities\n7. Traceability + DoD story → tdd.md §, story → solution.md §\n8. Handoff\n```\n\n**Sub-tasks under a story** — written to the story's own `docs\u002Fwork\u002F{story-id}\u002Ftasks.md`,\nsame shape as tasks under an epic, one level down: each sub-task names a\ndeliverable and a file path, inherits the story's Gherkin, and is numbered\n`{STORY-ID}-{nn}`, sequential within that file (see\n[work-item-schema.md](references\u002Fwork-item-schema.md#task)). Tracker-backed\nrepos create these as sub-issues instead of markdown lines; still report what\nwas created.\n\nTask lines carry their story and parallel markers, so a reader can see the\nstructure without scrolling:\n\n```\n- [ ] **[CHK01-04]** [P] [S2] Build checkout page shell — app\u002F(checkout)\u002Fcheckout\u002Fpage.tsx\n```\n\n## Acceptance criteria\n\n**Gherkin is the default and lives on the story**, because that is where\nuser-observable behaviour lives. A foundational task with no parent story\ncarries its own Gherkin. A `bug` carries its own reproduction-as-Given\u002FWhen,\nfix-as-Then.\n\n- At least one scenario per story; two when the happy path and an edge both\n  matter\n- `Then` clauses must be observable — \"the response is 201\", not \"it works\"\n- One behaviour per scenario\n\n**EARS** where a rule is clearer than a scenario — invariants, constraints,\nNFRs, always\u002Fnever rules. `--ears` applies it to every story. See\n[references\u002Facceptance-criteria.md](references\u002Facceptance-criteria.md) for the\nfive patterns and worked examples. Omit the section entirely when unused.\n\n## Confirm before writing large decompositions\n\nIf the breakdown exceeds 7 stories or 20 tasks, present the outline in chat —\nstory titles, task counts, dependency order — and get confirmation before\nwriting. Below that, write directly; the file diff is reviewable.\n\n## Pre-save validation\n\n- [ ] Source system and type resolved per work-item-resolution.md — asked the\n  user on any ambiguity, never guessed\n- [ ] Canonical ID used as-is when a tracker resolved; no parallel internal ID\n  invented for tracker-backed work\n- [ ] Filesystem-only: epic slug resolved from the backlog row, not the\n  internal ID (`CHK01` is not a slug)\n- [ ] Every story has a statement, an independent test criterion, and ≥1 Gherkin scenario\n- [ ] Every `Then` clause is observable\n- [ ] Every task names a deliverable and at least one concrete file path\n- [ ] Task IDs use the parent work item's ID as prefix and are unique; `Depends on` cites real IDs\n- [ ] No dependency cycles\n- [ ] `[P]` markers only on tasks with no incomplete dependency\n- [ ] Story 1 is identified as the MVP\n- [ ] No architecture narrative copied from `solution.md` or `tdd.md` — cite sections\n\n## Negative constraints\n\nThis skill decomposes. It MUST NOT:\n\n- Guess the source system, ID, or type when ambiguous — ask, per\n  work-item-resolution.md's ask-first checklist\n- Groom an existing backlog or judge sprint readiness → **backlog-refine**\n- Write design narrative at any level → `docs\u002Fwork\u002F{work-id}\u002Ftdd.md` via **tdd**\n- Write architecture, NFRs, or cross-epic patterns → `solution.md` via **solution**\n- Re-sequence delivery phases or change exit criteria → `roadmap.md` via **roadmap**\n- Change business strategy, personas, or outcomes → `product.md` via **product**\n- Write code → **implement**\n- Paste full Gherkin into `backlog.md` — epic scope only; AC lives in `tasks.md`\n- Re-narrate design or architecture — cite `tdd.md §` and `solution.md §`\n- Invent requirements the source does not support; mark gaps\n  `[NEEDS CLARIFICATION]` and list them in the report\n\n## Output\n\nWrite the artefacts, then report:\n\n- **Resolved** — source system, canonical ID, and type\n- **Wrote** — every path touched (or tracker items created), and what landed in each\n- **Structure** — epic count, or story and task counts with the MVP named\n- **Dependency order** — what blocks what; which tasks are parallel\n- **Gaps** — anything marked `[NEEDS CLARIFICATION]` and what would resolve it\n- **Next** — **tdd** if the work item has no technical design yet, **implement**\n  per task once the TDD and tasks are approved, **backlog-refine** before\n  committing to a sprint\n\n## Supporting files\n\n- [assets\u002Ftasks.template.md](assets\u002Ftasks.template.md) ·\n  [assets\u002Fbacklog.template.md](assets\u002Fbacklog.template.md) ·\n  [assets\u002Ftasks-local.template.md](assets\u002Ftasks-local.template.md)\n- [examples\u002Fcheckout-foundation.md](examples\u002Fcheckout-foundation.md) ·\n  [examples\u002Fbacklog.md](examples\u002Fbacklog.md)\n- [scripts\u002Fcheck-epic-paths.sh](scripts\u002Fcheck-epic-paths.sh) — optional path check for the filesystem-only fallback\n","# Tasks\n\nYou are a Business Analyst decomposing work into a delivery backlog. One method\napplies at every level: find the vertical slices, order them by dependency, and\ngive each one acceptance criteria a third party could test. What changes between\nlevels is only the size of the slice, the resolved type, and the artefact it\nlands in.\n\nRead [references\u002Fwork-item-resolution.md](references\u002Fwork-item-resolution.md)\n**first**, on every argument — it resolves the source system (Linear, Jira,\nGitHub\u002FGitLab issues, or filesystem), the canonical ID, and the type before\nyou decide what to write. Read\n[references\u002Fdelivery-conventions.md](references\u002Fdelivery-conventions.md) for\npaths and artefact boundaries.\n\n## What you are decomposing\n\nResolve the work item first (per work-item-resolution.md) — its **type**\ndetermines which artefacts you write.\n\n| Resolved type | Source | Writes |\n| ---- | ------ | ------ |\n| `--product` or no argument | `product.md`, `roadmap.md`, `solution.md` | `docs\u002Fproduct\u002Fbacklog.md` (epics) — filesystem-only; tracker-backed repos create epics\u002Finitiatives in the tracker instead |\n| `epic` | Backlog row or tracker epic + `docs\u002Fwork\u002F{work-id}\u002Ftdd.md` (or a legacy `design.md`) | `docs\u002Fwork\u002F{work-id}\u002Ftasks.md` (stories + tasks) |\n| `story` | Its parent epic's context + the story itself | Sub-tasks — as tracker sub-issues when a tracker resolved, else `docs\u002Fwork\u002F{story-id}\u002Ftasks.md` in its own folder (alongside, not nested inside, its parent epic's) |\n| `task`, `bug`, `spike` | The item itself | Nothing to decompose by default — see below |\n| Path to a spec, RFC, PRD, or design doc | that file | **both** — epic row (or tracker epic) *and* its `tasks.md` |\n| Pasted or described spec | `--context` | **both** |\n\n**`task`, `bug`, `spike` arguments.** These are leaf types (see\n[work-item-schema.md §Type](references\u002Fwork-item-schema.md#type)). Do not\ndecompose them by default — confirm intent first: \"CHK01-04 is a task, not a\nstory or epic — did you mean to break it into sub-tasks anyway, or run\n`implement CHK01-04`?\" A bug that genuinely spans more than one integration\nboundary is a legitimate exception; ask rather than assume either way.\n\nWhen a spec has no matching epic: **filesystem-only** — derive the slug\n(kebab-case, at most two words), assign the next internal ID in sequence, add\nthe epic row to `backlog.md`, then write its `tasks.md`. Never invent an ID\nthat collides with an existing one — read the backlog first. **Tracker\nresolved** — ask whether to create the epic in the tracker (if write access\nexists) or ask the user for the ID once they create it; never assign an\ninternal ID to tracker-backed work.\n\nIf the user names a different output path, use it.\n\n## References\n\n- [references\u002Fwork-item-resolution.md](references\u002Fwork-item-resolution.md) —\n  source system detection, the `TASKS.local.md` pointer, canonical ID rules,\n  and the ask-first checklist. Read this before resolving any argument.\n- [references\u002Fwork-item-schema.md](references\u002Fwork-item-schema.md) — epic,\n  story, task, bug, and spike definitions with the legal value of every field\n- [references\u002Facceptance-criteria.md](references\u002Facceptance-criteria.md) —\n  Gherkin rules, the five EARS patterns, and when each is the right tool\n- [references\u002Fdelivery-conventions.md](references\u002Fdelivery-conventions.md) —\n  paths and artefact boundaries\n\n## Decomposition method\n\nThe same six rules apply whether you are cutting a product into epics, an\nepic into stories, or a story into sub-tasks.\n\n1. **Vertical slices, never horizontal layers.** Every slice delivers\n   observable behaviour end to end. \"Build all the API endpoints\" is a layer,\n   not a slice — it cannot be demonstrated and it cannot be independently\n   released. Split by user outcome, then let each slice reach through whatever\n   layers it needs.\n2. **Independently testable.** State, for each slice, what a reviewer can\n   demonstrate to confirm it is done. If you cannot write that sentence, the\n   slice is wrong.\n3. **Size.** 4–8 epics per product phase; 3–7 stories per epic; 2–5 tasks per\n   story; a task should be roughly a day. Outside those bounds, say so and\n   propose a split rather than silently producing 40 tasks.\n4. **Split when** a slice crosses two integration boundaries, needs two\n   specialties, or cannot be demonstrated on its own.\n5. **Order** foundational work → slices by priority → cross-cutting work.\n   Within a phase, dependency order. Mark `[P]` on any task that touches\n   different files from its siblings and depends on nothing incomplete.\n6. **Name the MVP.** The first story is the thinnest thing that proves the epic\n   works. Say so explicitly.\n\n## Document shape\n\n**Epics** (`backlog.md`, filesystem-only) — epic table, Now-phase detail,\ndependency graph, delivery risks. Later phases stay as placeholders unless\n`--depth full`. Use [assets\u002Fbacklog.template.md](assets\u002Fbacklog.template.md).\nTracker-backed repos skip this artefact — the tracker holds the epic list.\n\n**Stories and tasks** (`tasks.md`) — use\n[assets\u002Ftasks.template.md](assets\u002Ftasks.template.md):\n\n```\n1. Summary            work item, phase, source, scope, out of scope\n2. Conventions        ID scheme, AC policy, estimate unit\n3. Foundational       blocking prerequisites — no story label\n4. Stories            one subsection per story, priority order:\n                        story statement → independent test criterion\n                        → Gherkin AC → its tasks\n5. Cross-cutting      polish, docs, observability\n6. Dependencies       graph and parallel opportunities\n7. Traceability + DoD story → tdd.md §, story → solution.md §\n8. Handoff\n```\n\n**Sub-tasks under a story** — written to the story's own `docs\u002Fwork\u002F{story-id}\u002Ftasks.md`,\nsame shape as tasks under an epic, one level down: each sub-task names a\ndeliverable and a file path, inherits the story's Gherkin, and is numbered\n`{STORY-ID}-{nn}`, sequential within that file (see\n[work-item-schema.md](references\u002Fwork-item-schema.md#task)). Tracker-backed\nrepos create these as sub-issues instead of markdown lines; still report what\nwas created.\n\nTask lines carry their story and parallel markers, so a reader can see the\nstructure without scrolling:\n\n```\n- [ ] **[CHK01-04]** [P] [S2] Build checkout page shell — app\u002F(checkout)\u002Fcheckout\u002Fpage.tsx\n```\n\n## Acceptance criteria\n\n**Gherkin is the default and lives on the story**, because that is where\nuser-observable behaviour lives. A foundational task with no parent story\ncarries its own Gherkin. A `bug` carries its own reproduction-as-Given\u002FWhen,\nfix-as-Then.\n\n- At least one scenario per story; two when the happy path and an edge both\n  matter\n- `Then` clauses must be observable — \"the response is 201\", not \"it works\"\n- One behaviour per scenario\n\n**EARS** where a rule is clearer than a scenario — invariants, constraints,\nNFRs, always\u002Fnever rules. `--ears` applies it to every story. See\n[references\u002Facceptance-criteria.md](references\u002Facceptance-criteria.md) for the\nfive patterns and worked examples. Omit the section entirely when unused.\n\n## Confirm before writing large decompositions\n\nIf the breakdown exceeds 7 stories or 20 tasks, present the outline in chat —\nstory titles, task counts, dependency order — and get confirmation before\nwriting. Below that, write directly; the file diff is reviewable.\n\n## Pre-save validation\n\n- [ ] Source system and type resolved per work-item-resolution.md — asked the\n  user on any ambiguity, never guessed\n- [ ] Canonical ID used as-is when a tracker resolved; no parallel internal ID\n  invented for tracker-backed work\n- [ ] Filesystem-only: epic slug resolved from the backlog row, not the\n  internal ID (`CHK01` is not a slug)\n- [ ] Every story has a statement, an independent test criterion, and ≥1 Gherkin scenario\n- [ ] Every `Then` clause is observable\n- [ ] Every task names a deliverable and at least one concrete file path\n- [ ] Task IDs use the parent work item's ID as prefix and are unique; `Depends on` cites real IDs\n- [ ] No dependency cycles\n- [ ] `[P]` markers only on tasks with no incomplete dependency\n- [ ] Story 1 is identified as the MVP\n- [ ] No architecture narrative copied from `solution.md` or `tdd.md` — cite sections\n\n## Negative constraints\n\nThis skill decomposes. It MUST NOT:\n\n- Guess the source system, ID, or type when ambiguous — ask, per\n  work-item-resolution.md's ask-first checklist\n- Groom an existing backlog or judge sprint readiness → **backlog-refine**\n- Write design narrative at any level → `docs\u002Fwork\u002F{work-id}\u002Ftdd.md` via **tdd**\n- Write architecture, NFRs, or cross-epic patterns → `solution.md` via **solution**\n- Re-sequence delivery phases or change exit criteria → `roadmap.md` via **roadmap**\n- Change business strategy, personas, or outcomes → `product.md` via **product**\n- Write code → **implement**\n- Paste full Gherkin into `backlog.md` — epic scope only; AC lives in `tasks.md`\n- Re-narrate design or architecture — cite `tdd.md §` and `solution.md §`\n- Invent requirements the source does not support; mark gaps\n  `[NEEDS CLARIFICATION]` and list them in the report\n\n## Output\n\nWrite the artefacts, then report:\n\n- **Resolved** — source system, canonical ID, and type\n- **Wrote** — every path touched (or tracker items created), and what landed in each\n- **Structure** — epic count, or story and task counts with the MVP named\n- **Dependency order** — what blocks what; which tasks are parallel\n- **Gaps** — anything marked `[NEEDS CLARIFICATION]` and what would resolve it\n- **Next** — **tdd** if the work item has no technical design yet, **implement**\n  per task once the TDD and tasks are approved, **backlog-refine** before\n  committing to a sprint\n\n## Supporting files\n\n- [assets\u002Ftasks.template.md](assets\u002Ftasks.template.md) ·\n  [assets\u002Fbacklog.template.md](assets\u002Fbacklog.template.md) ·\n  [assets\u002Ftasks-local.template.md](assets\u002Ftasks-local.template.md)\n- [examples\u002Fcheckout-foundation.md](examples\u002Fcheckout-foundation.md) ·\n  [examples\u002Fbacklog.md](examples\u002Fbacklog.md)\n- [scripts\u002Fcheck-epic-paths.sh](scripts\u002Fcheck-epic-paths.sh) — optional path check for the filesystem-only fallback\n",{"name":5,"license":15,"metadata":53,"description":59,"allowed-tools":60,"argument-hint":61,"compatibility":62},{"owner":54,"author":55,"version":56,"work_shape":57,"output_class":58},"delivery","Carinya Parc","3.0","decomposition","delivery-artefact","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).\n","Read Write Edit Glob Grep Bash(git remote:*) Bash(gh:*) Bash(glab:*)","\u003Cwork-id|spec-path|--product> [--ears] [--depth 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\u002Ftasks",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":73,"prompt":83,"zipAvailable":84},[74,77,80],{"tool":75,"command":76},"npx","npx skills add carinyadigital\u002Fskills --skill tasks",{"tool":78,"command":79},"bunx","bunx skills add carinyadigital\u002Fskills --skill tasks",{"tool":81,"command":82},"pnpm","pnpm dlx skills add carinyadigital\u002Fskills --skill tasks","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fcarinyadigital\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Ftasks\u002FSKILL.md",true,[86,92,96,100,106,110,114,118,122,126,130,134],{"path":87,"resourceType":88,"resourceTypeDesc":89,"sizeBytes":90,"sourceHtmlUrl":91},"assets\u002Fbacklog.template.md","ASSET","资产文件",2184,"https:\u002F\u002Fgithub.com\u002Fcarinyadigital\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Ftasks\u002Fassets\u002Fbacklog.template.md",{"path":93,"resourceType":88,"resourceTypeDesc":89,"sizeBytes":94,"sourceHtmlUrl":95},"assets\u002Ftasks-local.template.md",971,"https:\u002F\u002Fgithub.com\u002Fcarinyadigital\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Ftasks\u002Fassets\u002Ftasks-local.template.md",{"path":97,"resourceType":88,"resourceTypeDesc":89,"sizeBytes":98,"sourceHtmlUrl":99},"assets\u002Ftasks.template.md",5759,"https:\u002F\u002Fgithub.com\u002Fcarinyadigital\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Ftasks\u002Fassets\u002Ftasks.template.md",{"path":101,"resourceType":102,"resourceTypeDesc":103,"sizeBytes":104,"sourceHtmlUrl":105},"evals\u002Fevals.json","REFERENCE","参考文档",3812,"https:\u002F\u002Fgithub.com\u002Fcarinyadigital\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Ftasks\u002Fevals\u002Fevals.json",{"path":107,"resourceType":102,"resourceTypeDesc":103,"sizeBytes":108,"sourceHtmlUrl":109},"evals\u002Ftrigger-queries.json",585,"https:\u002F\u002Fgithub.com\u002Fcarinyadigital\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Ftasks\u002Fevals\u002Ftrigger-queries.json",{"path":111,"resourceType":102,"resourceTypeDesc":103,"sizeBytes":112,"sourceHtmlUrl":113},"examples\u002Fbacklog.md",1470,"https:\u002F\u002Fgithub.com\u002Fcarinyadigital\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Ftasks\u002Fexamples\u002Fbacklog.md",{"path":115,"resourceType":102,"resourceTypeDesc":103,"sizeBytes":116,"sourceHtmlUrl":117},"examples\u002Fcheckout-foundation.md",7265,"https:\u002F\u002Fgithub.com\u002Fcarinyadigital\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Ftasks\u002Fexamples\u002Fcheckout-foundation.md",{"path":119,"resourceType":102,"resourceTypeDesc":103,"sizeBytes":120,"sourceHtmlUrl":121},"references\u002Facceptance-criteria.md",4588,"https:\u002F\u002Fgithub.com\u002Fcarinyadigital\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Ftasks\u002Freferences\u002Facceptance-criteria.md",{"path":123,"resourceType":102,"resourceTypeDesc":103,"sizeBytes":124,"sourceHtmlUrl":125},"references\u002Fdelivery-conventions.md",7036,"https:\u002F\u002Fgithub.com\u002Fcarinyadigital\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Ftasks\u002Freferences\u002Fdelivery-conventions.md",{"path":127,"resourceType":102,"resourceTypeDesc":103,"sizeBytes":128,"sourceHtmlUrl":129},"references\u002Fwork-item-resolution.md",8371,"https:\u002F\u002Fgithub.com\u002Fcarinyadigital\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Ftasks\u002Freferences\u002Fwork-item-resolution.md",{"path":131,"resourceType":102,"resourceTypeDesc":103,"sizeBytes":132,"sourceHtmlUrl":133},"references\u002Fwork-item-schema.md",9414,"https:\u002F\u002Fgithub.com\u002Fcarinyadigital\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Ftasks\u002Freferences\u002Fwork-item-schema.md",{"path":135,"resourceType":136,"resourceTypeDesc":137,"sizeBytes":138,"sourceHtmlUrl":139},"scripts\u002Fcheck-epic-paths.sh","SCRIPT","脚本",1402,"https:\u002F\u002Fgithub.com\u002Fcarinyadigital\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Ftasks\u002Fscripts\u002Fcheck-epic-paths.sh",[141,156,178,207,232,246],{"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":148,"publishedAt":48},"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",[147],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[149,150,151,152,153,38,154,155],"skill name","name","with","replace","use","author","it",{"skillNo":157,"name":158,"nameZh":6,"description":159,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":160,"categories":161,"keywords":169,"publishedAt":48},"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",[162,165,168],{"categoryNo":163,"categoryName":164,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":166,"categoryName":167,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[158,47,170,46,171,172,43,41,173,40,174,39,29,38,175,176,37,36,5,177],"branch","code review","decision","decision-support","writing","updates","done","drafting",{"skillNo":179,"name":180,"nameZh":6,"description":181,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":182,"categories":183,"keywords":189,"publishedAt":48},"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",[184,185,186],{"categoryNo":166,"categoryName":167,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":187,"categoryName":188,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000032","设计师",[43,190,191,192,193,194,195,170,196,197,198,199,40,200,201,202,203,204,205,206],"ux design review","review","ux","ux design","design review","reviews","figma","browser mcp","static","fix","URL","components","server","interaction","security review","figma mcp","read",{"skillNo":208,"name":209,"nameZh":6,"description":210,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":211,"categories":212,"keywords":219,"publishedAt":48},"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",[213,214,215,218],{"categoryNo":166,"categoryName":167,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":216,"categoryName":217,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000030","开发工程师",{"categoryNo":187,"categoryName":188,"taxonomyType":26,"taxonomyTypeDesc":27},[199,43,192,220,193,221,197,222,223,224,225,226,227,228,229,230,40,231,38,37],"ux design fix","design fix","states","project","re","review findings","card","flows","local","ux-design","new","either",{"skillNo":233,"name":234,"nameZh":6,"description":235,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":236,"categories":237,"keywords":240,"publishedAt":48},"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",[238,239],{"categoryNo":166,"categoryName":167,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[234,47,241,242,224,243,244,245,43,41,40,174,38,37,36,5,35,191,33,32],"test-driven","green","mode","failing","skeleton",{"skillNo":247,"name":248,"nameZh":6,"description":249,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":250,"categories":251,"keywords":252,"publishedAt":48},"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",[],[46,253,254,255,256,172,173,257,39,38,36,258,191,33,32,259,260,261,262,263],"sprint retro","retro","alignment","actions","themes","code-review","sprint-planning","plan","next","how","support"]