PM - Feature Card

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.

Artifact language

Checks state.json → artifact_language. Default (unset or "English"): no change in behavior.

• If set to a non-English language: write the card's prose (feature description, acceptance criteria narrative, rationale in Sections 1-4) in that language.
• Never translate: FEAT-ID, BR-ID/TBL-ID references, frontmatter keys and enum values (status: 4_In_Build, layer:, priority:...), section headers (## Section 1 - Business Constraints, etc.), file names - these stay English always, regardless of the setting.

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

Manages Feature Cards in the FDD+SDD framework. A Feature Card is the atomic delivery unit - one card per feature, progressing through a defined lifecycle from initial walkthrough to immutable post-build history.

Card lifecycle:

2b_In_Design is optional and layer-gated. Only a feature whose layer includes frontend passes through it (it has a UI to design in Figma). A pure backend / system feature goes straight 2_Spec_Done → 3_Ready_to_Build - it has nothing to design. So the path is:

• frontend feature: 2_Spec_Done → 2b_In_Design → 3_Ready_to_Build
• backend / system feature: 2_Spec_Done → 3_Ready_to_Build (skips design)

This skill handles:

• Creating stub Feature Cards manually (when not created by pm-features-list)
• Reviewing Feature Card completeness at any status
• Advancing status after human confirmation
• Creating the card template reference

Section ownership:

• Frontmatter: pm-features-list (init) + pm-mvp-scope (stripe assignment) + pm-feature-design (status updates)
• promoted_from: and the prototype reference block: pm-prototype only - see "Prototype provenance" below. This skill preserves them and never writes them
• Section 1 (Biznis Mantinely): pm-feature-design
• Section 2 (Acceptance Criteria): pm-feature-design
• Section 3 (JIT Technical Design): pm-feature-design
• Section 4 (Realizacny Protokol): pm-stripe (after build)

Dependencies

Required before creating a stub:

• Feature must exist in features/feature_list.md

Required before Sections 1-3 are complete:

• pm-entity-registry - entities.md must exist
• pm-business-rules-library - business_rules.md and decision_models.md must exist
• pm-feature-design - JIT design skill that populates Sections 1-3

Produces artifacts used by:

• pm-feature-design - reads stub, populates Sections 1-3
• Build skills - read completed Feature Card as implementation spec
• pm-stripe - Impact Analysis reads BR-IDs in Section 1

Step 0: Current state check

Check for existing Feature Card at /features/cards/[FEAT-ID].md.

Verdict: [One sentence - what stage the card is in, what is next]

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 (if creating manually)

Used when creating a card that was not auto-created by pm-features-list.

Creating Feature Card for: [FEAT-ID]

1. FEATURE REFERENCE
   Feature ID: [FEAT-ID]
   Feature title (FDD format): "[Action] [Result] [Object]"
   Feature Set: [FS-NN: Name]
   From feature_list.md: [confirm feature exists]

2. STRIPE ASSIGNMENT
   Assigned stripe: [stripe-name]
   Priority: [P1 / P2 / P3]
   Dependencies: [FEAT-IDs this depends on, or "none"]

3. PRD REFERENCE
   Which section of PRD covers this feature's business capability?
   [/product/PRD_master.md#section or /product/PRD_[Domain].md#section]

4. FEATURE FLAG
   Flag name (format: domain.feature-name): [name]
   Default: OFF (mandatory in pureinn)

Feature Card Template

This is the canonical template for all Feature Cards in the FDD+SDD framework.

---
id: FEAT-[DOMAIN]-[NUMBER]
title: "[Action] [Result] [Object]"
status: 1_Backlog
stripe: [stripe-name]
feature_set: "FS-NN: [Feature Set name]"
layer: [one or more of frontend / backend / system - e.g. "backend" or "frontend, backend" for a genuinely cross-layer feature. NEVER "fullstack" - that is not a layer, list the actual layers]
phase: [MVP / MVP+ / Phase 1 / ... or a project's P0 / P1 - the SINGLE axis for MVP membership; IN-MVP = the first / MVP / P0 phase. Never a separate mvp flag]
actor: [User / Host / Admin / System]
owner: unassigned
priority: P1
kano: [Must-be / Performance / Delighter / Indifferent]
vxc: [Quick Win / Big Bet / Fill-in / Time Waster]
estimate: "[S / M / L - informational sizing for roadmap, NOT the atomicity test]"
has_subtasks: false
security_review: none    # none | build | review | both - set by pm-feature-design (Step 1.5 security dimension). Routes secure-code-guardian (build) + security-reviewer (review) in pm-stripe. Stub default: none.
test_types: [unit]       # unit | integration | contract | visual_regression | performance - set by pm-feature-design (Step 1.5 test type dimension). Specializes test-master routing + Build Skills Coverage check in pm-stripe. unit is the baseline stub default.
mutex_tags: []           # code modules/files this feature touches - drives delivery-plan CONTENTION (two features sharing a tag can't run parallel). Set at JIT by pm-feature-design (or from real code by pm-reverse-extract/pm-reconcile). Entry: "ModuleName" or {tag: X, reason: "why"}. Empty at stub.
override: false          # break-glass. Set to {reason: "..."} to force a P0 ahead of capacity/priority/contention in the delivery plan (never past a HARD dependency - that's physics). Shown loudly in the plan rationale.
prd_ref: /product/PRD_master.md#[section]
feature_flag: [domain.feature-name]
flag_default: off
---

# Feature Card: {{title}}

---

## Description

[2-3 clear, genuinely orientational sentences - what this feature does, who uses it, and the value/role it delivers. NOT a one-liner restating the title. **MANDATORY for every card regardless of status** (even `1_Backlog` and `6_Shipped`) - this is what a teammate reads first. Never blank or trivial.]

---

## 1. Biznis Mantinely (SDD Input)

*Populated by pm-feature-design (JIT). Links to live registers as source of truth.*

**Rules enforced in this feature:**

| Rule ID | Rule | Priority | Enforcement point |
|---|---|---|---|
| [BR-XXX-001](/domain/business_rules.md#br-xxx-001) | [Rule name: one-line summary] | [Critical/High/Medium] | [Service method / middleware / DB constraint] |

**Entity guard conditions (from entities.md):**

| Entity | Transition | Guard condition |
|---|---|---|
| [Entity Name](/domain/entities.md#entity-name) | [State before] → [State after] | [exact guard expression] |

**Decision model:** [TBL-XXX-01](/domain/decision_models.md#tbl-xxx-01) - [Table name, if applicable]

**What this feature does NOT do:**
- [explicit scope exclusion]

---

## 2. Acceptance Criteria

*Derived from register state + business rules by pm-feature-design. Used for human Black-box testing.*

### AC-01: [Happy Path Name]
- **Given** [precondition: entity state, actor]
- **When** [action]
- **Then** [observable outcome: state change, event emitted, user signal]
  - **And** [secondary outcome]

### AC-02: [EC-XXX] [Edge Case Name] (enforces [BR-ID] if applicable)
- **Given** [precondition]
- **When** [invalid condition]
- **Then** [system blocks, entity unchanged, error signal]

### AC-03: Feature Flag OFF
- **Given** flag `[feature_flag]` is OFF
- **When** [same trigger as AC-01]
- **Then** [existing behavior unchanged / feature hidden]

### Edge Case Coverage
*Resolved by pm-feature-design Step 1.5 - each cell becomes AC-NN, `N/A - <feature-specific reason>`, or `OQ-[DOMAIN]-NN`. An index, not a description. No empty or TBD cell from 3_Ready_to_Build on.*

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

---

## Subtasks (helper notes)

*Lightweight nuance / spec helpers for the developer - NOT deliverables, NOT sub-features, they never break the feature's atomicity. Added during pm-feature-design discovery, by the team while writing the card, or folded from too-granular legacy features by pm-reconcile. A subtask that hardens into a testable condition becomes an AC; one that becomes reusable non-negotiable logic becomes a business rule (BR-ID).*

- [ ] [nuance / spec detail - e.g. "reset link expires in 15 min", "reuse existing EmailService", "show skeleton loader while fetching"]

> **Subtask-count signal:** more than ~6-8 subtasks on one card is usually not a detail-rich feature - it is an under-split feature wearing one FEAT-ID. Re-run the atomicity test from `pm-features-list` (one coherent result?) before adding more subtasks; if it fails, split the feature instead of growing the list.

---

## 3. JIT Technical Design (FDD Design)

*Populated by pm-feature-design just before build. Approved during Design Inspection.*

### Data flow and object interaction

```mermaid
sequenceDiagram
    %% Generated by pm-feature-design
    %% [FEAT-ID]: [title]

Files to modify

• [TBD - populated by pm-feature-design]

4. Realizacny Protokol (Build Verification)

Populated after successful build and Code Inspection. After 6_Shipped: immutable.

• Production code commits:
  • [feat: description](commit_hash_link)
• Test files:
  • tests/unit/[ServiceName]_[FEAT-ID]_spec.[ext]
• Feature flag OFF verification: [yes / no]
• Edge case test mapping: (every AC in the Edge Case Coverage table)
  • AC-NN → [test file path]
• Code Inspection: [Approved by [reviewer] on YYYY-MM-DD / AI guardrail passed on YYYY-MM-DD]

---

## Prototype provenance (written by pm-prototype - preserve)

Two optional elements can appear on a card. Neither is part of the stub template, **both are written only by `/pm-prototype`**, and this skill must carry them through every operation - review, status advance, manual re-creation, Notion push - unchanged.

**1. `promoted_from:` - optional frontmatter field**

```yaml
promoted_from: PRT-[NAME]-NNN   # optional. Written by pm-prototype at promotion. The prototype feature this card was promoted from.

Present only on a card that started as a prototype feature and was promoted (pm-prototype Step 8, its references/promotion.md). The value is a prototype feature ID from prototypes/[prototype-name]/feature-plan-prt.md. The card's own id: is always a real FEAT-ID - a PRT- ID never appears as id:, in a file name, in feature_list.md, or in a dependency. promoted_from: is the one place on a production card where a PRT- ID is legitimate.

2. Prototype reference block - lightweight note, outside Sections 1-4

Prototype: [/prototypes/[prototype-name]/ or /prototypes/[FEAT-ID]-prototype-spec.md]
Prototype URL: [live/preview URL, local harness URL, or "pending build"]
Audience: [who the prototype is for]
Expected outcome: [the success criterion, written before any result]
Result: pending

Written by pm-prototype Step 7 when a feature already in the plan gets a prototype. Result: starts as pending and is later updated by pm-prototype (result mode) to one of its four verdict states: Supported within scope, Refuted within scope, Prototype or study failure, Inconclusive.

What this skill does with them:

• Never writes, edits, moves or removes either one. Not when creating a card manually (a manually created card has no prototype provenance - do not add an empty field or an empty block), not when advancing status, not when normalizing a card to the template. A card that carries them and is missing from the template is not drift.
• Never fills Result:. A verdict comes from /pm-prototype, against the threshold written in Expected outcome. Do not infer it from the conversation.
• Reports them in Step 0. Result: pending means the card says a prototype result is still expected before build - say so and route to /pm-prototype. Refuted within scope on a card heading into design or build is flagged the same way.
• Does not check them for truth. Whether the PRT- ID or the prototype folder still exists is pm-audit's check; what the prototype resolved and what the production spec changes against it is recorded by pm-feature-design (Section 3, ### Prototype carry-over).
• Labels stay English under any artifact_language: promoted_from, the five labels of the block, and the Result: values are read literally by other skills.

Notion push

Runs after Feature Card Section 4 is complete (status: 6_Shipped).

Read pureinn-variables.md key "Feature Backlog" → get DB URL. Find the existing Feature entry for this FEAT-ID.

Update the Feature entry via notion-update-page:

Push Feature Card content as the Notion page body.

If Feature Backlog URL is blank in pureinn-variables.md: save locally, remind user to update Notion manually.

Internal completeness checklist

Stub (1_Backlog) must have:

• All frontmatter fields populated (id, title, status, stripe, owner, priority, prd_ref, feature_flag, flag_default; security_review: none placeholder; test_types: [unit] placeholder)
• Sections 1-4 present as stubs (not filled); Section 2 carries the Edge Case Coverage table with 6 TBD rows

Prototype provenance (any status):

• promoted_from: and the prototype reference block, if present, are unchanged - never added, edited, or dropped by this skill

After pm-feature-design (2_Spec_Done) must have:

• security_review set from the Step 1.5 assessment (no longer the none stub default unless genuinely no trigger met)
• test_types set from the Step 1.5 assessment (beyond the [unit] stub default where a trigger was met)
• Section 1: entity, state before/after, BR-IDs linked
• Section 2: happy path AC + flag OFF AC, all in Given/When/Then; Edge Case Coverage table with all 6 categories resolved (AC-NN / N/A with feature-specific reason / OQ-ID), edge case ACs tagged [EC-XXX]
• Section 3: mermaid sequenceDiagram (not empty), files to modify listed

After build (6_Shipped) must have:

• Section 4: at least one commit link, at least one test file path
• Section 4: flag OFF verification stated
• Section 4: every edge case AC from the coverage table mapped to a test file
• Section 4: Code Inspection result with date
• Status: 6_Shipped

Save to

pureinn-workspace/[project-slug]/features/cards/[FEAT-ID].md

Handoff

Čo si teraz má: Feature Card podľa kanonickej šablóny (frontmatter + sekcie 1-4) - štruktúra pripravená na JIT dizajn.

Ďalší krok: /pm-feature-design [FEAT-ID] — napĺňa sekcie 1-3 (Biznis Mantinely, ACs, sequence diagram) tesne pred buildom.

Môžeš preskočiť ak: Kartu vytvára automaticky /pm-features-list alebo /pm-reverse-extract - samostatne ju spúšťaj len keď chceš šablónu/referenciu.