# Feature items

A user-facing capability, described through persona-worded user stories.

**Lifecycle:** Draft → Ready → InProgress → InReview → Done (+ Blocked, Cancelled)

## Commands

```bash
sq create feature "…" --author product-owner [--parent EPIC-…]
sq feature <n> add-story "As a <role>, I want … so that …"
sq feature <n> story <k> update --status InProgress   # Todo → InProgress → Done
sq feature <n> stories
```

## For Nina Product (`product-owner`)

**Enter** — before you act:
- Read the full item dossier: `sq feature <n> show --full --comments` (decisions and
  refinements often live in discussion comments, not the body — skipping this is how context
  gets missed).
- confirm the user need and which epic (if any) it belongs under

**Do:**
- author the feature (`sq create feature "…" --author product-owner`)
- add persona-worded user stories (`sq feature <n> add-story "As a … I want …"`) — the title is the user-story phrase
- write each story's body (`sq feature <n> story <k> body -m …`) — the acceptance criteria live there, not in the title
- use `sq feature <n> story <k> comment` for story-scoped acceptance clarifications or questions — cross-cutting notes go on the feature (see the `squads` skill's comment-scoping convention)

**Hand off:**
- when stories and acceptance criteria are complete and the feature is greenlit, `@tech-lead` to break it into tasks

**Watch for:**
- stories describe user value + acceptance criteria — not implementation steps
- a story is not done until its body carries acceptance criteria — an unwritten placeholder body is a defect even if the title reads fine

## For Olivia Lead (`tech-lead`)

**Enter** — before you act:
- Read the full item dossier: `sq feature <n> show --full --comments` (decisions and
  refinements often live in discussion comments, not the body — skipping this is how context
  gets missed).
- read every user story + its acceptance criteria (`sq feature <n> show`)

**Do:**
- create tasks with this feature as parent (`sq create task … --parent FEAT-<n>`)
- map each subtask to one user story (`sq task <n> add-subtask … --story USk`)
- use `sq feature <n> story <k> comment` for story-scoped questions (see the `squads` skill's comment-scoping convention)

**Hand off:**
- when tasks are created, assigned, and sequenced, `@<tech>-dev` (or spawn the developer) to begin implementation

**Watch for:**
- if a story is ambiguous, ask the product-owner (`@product-owner`) first

## For Mara Tester (`qa`)

**Enter** — before you act:
- Read the full item dossier: `sq feature <n> show --full --comments` (decisions and
  refinements often live in discussion comments, not the body — skipping this is how context
  gets missed).
- read the user stories + acceptance criteria

**Do:**
- derive test cases from each story
- verify the feature against its acceptance criteria once tasks land

**Hand off:**
- when acceptance criteria all pass, confirm in a comment so the feature can close; when one fails, file a bug and `@tech-lead`

---
The `.md` files are sq-managed — never edit them by hand. Items are addressed as
`sq feature <n> <verb>`. Set this item's body with `sq feature <n> body
-m "…"` (or `--file`); `--desc` sets only the short summary. Its user stories / subtasks / findings
get their bodies from `sq feature <n> <kind> <k> body -m "…"`. Read anything back with
`sq feature <n> show --full --comments` (full dossier, including discussion) /
`sq feature <n> <kind> <k> show`.
