PM - Features List

Agent mode (--agent)

Supports --agent: runs autonomously in a subagent, drafts the artifact from existing inputs, and returns a short summary + coverage note.

• No flag → interactive (default); if inputs are heavy, offer agent mode.
• --agent → obey. First check inputs are complete. Anything missing: do NOT invent it - mark [ASSUMED - what/why] in the output and summary. Never hallucinate to fill a gap.
• Review required: the artifact contains commitments - after drafting, require the user's review before finalizing; do not close decisions autonomously.

Standalone run

Needs the artifacts listed under Dependencies - it synthesizes them, so without them there is nothing to synthesize.

• No workspace, or inputs missing: name which are missing and what each one unlocks, then offer the PREREQ paths - proceed on stated assumptions marked [ASSUMED - what/why], or route to the skill that produces the missing input. Never hard-block, and never invent the input.
• Writing never depends on /pureinn having run: with no workspace, create just the folder this skill writes into, or write to a path the user names, and say where the file went.
• Read pureinn-variables.md / state.json where a value is actually used, not at the top of the run. Missing value: continue and name the capability it costs.

What this skill does

Phase 5 / Step 1-3. Takes the product scope from PRD Business Capabilities and produces:

1. FDD Feature List (features/feature_list.md) - Live Register 4. All features in FDD format ([Action] [Result] [Object]), organized in 3-level hierarchy: Domain -> Feature Set -> Feature. With actor, priority, dependencies, MVP flag, and stripe assignment.
2. Dependency Map - which features block which, critical path, parallelizable tracks
3. KANO Analysis - must-be / performance / delighter / indifferent classification per feature
4. Value vs. Complexity Matrix - Quick Win / Big Bet / Fill-in / Time Waster scoring per feature
5. Stub Feature Cards - one per feature, created automatically in /features/cards/FEAT-[DOMAIN]-[NUMBER].md with status 1_Backlog

After user approval: push the complete feature inventory to Notion as the initial product backlog.

This is the direct input for pm-mvp-scope, which makes the MVP cut per feature and assigns features to Delivery Stripes.

Prioritization methods used

KANO Analysis

Classifies each feature by the type of value it delivers to the customer:

How to classify: ask "how would you feel if this feature existed?" and "how would you feel if it didn't?" The combination of answers maps to KANO category. When in doubt: what does the customer assume is already there? That's Must-be.

Value vs. Complexity Matrix (V×C)

Maps each feature on two axes to determine delivery order:

Value = business impact + customer pain relief (use KANO + validated pains from Problem Validation). Complexity = estimated build effort + technical risk + dependency depth.

KANO tells you what to include. V×C tells you in what order to deliver it. Use both - KANO without V×C gives no delivery order; V×C without KANO can lead to building the wrong things quickly.

Dependencies

Required before running:

• pm-prd - PRD Business Capabilities section is the primary input for feature extraction (or pm-scope-brief on commissioned builds - product/scope_brief.md carries the same Business Capabilities contract)
• pm-entity-registry - entities.md informs what operations are needed per domain

Recommended before running:

• pm-personas - user roles drive which features belong to which actor
• pm-problem-validation - validated pains confirm which features address real needs
• pm-business-rules-library - known compliance rules may constrain feature scope

Produces artifacts used by:

• features/feature_list.md - Live Register 4 of 4 (FDD Feature List)
• /features/cards/FEAT-*.md - stub Feature Cards (one per feature, status: 1_Backlog)
• pm-mvp-scope - feature list is the direct input for MVP cut + stripe assignment
• pm-product-roadmap v3 - features populate the delivery view
• Phase 6 skills - pm-feature-design reads Feature Cards JIT before each feature enters build

Open questions

Open questions and decisions have exactly one home in the whole project: domain/open_questions.md (Live Register 5, owned by pm-open-questions). If prioritization or scoping surfaces a genuine judgment call (e.g. unclear which phase/MVP-cut a capability belongs to, before pm-mvp-scope can rule on it) do not embed it as a note in feature_list.md - append an entry to the register (Type: Question, OQ-{DOMAIN}-NN or OQ-MVP-NN for MVP-cut questions; run pm-open-questions to initialize it first if it doesn't exist).

Step 0: Current state check + mode detection

Check for existing artifacts:

• features/feature_list.md (Live Register 4)
• Dependency Map
• KANO Analysis
• Value vs. Complexity Matrix
• Stub Feature Cards in features/cards/

Mode detection:

If FI Append mode detected, show existing feature count and domain list, then use AskUserQuestion:

• Question 1: "Which initiative slug and domain code? (e.g., initiative: ai-onboarding, domain code: ONB → features will be FEAT-ONB-001...)" (free text)
• Question 2: "Input source for the new initiative features?" with options:
  • Option A: "Initiative PRD at initiatives/[slug]/prd.md - Business Capabilities section (Recommended)"
  • Option B: "Paste Business Capabilities directly"

Also check: does entities.md include the new domain entities? Without domain entities for the new initiative, feature-entity alignment will be guesswork.

Look for: features named as capabilities rather than actions, features too large for a single delivery cycle (split needed), missing user role attribution, duplicates, KANO classification without rationale. Domains and Feature Sets are GROUPING ONLY.

Interaction: Group related questions (2-4 per round) and confirm before moving on. For any A/B/C/D choice, use the AskUserQuestion tool with one option marked (Recommended) - never print options as plain text. Keep open-ended questions free-text (don't fake options). If the user is unsure, propose 3-4 concrete options plus "Other". Surface an assumption the moment you make one; never fabricate to fill a gap. (Full standard: CLAUDE.md.)

Step 1: Gather inputs

Use AskUserQuestion tool for this scoping question:

What is the goal for this session?

A) Full extraction - map all features across the entire product scope, prioritize with KANO + V×C (Recommended for first run) B) Focused area - extract and prioritize features for one specific functional area only C) Refresh - update an existing list with new features or re-run prioritization D) Quick scan - extract a rough feature list without full KANO + V×C scoring

Then ask the remaining inputs as plain text:

I need inputs for the FDD Feature List (Live Register 4), Dependency Map, and KANO + V×C prioritization.

1. PRD BUSINESS CAPABILITIES
   Paste the Business Capabilities section from the PRD, or confirm it is in context.
   I will extract features from these capabilities using FDD grammar [Action] [Result] [Object].
   [paste or "in context"]

2. USER ROLES
   Who are the actors in the system? (e.g., Host, Guest, Admin, Property Manager)
   Which role is primary (most features serve them)?

3. ENTITY REGISTRY REFERENCE
   Is entities.md in context? (informs what operations are needed per domain entity)
   [confirm or "not yet"]

4. FEATURE IDEAS
   Do you have any feature ideas already written down?
   (Paste any list, notes - NO User Stories please, just capabilities or action descriptions)
   [paste or "nothing yet - extract from PRD only"]

5. KNOWN DEPENDENCIES
   Are there features you know depend on each other?
   (e.g., "payment must come before booking confirmation", "listing must exist before search")
   [describe or "none known yet"]

6. NOTION SETUP
   Read pureinn-variables.md, key "Feature Backlog". Skip this question if URL is present.
   If blank: do you have a Notion Product Features database to push features to after approval?
   [yes - paste URL / no - skip]

Step 2: Generate FDD Feature List (Live Register 4)

Hierarchy:

• Domain - business area, determines the feature ID prefix (ORD, PAY, USR...). Corresponds to entity clusters in entities.md.
• Feature Set - optional grouping label within a domain. Use when a domain has 5+ features that naturally cluster (e.g., "Checkout Flow", "Order History"). Grouping only - no separate spec document per Feature Set.
• Feature - atomic delivery unit. One Feature Card per feature. Spec written JIT by pm-feature-design.

Before generating:

1. Read PRD Business Capabilities - identify Domains and extract features per domain
2. Decompose each capability into FDD features: [Action] [Result] [Object]
3. Group into Feature Sets where domain has 5+ features (use judgment - don't force grouping)
4. Assign each feature: unique ID (FEAT-[DOMAIN]-[NUMBER], e.g., FEAT-ORD-001), user role, rough complexity
5. Flag features that are likely too large for one delivery cycle (mark for atomic split)
6. Domain and Feature Set are GROUPING ONLY - no execution logic at those levels
7. Entity-coverage cross-check (closes the loop between Register 1 and Register 4): walk every state transition in entities.md - some feature must be the thing that triggers it. A transition no feature triggers is either a dead state or a missing feature; surface it. Run the reverse too: a feature whose action maps to no entity operation or transition is a scope-creep candidate - question it before it gets an ID.

ID format: FEAT-[DOMAIN]-[NUMBER] Domain codes match business_rules.md: ORD (order), PAY (payment), USR (user/auth), INV (inventory), etc.

Generate in English.

ARTIFACT 1: FDD Feature List (Live Register 4)

Save to: pureinn-workspace/[project-slug]/features/feature_list.md

# FDD Feature List
# Live Register 4 of 4 - FDD+SDD Framework

> **Product:** [Product Name]
> **Version:** 1.0
> **Last updated:** [date]
> **Based on:** PRD Business Capabilities v[X], entities.md v[X]

---

> **How to read this register:**
> - Domains and Feature Sets are grouping only - no execution logic
> - All prioritization, dependencies, MVP cut, and stripe assignment is per Feature
> - Status reflects Feature Card status (updated by pm-stripe during JIT cycle)

---

## Feature Naming Convention

**Top-down derivation (Features are leaves, derived last):** Start from the roadmap's Functional Decomposition (Domain > Feature Set), then derive the atomic Features within each Feature Set. Every Feature traces up to a Feature Set and a strategic phase. If no roadmap decomposition exists, derive directly from the domain registers (`entities.md`) - but the roadmap map is the preferred input.

Every feature follows: **`[Action] [Result] [Object]`** (FDD grammar - never the User Story "As a user I want..." form).

- **Action** = a strong, concrete verb. Use: *Calculate, Validate, Generate, Create, Add, Submit, Send, Approve, Cancel, Update, Display, Download, Assign, Reverse*. **Ban vague verbs:** *Process, Manage, Handle, Support, Set up, Maintain, Control* - they hide what actually happens ("Process order" → what exactly?).
- **Result** = the outcome / state change (order confirmation, payment status, availability).
- **Object** = a concrete **entity from `entities.md`** - never an abstract noun ("data", "information", "system", "process").

**Sizing - the atomicity test is SEMANTIC, not time-based:**
A Feature is one coherent, client-valued function with one result. Test: *"Is this one thing the client perceives as value, expressible as `<verb> <result> <object>`?"*
- "...and..." / two independent results → **split** into separate Features.
- A detail or nuance of one Feature → a **Subtask**, not a split.
The `estimate` field (S/M/L) is informational for the roadmap - it is **not** the atomicity gate (dev time compresses with AI agents).

**Validate every feature against the 7 anti-patterns** (fix if any hits): (1) too big - two results, (2) vague verb, (3) technical task with no client value, (4) named after a UI screen, (5) missing acceptance criteria, (6) abstract object, (7) duplicate of an existing feature.

**Feature Set ID convention:**
Feature Sets are grouping labels (not spec artifacts), but each gets a stable ID for indexing and cross-reference. Assign `FS-NN` globally sequential across the whole product (FS-01, FS-02, FS-03...), continuing across domains - not reset per domain. Reference format everywhere is `FS-NN: Name` (e.g., `FS-01: Order Processing`). Each feature inherits its Feature Set's ID; this is written to the `feature_set` field of every stub Feature Card.

---

## [Domain 1: e.g., Order Management]

> **Column codes:** Layer = FE / BE / SYS · Phase = MVP / MVP+ / P1... · Pri = P1-P3 · KANO = M(ust-be) / P(erformance) / D(elighter) / I(ndifferent) · V×C = QW / BB / FI / TW · Sub = has subtasks (✓ / –). Full values live in each card's frontmatter; this is the index.

### FS-01: [e.g., Order Processing]

| ID | Feature | Actor | Layer | Phase | Pri | KANO | V×C | Sub | Stripe | Status | Deps |
|---|---|---|---|---|---|---|---|---|---|---|---|
| FEAT-ORD-001 | [Create] [draft order] [from cart] | Customer | FE | MVP | P1 | M | QW | – | TBD | 1_Backlog | none |
| FEAT-ORD-002 | [Confirm] [order] [after payment] | System | BE | MVP | P1 | M | BB | – | TBD | 1_Backlog | FEAT-ORD-001, FEAT-PAY-001 |
| FEAT-ORD-003 | [Cancel] [order] [before fulfillment] | Customer | FE | MVP | P2 | P | QW | – | TBD | 1_Backlog | FEAT-ORD-001 |

### FS-02: [e.g., Order Fulfillment]

| ID | Feature | Actor | Layer | Phase | Pri | KANO | V×C | Sub | Stripe | Status | Deps |
|---|---|---|---|---|---|---|---|---|---|---|---|
| FEAT-ORD-010 | [Track] [fulfillment status] [for order] | Customer | FE | MVP+ | P2 | P | FI | – | TBD | 1_Backlog | FEAT-ORD-002 |

---

## [Domain 2: e.g., Payments]

### FS-03: [e.g., Card Payments]

| ID | Feature | Actor | Layer | Phase | Pri | KANO | V×C | Sub | Stripe | Status | Deps |
|---|---|---|---|---|---|---|---|---|---|---|---|
| FEAT-PAY-001 | [Validate] [card payment] [for order] | System | BE | MVP | P1 | M | BB | – | TBD | 1_Backlog | FEAT-ORD-001 |
| FEAT-PAY-002 | [Issue] [refund] [for cancelled order] | System | BE | MVP+ | P1 | P | BB | – | TBD | 1_Backlog | FEAT-ORD-003 |

---

## Features Flagged for Splitting

| Feature ID | Reason | Suggested split |
|---|---|---|
| [FEAT-XXX-001] | Too broad - each part separately deliverable | [FEAT-XXX-001a: ..., FEAT-XXX-001b: ...] |

---

## Feature Count Summary

| Domain | Feature Sets | Features |
|---|---|---|
| [Area 1] | [X] | [X] |
| **Total** | **[X]** | **[X]** |

---

## Features Not in Scope (from PRD)

| Capability | Reason excluded | Reconsider when |
|---|---|---|
| [e.g., Native mobile app] | Web-first MVP | After PMF proven on web |

---

## Changelog

| Version | Date | Change |
|---|---|---|
| 1.0 | [date] | Initial extraction from PRD Business Capabilities |

Step 3: Generate Dependency Map

After Features List is approved, run dependency analysis.

ARTIFACT 2: Dependency Map

# Feature Dependency Map - [Product Name]

> **Phase:** 5 - Feature Planning
> **Date:** [date]

---

## Dependency Rules

A feature is **blocked** if another feature must be complete before it can be built or tested.
A feature is a **blocker** if other features depend on it.

---

## Dependency Matrix

| Feature | Depends on | Blocks | Dependency type |
|---|---|---|---|
| [FEAT-BKG-011: Submit booking request] | [FEAT-LST-001: Create property listing] | [FEAT-BKG-012: Approve booking request] | Hard - cannot test without it |
| [FEAT-PAY-015: Process booking payment] | [FEAT-BKG-011, FEAT-BKG-012] | [FEAT-PAY-016: Issue refund] | Hard - payment depends on confirmed booking |
| [FEAT-NTF-020: Send booking confirmation] | [FEAT-BKG-012, FEAT-PAY-015] | None | Soft - can stub notification for testing |

---

## Critical Path

The longest sequence of hard dependencies that determines minimum delivery timeline.

[FEAT-LST-001] Create listing → [FEAT-BKG-011] Submit booking request → [FEAT-BKG-012] Approve booking request → [FEAT-PAY-015] Process payment → [FEAT-NTF-020] Send confirmation

**Critical path length:** [X features - estimated [Y] weeks]

---

## Parallelizable Tracks

| Track | Features | No dependency on |
|---|---|---|
| [Track A: Property management] | [FEAT-LST-001, FEAT-LST-002, FEAT-LST-003] | Track B, C |
| [Track B: Search] | [FEAT-SRC-010] | Track A (partial) |
| [Track C: Messaging] | [FEAT-MSG-030, FEAT-MSG-031] | Track A + B complete |

Step 4: Prioritize (offer, don't impose)

After the Dependency Map is approved. Do not auto-run KANO/V×C silently - prioritization is offered on a basis, consistent with the canonical engine pm-prioritize (per the Adaptive-execution standard in CLAUDE.md).

Use AskUserQuestion: "How should I prioritize this backlog?"

• Option A: "KANO + V×C (Recommended for a first greenfield pass)" - the default scoring; generate the two artifacts below
• Option B: "Align to the roadmap" (if one exists) - delegate to /pm-prioritize Option A
• Option C: "My directive / a specific lens" - delegate to /pm-prioritize (Options B/C)
• Option D: "You decide and propose" - delegate to /pm-prioritize Option D

If the user picks A, generate the KANO + V×C artifacts below. For B/C/D, run the pm-prioritize basis instead (KANO/V×C remains available as an input lens). Either way the result is a dependency-reconciled priority order on the feature list - the engine and its logic live in pm-prioritize; this step just offers it at creation time.

If the user is unsure: be the proactive partner - propose the most fitting basis with reasoning (e.g. "no roadmap yet and you're validating - KANO + V×C is the right first lens") and confirm.

ARTIFACT 3: KANO Analysis (when basis = KANO + V×C)

# KANO Analysis - [Product Name]

> **Phase:** 5 - Feature Planning
> **Date:** [date]

---

## KANO Categories

| Category | Definition | MVP implication |
|---|---|---|
| Must-be | Expected by default. Absence = dissatisfied. Presence is neutral. | Always in MVP |
| Performance | More = better. Linear satisfaction. | Prioritize highest-impact |
| Delighter | Unexpected. Delights when present. No dissatisfaction if absent. | Post-MVP unless very fast to build |
| Indifferent | Neither satisfied nor dissatisfied. | Cut or defer indefinitely |

---

## Feature KANO Classification

| Feature | KANO Category | Rationale |
|---|---|---|
| [FEAT-LST-001: Create property listing] | Must-be | Without this, hosts cannot use the product |
| [FEAT-SRC-010: Search available properties] | Must-be | Without this, guests cannot book |
| [FEAT-LST-006: Configure seasonal pricing] | Performance | Better pricing = more host revenue, but basic pricing works |
| [FEAT-LST-025: AI-generated listing description] | Delighter | Unexpected value-add |
| [FEAT-PAY-050: Multi-currency display] | Indifferent (for MVP market) | Single-market MVP |

---

## KANO Summary

| Category | Count | Notes |
|---|---|---|
| Must-be | [X] | All go into MVP |
| Performance | [X] | Highest-impact ones into MVP |
| Delighter | [X] | Post-MVP unless fast to build |
| Indifferent | [X] | Cut |

ARTIFACT 4: Value vs. Complexity Matrix

# Value vs. Complexity Matrix - [Product Name]

> **Phase:** 5 - Feature Planning
> **Date:** [date]
> **Purpose:** Determine delivery priority and sequencing

---

## Quadrants

| Quadrant | Value | Complexity | Action |
|---|---|---|---|
| Quick Win | High | Low | Do first |
| Big Bet | High | High | Plan carefully, phase |
| Fill-in | Low | Low | Only if fits naturally |
| Time Waster | Low | High | Cut |

---

## Feature Scoring

| Feature | Value (1-5) | Complexity (1-5) | Quadrant | Notion Priority |
|---|---|---|---|---|
| [FEAT-LST-001: Create property listing] | 5 | 3 | Big Bet | P1 - Critical |
| [FEAT-SRC-010: Search available properties] | 5 | 2 | Quick Win | P1 - Critical |
| [FEAT-LST-004: Set base nightly price] | 4 | 1 | Quick Win | P1 - Critical |
| [FEAT-LST-025: AI listing description] | 4 | 2 | Quick Win | P2 - High |
| [FEAT-LST-006: Configure seasonal pricing] | 3 | 2 | Fill-in | P3 - Medium |
| [FEAT-ANL-040: Analytics dashboard] | 2 | 4 | Time Waster | P4 - Low |

**Notion Priority mapping:**
- Must-be (KANO) → P1 - Critical
- Performance (KANO) + Quick Win (V×C) → P2 - High
- Performance (KANO) + Big Bet (V×C) → P2 - High
- Delighter + Fill-in → P3 - Medium
- Indifferent + Time Waster → P4 - Low

---

## Sequencing Signal

First in delivery: Quick Wins from Must-be category Then: Big Bets (high value, plan carefully) Later: Fill-ins alongside other work Cut: Time Wasters + Indifferent

Step 5: Create stub Feature Cards

Runs after user approves all four artifacts (Feature List, Dependency Map, KANO, V×C).

For every feature in the Feature List, create a stub Feature Card file at: pureinn-workspace/[project-slug]/features/cards/[FEAT-ID].md

Stub content (frontmatter only, sections as empty placeholders):

---
id: [FEAT-ID]
title: "[Action] [Result] [Object]"
status: 1_Backlog
stripe: TBD
feature_set: "FS-NN: [Feature Set name]"
layer: [one or more of frontend / backend / system - list all layers a cross-layer feature spans (e.g. "frontend, backend"), never "fullstack"]
phase: [MVP / MVP+ / Phase 1 / ...]
actor: [User / Host / Admin / System]
owner: unassigned
priority: [P1/P2/P3 from V×C]
kano: [Must-be / Performance / Delighter / Indifferent]
vxc: [Quick Win / Big Bet / Fill-in / Time Waster]
estimate: "[S / M / L - informational sizing, NOT the atomicity test]"
has_subtasks: false
security_review: none    # none | build | review | both - stub default; set by pm-feature-design (Step 1.5), read by pm-stripe to route security specialists
mutex_tags: []           # code modules/files this feature touches - drives delivery-plan CONTENTION. Empty at stub; set at JIT (pm-feature-design) or from code (pm-reverse-extract/pm-reconcile). Entry: "ModuleName" or {tag: X, reason: "why"}
override: false          # break-glass; {reason: "..."} forces a P0 ahead of capacity/priority/contention (never past a hard dependency)
dependencies: [FEAT-ID, FEAT-ID]   # from the Deps column above - [] if none. Entry may be a bare FEAT-ID or annotated {id: FEAT-ID, reason: "why"} for delivery-plan explainability
prd_ref: /product/PRD_master.md#[relevant-section]
feature_flag: [domain.feature-name]
flag_default: off
---

# Feature Card: {{title}}

## Description
[2-3 sentences - what this feature does, who uses it, the value. Mandatory for every card regardless of status - the team's orientation. Never blank.]

## 1. Biznis Mantinely (SDD Input)
*TBD - populated by /pm-feature-design [FEAT-ID]*

## 2. Acceptance Criteria
*TBD - populated by /pm-feature-design [FEAT-ID]*

### Edge Case Coverage
| Category | Coverage |
|---|---|
| EC-INPUT | TBD |
| EC-AUTH | TBD |
| EC-STATE | TBD |
| EC-CONC | TBD |
| EC-EXT | TBD |
| EC-CLIENT | TBD |

## Subtasks (helper notes)
*TBD - nuance helpers added during /pm-feature-design [FEAT-ID] or by the team*

## 3. JIT Technical Design (FDD Design)
*TBD - populated by /pm-feature-design [FEAT-ID]*

## 4. Realizacny Protokol (Build Verification)
*TBD - populated after build and Code Inspection*

After creating all stub cards: confirm count and remind user that:

• Stripe assignment happens in pm-mvp-scope (updates stripe: field in each card)
• JIT design (Sections 1-3) happens in pm-feature-design just before each feature enters build
• Feature flags follow format: [product-domain].[feature-name] (e.g., orders.draft-order)

Step 6: Notion push

Runs after stub Feature Cards are created.

If no Notion database is configured (state.json notion_ids.feature_backlog is null and user did not provide a URL in Step 1): skip this step, output Markdown files only.

5a. Get data source ID and template ID

1. Read pureinn-variables.md key "Feature Backlog" → get URL
2. Check state.json notion_ids.feature_backlog → if set, use it directly; otherwise call mcp__claude_ai_Notion__notion-fetch
3. From notion-fetch result: extract data_source_id from <data-source url="collection://...">, save to state.json
4. From notion-fetch result: find <templates> section, extract ID of template named "Feature Card Template" - this is required for Step 5b

6b. Push Feature entries

Call mcp__claude_ai_Notion__notion-create-pages with:

• parent.type = "data_source_id"
• parent.data_source_id = ID from 5a

Per entry - use both properties AND content. Do NOT use template_id:

properties:
  Artefact Name: FEAT-[DOMAIN]-[NUMBER]: [Feature Name]
  Artefact Type: Feature
  FEAT-ID: FEAT-[DOMAIN]-[NUMBER]
  Short Description: [1-sentence description]
  Status: 1_Backlog
  Layer: [one or more of Frontend / Backend / System - multi-select; never "fullstack"]
  Phase: [MVP / MVP+ / Phase 1 / ...]
  Priority: [P1 - Critical / P2 - High / P3 - Medium / P4 - Low]
  KANO Category: [Must-be / Performance / Delighter / Indifferent]
  V×C Quadrant: [Quick Win / Big Bet / Fill-in / Time Waster]
  Dev Stripe: [Dev Stripe N if pm-mvp-scope already ran / "TBD" otherwise - same value as the Stripe column]
  Has Subtasks: [true / false]
  Dependencies: [rich_text - comma-separated FEAT-IDs from the Deps column, or "none"]

content:
  ## [Feature Name]

  [1-2 sentence description of what this feature does and who uses it]

  **KANO:** [Must-be / Performance / Delighter / Indifferent]
  **V×C:** [Quick Win / Big Bet / Fill-in / Time Waster]

  ---

  ## 1. Biznis Mantinely (SDD Input)
  *TBD - populated by /pm-feature-design [FEAT-ID]*

  ## 2. Acceptance Criteria
  *TBD - populated by /pm-feature-design [FEAT-ID]*

  ### Edge Case Coverage
  | Category | Coverage |
  |---|---|
  | EC-INPUT | TBD |
  | EC-AUTH | TBD |
  | EC-STATE | TBD |
  | EC-CONC | TBD |
  | EC-EXT | TBD |
  | EC-CLIENT | TBD |

  ## Subtasks (helper notes)
  *TBD - nuance helpers added during /pm-feature-design [FEAT-ID] or by the team*

  ## 3. JIT Technical Design (FDD Design)
  *TBD - populated by /pm-feature-design [FEAT-ID]*

  ## 4. Realizacny Protokol (Build Verification)
  *TBD - populated after build and Code Inspection*

Push features in batches of up to 100 per call if the list is large.

6c. Confirm

After push: report how many entries were created, how many stub Feature Cards were written locally, and surface any errors. Remind the user that MVP cut, stripe assignment, and Domain / Feature Set grouping will be finalized after pm-mvp-scope.

Internal completeness checklist

Feature naming must comply with FDD:

• Every feature follows action + result + object format
• No feature named as a capability ("messaging system", "admin panel")
• Features are discrete actions, not multi-step processes

Feature granularity:

• Each feature is one coherent client-valued function with one result (semantic atomicity test - not time-based)
• Features with two independent results are flagged for splitting; nuances captured as Subtasks, not splits

Coverage:

• All in-scope functional areas from PRD have features
• All user roles have features assigned
• System-automated features included (notifications, scheduled jobs, payments)
• Admin/back-office features included

Dependency Map:

• All hard dependencies identified
• Critical path identified
• Parallelizable tracks identified
• No circular dependencies
• Every feature's Deps column value mirrored into its Feature Card frontmatter dependencies: field and into the Notion Dependencies property - same data, three places, never only in the Dependency Map doc

KANO:

• Every feature classified
• Classification rationale stated
• All Must-be features are in MVP

V×C Matrix:

• Every feature scored on Value (1-5) and Complexity (1-5)
• Quadrant assigned
• Notion Priority assigned per mapping

For SaaS/AI products:

• AI features named correctly (e.g., "Generate listing description draft", not "AI module")
• Onboarding features included
• Billing and subscription management features included (if paid)
• Settings and configuration features included
• Data export / account deletion features included (GDPR)
• Notification features included per channel
• API/webhook features included if integrations are in scope

Save to

Create mode (first run - Greenfield):

pureinn-workspace/[project-slug]/features/feature_list.md          (Live Register 4 - created)
pureinn-workspace/[project-slug]/features/cards/FEAT-[DOMAIN]-[NUMBER].md  (one stub per feature)
pureinn-workspace/[project-slug]/artifacts/phase-5-planning/feature-dependency-map.md
pureinn-workspace/[project-slug]/artifacts/phase-5-planning/kano-analysis.md
pureinn-workspace/[project-slug]/artifacts/phase-5-planning/value-complexity-matrix.md

FI Append mode (new initiative):

pureinn-workspace/[project-slug]/features/feature_list.md          (APPENDED - new domain section added)
pureinn-workspace/[project-slug]/features/cards/FEAT-[NEW-DOMAIN]-[NUMBER].md  (stub cards for new features only)
pureinn-workspace/[project-slug]/initiatives/[slug]/kano-analysis.md  (initiative-scoped KANO)
pureinn-workspace/[project-slug]/initiatives/[slug]/value-complexity-matrix.md  (initiative-scoped V×C)

FI Append rules:

• Existing FEAT-* entries in feature_list.md are not modified, renumbered, or removed
• New initiative features are appended as a new Domain section at the bottom
• Stub Feature Cards created only for new FEAT-[NEW-DOMAIN]-* features
• KANO + V×C saved to initiative folder (not overwriting master phase-5/ analysis)
• Dependency map section in feature_list.md updated with cross-initiative dependencies (if any)

Re-check mode (post-research re-prioritization):

When re-run with new personas or market analysis to re-check KANO/VxC/phase:

1. Do NOT rewrite feature_list.md in full - show only proposed changes in diff format: FEAT-ID | field | current value → proposed value | reason (from research)
2. Wait for user approval of the diff before writing any changes
3. After approval: update feature_list.md for approved changes only
4. Feature Card frontmatter sync (mandatory after any KANO/VxC/phase change):
   • For each FEAT-ID where kano, vxc, phase, or priority changed: update the corresponding frontmatter field in /features/cards/FEAT-[ID].md
   • Do NOT touch Section 1, 2, 3, or 4 - spec content is defined by domain logic, not prioritization
   • Cards at 6_Shipped status: update kano/vxc/phase in frontmatter only (Section 4 remains immutable)
5. Report: N features re-classified, N Feature Cards frontmatter synced

Handoff

Čo si teraz má: feature_list.md (Live Register 4) - prioritizovaný feature inventory s FEAT-IDs, KANO + V×C, dependency map a stub Feature Cards.

Ďalší krok: /pm-mvp-scope — rozhodni IN/POST-MVP/CUT per feature a prirad ich do Delivery Stripes.

Môžeš preskočiť ak: Ide o existujúci produkt - vtedy MVP cut a stripes rieši /pm-reverse-extract (migrácia), nie tento flow.