---
model: sonnet
---

# /tas-feature $ARGUMENTS

Role: PE - Product Engineer
Create or update a Feature document. Feature is the **only** unit of business work in TAS — Epic and Story are removed.

**Scope:** Business logic, AC, NFR.
**Out of scope:** Technical implementation, file changes, ERD, ADR — that's `/tas-plan`'s job (writes `Feature-{NNN}-Technical.md`).

## Always / Ask / Never

| | Action |
|---|---|
| **Always** | Write AC in Given/When/Then format |
| **Always** | Set `plan_status: pending` for new Feature |
| **Always** | Read PRD + SAD before proposing Features |
| **Always** | Infer stacks from SAD architecture — do NOT ask user to specify stacks |
| **Always** | Run the feature-completeness gap pass (read SAD §8–12, apply lenses) before presenting Features — including when adding a single Feature during maintenance |
| **Always** | In ad-hoc mode: write Feature first (Gate 1), then PRD delta (Gate 2) — never show both drafts simultaneously |
| **Always** | In ad-hoc mode: check ADRs for conflicts before drafting |
| **Never** | Write Technical Plan content here |
| **Never** | Suggest or create ADRs — `/tas-plan` documents decisions, human approves ADRs |
| **Never** | Use SAD for technical analysis — read SAD only for system layers and dependency order |
| **Never** | Write PRD before Feature is approved in ad-hoc mode |

## Prerequisites
- `tas.yaml` exists at project root
- (Optional but preferred) `docs/prd.md` — for FR list and business context
- (Optional but preferred) `docs/sad.md` (or linked SAD file) — for system architecture layers and component dependency order

## Gate (run first)
If `workflow.gate_enforcement: true` in `tas.yaml` (default true): require BOTH `docs/prd.md` AND `docs/sad.md` frontmatter `artifact-status: approved` — grep only the `artifact-status:` line of each. Any missing or not `approved` → **STOP** naming which one and how to fix (set it to `approved`, or set `workflow.gate_enforcement: false`). If `false` → skip.
**Exemption:** Ad-hoc Mode (requirement not in PRD) is exempt — it deliberately authors a new FR and updates the PRD afterward, so skip the gate when entering Ad-hoc Mode.

## Actions

### CREATE mode (`$ARGUMENTS` is new Feature description, or no `$ARGUMENTS`)

**Step 1 — Read context** *(never read full PRD/SAD — grep headings `^#{1,4} ` first, then Read only the sections you need by line range)*
- Read `project.code` from root `tas.yaml`
- `docs/prd.md` if exists — Read the FR list section (grep headings, jump to "Functional Requirements"); pull business context only for FRs in scope of `$ARGUMENTS`
- SAD if exists — grep headings, Read only the architecture-overview / container sections to extract:
  - Which layers/stacks exist in this system (`app`, `web`, `service`, `integration` — only layers actually present)
  - Component or layer dependencies (which components must exist before others)

**Step 1.5 — Match $ARGUMENTS against PRD (only when $ARGUMENTS is a description)**

If `$ARGUMENTS` is a description (not a Feature ID, not empty):
- Compare against existing FRs in PRD
- If **clear match found** → continue to Step 2 (normal flow for that FR)
- If **no match** → enter **Ad-hoc Mode** below

#### Ad-hoc Mode — New Requirement Not in PRD

Used when customer brings a requirement not covered by existing PRD FRs.

**a. Announce:**
> "Requirement not found in PRD. Entering ad-hoc mode — will survey, create Feature, then update PRD."

**b. Q&A — use `AskUserQuestion` tool (popup UI), split into 2 calls:**

**Popup call 1** (up to 4 questions):
- "What business value does this deliver? Who benefits?" — header: `Business`
- "Who are the actors / triggers? Any external systems?" — header: `Actors`
- "Key business rules or constraints?" — header: `Rules`
- "NFR priorities?" — header: `NFR`, `multiSelect: true`, options: Performance / Security / Compliance / Scalability / Accessibility

**Popup call 2** (after call 1 answers received):
- "Which stacks does this touch?" — header: `Stacks`, `multiSelect: true`, options: list only stacks found in SAD (web / service / integration / app — only those present)

Wait for all answers before proceeding to step c.

**c. ADR conflict check:**
Read `docs/adr/*.md` if exists. Flag any conflict:
> "⚠️ Conflict with ADR-XXX: [decision]. This requirement may require revisiting [constraint]."

**d. Draft Feature (in-conversation):**
Using PE answers + ADR check, draft full Feature content following `.tas/templates/Feature.md` structure (Description, User Flow, Design Reference, NFR, AC in Given/When/Then). No User Story and no separate Actor section — the actor is named on each User Flow step (from PRD.Persona / BRD `AT-NNN`). No separate Business Rules section — **tag each AC explicitly with its FR and enforced rule: `AC-N (FR-NNN, BRU-NNN)`**. Set frontmatter `implements_frs: [FR-NNN]` (the FR Reference); leave `depends_on_features` for `/tas-master-plan` to write.

**e. Gate 1 — Feature approval:**
> "Feature draft above OK? Approve to write file."
- Approved → assign next Feature ID (scan `docs/features/`), create directory + write file → **skip Steps 2–6, go to step f**
- Feedback → update draft, ask again

**f. Draft PRD delta (in-conversation):**
After Feature file written, draft PRD addition for the new FR. Default: FR title + one-line description + reference to Feature file. Show draft and note:
> "Default: minimal FR entry. Expand if more business context needed."

**g. Gate 2 — PRD approval:**
> "PRD update above OK? Approve to write."
- Approved → append new FR to `docs/prd.md` (in appropriate section)
- Feedback → update draft, ask again

**h. Proceed to Step 7** (update `project-status.yaml`)

**i. Update master plan (if exists):**
- Check if `docs/master-plan.md` exists
- If exists → invoke `/tas-master-plan AMEND` inline (follow that command's AMEND mode steps); do not end turn, wait for result before continuing
- If not → skip

**Proceed to Step 8** (notify).

---

**Step 2 — Infer stacks per FR + determine order**
- For each FR in PRD:
  - Read FR description and understand what parts of the system it touches
  - Cross-reference SAD architecture to confirm which layers are involved
  - Example: "User Login FR" touching web UI + auth API + external IdP → inferred stacks: `web`, `service`, `integration`
- Order FRs by SAD dependency (foundation layers first — e.g., `service` before `web`, `web` before `integration` adapters)
- Result: one Feature per FR, with inferred stacks noted as context for PE

**Step 2.5 — Feature completeness pass**

Run the gap analysis from `.tas/rules/common/feature-completeness.md`: read SAD §8–12 carefully, walk the 11 functional lenses against the FR(s) in scope, and route each candidate (→ Feature / → NFR / → SAD). Present the rule's approval table; approved `→ Feature` rows join the proposed list in Step 3. (Runs the same way for a single added Feature during maintenance — apply the lenses to the new Feature's scope.)

**Step 3 — Present proposed Feature list + confirm**

Show ordered list with inferred stacks as context. Example:

```
Proposed Features (ordered by dependency):

[ ] Feature-NNN-auth        FR-001: Authentication   (touches: service, integration, web)
[ ] Feature-NNN-checkout    FR-002: Checkout         (touches: service, web)

Select which to create now (all, or specific numbers):
```

User can select all or a subset. Proceed only for selected items.

**Step 4 — Assign Feature IDs**
- Scan `docs/features/` for existing `{CODE}-Feature-NNN-*` directories
- Assign next sequential ID (max existing NNN + 1, +1 per new Feature in this batch)
- IDs assigned in the order shown in Step 3

**Step 5 — Create directory + file for each selected Feature**
- Directory: `docs/features/{CODE}-Feature-{NNN}-{slug}/`
- File: `docs/features/{CODE}-Feature-{NNN}-{slug}/{CODE}-Feature-{NNN}-{slug}.md`
- Use template `.tas/templates/Feature.md`
- Frontmatter: `plan_status: pending`, `plan_date:` empty

**Step 6 — Walk PE through filling each Feature (one at a time)**

For each created Feature file, ask PE to provide:

a. **Description**: short summary — for which actor, what it does, business value (the "why")
b. **FR Reference**: which PRD `FR-NNN` this Feature implements → set `implements_frs`
c. **User Flow**: "Detailed steps in this feature — each UI/API action, validation, branch (detail of PRD.UF)? **Name the actor on each step** (PRD Persona / BRD `AT-NNN`) — there is no separate Actor section."
d. **Design Reference** *(skip / `N/A` if backend-only or no UI/UX Design stage)*: "Which `SCR-NNN` (UI/UX Design.Generated Screens) apply, and which Design Spec component/token/breakpoint IDs? **Reuse defaults to `pixel-perfect`** — copy the Generated Screen's layout/CSS as-is, only wire real data/state. Only choose `build` when the Generated Screen genuinely cannot render a state this Feature needs (e.g. no screen exists yet, or a role/permission state the mockup never drew). **A mismatch between the mockup's demo data and the real API/data contract is NEVER a valid reason to choose `build`** — that data gets rewired regardless of Reuse mode; the layout still gets copied."
e. **Non-Functional Requirements**: "Which PRD `NFR-NNN` apply to this Feature? (measurable)"
f. **Acceptance Criteria** (Given/When/Then): "AC-1, AC-2... each testable? **Tag each AC as `AC-N (FR-NNN, BRU-NNN)`** — explicit FR + enforced BRU reference, no separate Business Rules section. Every applicable `BRU-NNN` must appear in ≥1 AC."
g. **Definition of Done**: default to the Standard DoD (`.tas/rules/common/feature-done.md`); only capture feature-specific additions.

After completing one Feature, move to next selected Feature.

**Step 7 — Update `project-status.yaml`**
- Per `.tas/rules/common/project-status.md` — add one entry per created Feature to flat `features.{FEATURE_ID}` map.

**Step 8 — Notify next step**
> "Features created. For each Feature, run `/tas-plan {Feature-ID}` to generate `Feature-{NNN}-Technical.md` before SE codes."

---

### UPDATE mode (`$ARGUMENTS` is Feature ID, e.g., `Feature-003`)

1. Find file via glob `docs/features/{CODE}-Feature-{ID}-*/**.md` (excluding `*-Technical.md`)
2. Read current Feature file **in full first** — preserve any human edits; merge the change rather than overwriting sections.
3. Ask user what to change (description, user flow, design reference, NFR, AC — with their `(FR, BRU)` tags — status...)
4. Update file, add Changelog entry: date + changes + author
5. Update `project-status.yaml` per `.tas/rules/common/project-status.md` — update `features.{FEATURE_ID}.status`
6. If AC changed: warn user that downstream artifacts may be stale — `Feature-{NNN}-Technical.md`, `Func-Test-*.md` (impact/blast-radius analysis happens at `/tas-plan` re-plan, not here — this command stays business-only)

## Principles
- Feature is a **complete business flow** that can be released to production after coding
- One Feature = one business requirement. A Feature may span multiple stacks (`app`, `web`, `service`, `integration`) — per-stack technical breakdown lives in `Feature-{NNN}-Technical.md`
- Each Feature lives in its own directory under `docs/features/`
- Feature MUST have clear, testable Acceptance Criteria in Given/When/Then format, each tagged `AC-N (FR-NNN, BRU-NNN)`
- Business rules are enforced via the `BRU-NNN` referenced in the ACs (no separate section); every applicable BRU must appear in ≥1 AC so it gets a test
- Non-Functional Requirements MUST be measurable when applicable
- Test cases (Functional / E2E) live in separate files in same directory — NOT in Feature doc
- Technical content (ERD, files, config, ADR, per-stack breakdown) lives in `Feature-{NNN}-Technical.md` — generated by `/tas-plan`

## Final Step — Token Log

Follow `.tas/rules/common/token-logging.md`: write AI Usage Log to working Feature file.