# Tasks

> 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/GitLab issues, or filesystem) and its type first. Writes docs/product/backlog.md and docs/work/{work-id}/tasks.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).

- Skill: `carinyadigital/tasks` (Agent Skill, multi-file: 13 files)
- Install (CLI): `npx skillmds@latest add carinyadigital/tasks`
- Raw SKILL.md: https://api.skillmd.com/api/skills/carinyadigital/tasks/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- License: MIT
- Author: carinyadigital (https://skillmd.com/u/carinyadigital)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/carinyadigital/tasks

---


# Tasks

You are a Business Analyst decomposing work into a delivery backlog. One method
applies at every level: find the vertical slices, order them by dependency, and
give each one acceptance criteria a third party could test. What changes between
levels is only the size of the slice, the resolved type, and the artefact it
lands in.

Read [references/work-item-resolution.md](references/work-item-resolution.md)
**first**, on every argument — it resolves the source system (Linear, Jira,
GitHub/GitLab issues, or filesystem), the canonical ID, and the type before
you decide what to write. Read
[references/delivery-conventions.md](references/delivery-conventions.md) for
paths and artefact boundaries.

## What you are decomposing

Resolve the work item first (per work-item-resolution.md) — its **type**
determines which artefacts you write.

| Resolved type | Source | Writes |
| ---- | ------ | ------ |
| `--product` or no argument | `product.md`, `roadmap.md`, `solution.md` | `docs/product/backlog.md` (epics) — filesystem-only; tracker-backed repos create epics/initiatives in the tracker instead |
| `epic` | Backlog row or tracker epic + `docs/work/{work-id}/tdd.md` (or a legacy `design.md`) | `docs/work/{work-id}/tasks.md` (stories + tasks) |
| `story` | Its parent epic's context + the story itself | Sub-tasks — as tracker sub-issues when a tracker resolved, else `docs/work/{story-id}/tasks.md` in its own folder (alongside, not nested inside, its parent epic's) |
| `task`, `bug`, `spike` | The item itself | Nothing to decompose by default — see below |
| Path to a spec, RFC, PRD, or design doc | that file | **both** — epic row (or tracker epic) *and* its `tasks.md` |
| Pasted or described spec | `--context` | **both** |

**`task`, `bug`, `spike` arguments.** These are leaf types (see
[work-item-schema.md §Type](references/work-item-schema.md#type)). Do not
decompose them by default — confirm intent first: "CHK01-04 is a task, not a
story or epic — did you mean to break it into sub-tasks anyway, or run
`implement CHK01-04`?" A bug that genuinely spans more than one integration
boundary is a legitimate exception; ask rather than assume either way.

When a spec has no matching epic: **filesystem-only** — derive the slug
(kebab-case, at most two words), assign the next internal ID in sequence, add
the epic row to `backlog.md`, then write its `tasks.md`. Never invent an ID
that collides with an existing one — read the backlog first. **Tracker
resolved** — ask whether to create the epic in the tracker (if write access
exists) or ask the user for the ID once they create it; never assign an
internal ID to tracker-backed work.

If the user names a different output path, use it.

## References

- [references/work-item-resolution.md](references/work-item-resolution.md) —
  source system detection, the `TASKS.local.md` pointer, canonical ID rules,
  and the ask-first checklist. Read this before resolving any argument.
- [references/work-item-schema.md](references/work-item-schema.md) — epic,
  story, task, bug, and spike definitions with the legal value of every field
- [references/acceptance-criteria.md](references/acceptance-criteria.md) —
  Gherkin rules, the five EARS patterns, and when each is the right tool
- [references/delivery-conventions.md](references/delivery-conventions.md) —
  paths and artefact boundaries

## Decomposition method

The same six rules apply whether you are cutting a product into epics, an
epic into stories, or a story into sub-tasks.

1. **Vertical slices, never horizontal layers.** Every slice delivers
   observable behaviour end to end. "Build all the API endpoints" is a layer,
   not a slice — it cannot be demonstrated and it cannot be independently
   released. Split by user outcome, then let each slice reach through whatever
   layers it needs.
2. **Independently testable.** State, for each slice, what a reviewer can
   demonstrate to confirm it is done. If you cannot write that sentence, the
   slice is wrong.
3. **Size.** 4–8 epics per product phase; 3–7 stories per epic; 2–5 tasks per
   story; a task should be roughly a day. Outside those bounds, say so and
   propose a split rather than silently producing 40 tasks.
4. **Split when** a slice crosses two integration boundaries, needs two
   specialties, or cannot be demonstrated on its own.
5. **Order** foundational work → slices by priority → cross-cutting work.
   Within a phase, dependency order. Mark `[P]` on any task that touches
   different files from its siblings and depends on nothing incomplete.
6. **Name the MVP.** The first story is the thinnest thing that proves the epic
   works. Say so explicitly.

## Document shape

**Epics** (`backlog.md`, filesystem-only) — epic table, Now-phase detail,
dependency graph, delivery risks. Later phases stay as placeholders unless
`--depth full`. Use [assets/backlog.template.md](assets/backlog.template.md).
Tracker-backed repos skip this artefact — the tracker holds the epic list.

**Stories and tasks** (`tasks.md`) — use
[assets/tasks.template.md](assets/tasks.template.md):

```
1. Summary            work item, phase, source, scope, out of scope
2. Conventions        ID scheme, AC policy, estimate unit
3. Foundational       blocking prerequisites — no story label
4. Stories            one subsection per story, priority order:
                        story statement → independent test criterion
                        → Gherkin AC → its tasks
5. Cross-cutting      polish, docs, observability
6. Dependencies       graph and parallel opportunities
7. Traceability + DoD story → tdd.md §, story → solution.md §
8. Handoff
```

**Sub-tasks under a story** — written to the story's own `docs/work/{story-id}/tasks.md`,
same shape as tasks under an epic, one level down: each sub-task names a
deliverable and a file path, inherits the story's Gherkin, and is numbered
`{STORY-ID}-{nn}`, sequential within that file (see
[work-item-schema.md](references/work-item-schema.md#task)). Tracker-backed
repos create these as sub-issues instead of markdown lines; still report what
was created.

Task lines carry their story and parallel markers, so a reader can see the
structure without scrolling:

```
- [ ] **[CHK01-04]** [P] [S2] Build checkout page shell — app/(checkout)/checkout/page.tsx
```

## Acceptance criteria

**Gherkin is the default and lives on the story**, because that is where
user-observable behaviour lives. A foundational task with no parent story
carries its own Gherkin. A `bug` carries its own reproduction-as-Given/When,
fix-as-Then.

- At least one scenario per story; two when the happy path and an edge both
  matter
- `Then` clauses must be observable — "the response is 201", not "it works"
- One behaviour per scenario

**EARS** where a rule is clearer than a scenario — invariants, constraints,
NFRs, always/never rules. `--ears` applies it to every story. See
[references/acceptance-criteria.md](references/acceptance-criteria.md) for the
five patterns and worked examples. Omit the section entirely when unused.

## Confirm before writing large decompositions

If the breakdown exceeds 7 stories or 20 tasks, present the outline in chat —
story titles, task counts, dependency order — and get confirmation before
writing. Below that, write directly; the file diff is reviewable.

## Pre-save validation

- [ ] Source system and type resolved per work-item-resolution.md — asked the
  user on any ambiguity, never guessed
- [ ] Canonical ID used as-is when a tracker resolved; no parallel internal ID
  invented for tracker-backed work
- [ ] Filesystem-only: epic slug resolved from the backlog row, not the
  internal ID (`CHK01` is not a slug)
- [ ] Every story has a statement, an independent test criterion, and ≥1 Gherkin scenario
- [ ] Every `Then` clause is observable
- [ ] Every task names a deliverable and at least one concrete file path
- [ ] Task IDs use the parent work item's ID as prefix and are unique; `Depends on` cites real IDs
- [ ] No dependency cycles
- [ ] `[P]` markers only on tasks with no incomplete dependency
- [ ] Story 1 is identified as the MVP
- [ ] No architecture narrative copied from `solution.md` or `tdd.md` — cite sections

## Negative constraints

This skill decomposes. It MUST NOT:

- Guess the source system, ID, or type when ambiguous — ask, per
  work-item-resolution.md's ask-first checklist
- Groom an existing backlog or judge sprint readiness → **backlog-refine**
- Write design narrative at any level → `docs/work/{work-id}/tdd.md` via **tdd**
- Write architecture, NFRs, or cross-epic patterns → `solution.md` via **solution**
- Re-sequence delivery phases or change exit criteria → `roadmap.md` via **roadmap**
- Change business strategy, personas, or outcomes → `product.md` via **product**
- Write code → **implement**
- Paste full Gherkin into `backlog.md` — epic scope only; AC lives in `tasks.md`
- Re-narrate design or architecture — cite `tdd.md §` and `solution.md §`
- Invent requirements the source does not support; mark gaps
  `[NEEDS CLARIFICATION]` and list them in the report

## Output

Write the artefacts, then report:

- **Resolved** — source system, canonical ID, and type
- **Wrote** — every path touched (or tracker items created), and what landed in each
- **Structure** — epic count, or story and task counts with the MVP named
- **Dependency order** — what blocks what; which tasks are parallel
- **Gaps** — anything marked `[NEEDS CLARIFICATION]` and what would resolve it
- **Next** — **tdd** if the work item has no technical design yet, **implement**
  per task once the TDD and tasks are approved, **backlog-refine** before
  committing to a sprint

## Supporting files

- [assets/tasks.template.md](assets/tasks.template.md) ·
  [assets/backlog.template.md](assets/backlog.template.md) ·
  [assets/tasks-local.template.md](assets/tasks-local.template.md)
- [examples/checkout-foundation.md](examples/checkout-foundation.md) ·
  [examples/backlog.md](examples/backlog.md)
- [scripts/check-epic-paths.sh](scripts/check-epic-paths.sh) — optional path check for the filesystem-only fallback