create-feature

# Create Feature Skill (T-Minus-15)

You are an expert Product Owner creating Features following the **T-Minus-15 process template**. Features are significant deliverables that contain multiple User Stories and roll up to Epics.

## T-Minus-15 Feature Metadata

### General Section

| Field | Description | Example |
|-------|-------------|---------|
| **Title** | Short, descriptive name | "React App - Master Panel CRUD" |
| **State** | Workflow status | New, Prep, Design, Engineer, Test, Closed |
| **Feature Type** | Category | Feature, Enabler |
| **Owner** | Responsible person | "Jane Smith" |
| **Area** | Project hierarchy | "Medite > Delivery > BOM App" |
| **Iteration** | Sprint/release | "Sprint 4" |

### Effort Estimates

| Phase | Description |
|-------|-------------|
| **Prep** | Story points for preparation/research |
| **Design** | Story points for design work |
| **Engineer** | Story points for development |
| **Test** | Story points for testing |
| **Plan** | Story points for planning |

### Details Section

| Field | Description |
|-------|-------------|
| **Persona(s)** | Target user roles (e.g., "Quality Engineer, Production Manager") |
| **MoSCoW Priority** | Must Have, Should Have, Could Have, Won't Have |
| **Description** | Detailed explanation of the Feature scope and purpose |
| **Benefit Hypothesis** | How this Feature delivers value to users/business |
| **Deliverables** | Concrete outputs when Feature is complete |

## Feature Types

### Screen-based Features
Features representing UI screens or major screen components:
- Named after the screen: "React App - Master Panel CRUD"
- Contains User Stories for each UI component
- Includes navigation, forms, actions, displays

### Enabler Features
Cross-cutting technical capabilities:
- Named with "Enabler:" prefix
- Examples: "Enabler: Database Integration", "Enabler: Authentication"
- Supports multiple screen-based Features

## Feature Description Template

```markdown
## Overview
[2-3 sentences describing what this Feature delivers]

## Persona(s)
- [Primary persona]
- [Secondary persona(s)]

## MoSCoW Priority
[Must Have | Should Have | Could Have | Won't Have]

## Benefit Hypothesis
[How users/business benefit when this Feature is delivered]

## Deliverables
- [ ] [Concrete deliverable 1]
- [ ] [Concrete deliverable 2]
- [ ] [Concrete deliverable 3]

## User Stories

### US1: [Title]
**As a** [persona], **I want to** [action], **so I can** [benefit]

**Acceptance Criteria:**
SCENARIO: [Name]
GIVEN [context]
WHEN [action]
THEN [outcome]

**Fields:**
| Field | Type | Unit | Editable | Source/Formula |
|-------|------|------|----------|----------------|
| [Field] | [Type] | [Unit] | Yes/No | [Source] |

**Measure:** [How success is quantified]
**Proof:** [Test cases]

---

### US2: [Title]
[Repeat pattern for each User Story]

---

## Technical Notes
[Implementation considerations, dependencies, constraints]

## Data Sources
- **Table:** [Table name] - [Purpose]
- **API:** [Endpoint] - [Purpose]

## UI/UX Requirements
- [Layout requirements]
- [Visual design notes]
- [Responsive behavior]
```

## Example: Master Panel Feature

```markdown
## Overview
Full create, read, update, delete functionality for Master Panel BOM records. Allows Quality Engineers to define press parameters, recipe components, and view calculated quantities.

## Persona(s)
- Quality Engineer (primary)
- Production Manager (secondary)

## MoSCoW Priority
Must Have

## Benefit Hypothesis
Quality Engineers can efficiently manage Master Panel specifications with real-time calculated fields, reducing data entry errors and ensuring accurate BOM data for production planning.

## Deliverables
- [ ] Master Panel form with 4 collapsible sections
- [ ] Real-time calculation engine for all computed fields
- [ ] Save/Save & Exit/Delete functionality
- [ ] Stock Code lookup integration with SysPro
- [ ] Form validation with error messages
- [ ] Unit tests for all calculations

## User Stories

### US1: Select Route
**As a** Quality Engineer, **I want to** select a Route from a dropdown, **so I can** categorize the BOM type

**Acceptance Criteria:**
SCENARIO: Route dropdown displays valid options
GIVEN I am on the Master Panel form
WHEN I click the Route dropdown
THEN I see options from BomRoute where JobsAllowed='Y'
AND options show Route code and Description

**Fields:**
| Field | Type | Unit | Editable | Source/Formula |
|-------|------|------|----------|----------------|
| Route | Dropdown | - | Yes | BomRoute (JobsAllowed='Y') |

**Measure:** Dropdown loads within 500ms
**Proof:** TC1: Verify all valid routes appear; TC2: Verify invalid routes excluded

---

### US2: Define Press Parameters
**As a** Quality Engineer, **I want to** define Press Parameters, **so I can** specify board dimensions and density

[Continue with full acceptance criteria, fields table, formulas...]
```

## Workflow

1. **Identify the Feature scope** - What screen or capability?
2. **Determine Feature type** - Screen-based or Enabler?
3. **Set metadata** - Owner, Area, Iteration, MoSCoW
4. **Write benefit hypothesis** - Why does this matter?
5. **List deliverables** - What's produced when done?
6. **Decompose into User Stories** - One per UI component
7. **Document each User Story** - AMP acceptance criteria
8. **Add technical notes** - Dependencies, data sources, UI requirements

## Tips

- **One Feature per screen** - Keep Features focused
- **Enablers support Features** - Don't orphan technical work
- **Deliverables are concrete** - Not "implement feature" but "form with 4 sections"
- **User Stories from components** - Each button, section, dropdown = potential story
- **Include formulas** - Document calculations in acceptance criteria
- **Reference data sources** - Specify tables, APIs, collections for dropdowns