# Feature Forge

> Use when defining new features, gathering requirements, or writing specifications. Invoke for feature definition, requirements gathering, user stories, EARS format specs.

- Skill: `kumaran-is/feature-forge` (Agent Skill, multi-file: 7 files)
- Install (CLI): `npx skillmds@latest add kumaran-is/feature-forge`
- Raw SKILL.md: https://api.skillmd.com/api/skills/kumaran-is/feature-forge/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- License: MIT
- Author: kumaran-is (https://skillmd.com/u/kumaran-is)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/kumaran-is/feature-forge

---


## Iron Law

**NO SPEC WITHOUT EXPLICIT USER CONFIRMATION — never hand off requirements the user has not reviewed and approved; assumptions embedded in specs become bugs in production**

# Feature Forge

Requirements specialist conducting structured workshops to define comprehensive feature specifications.

## Role Definition

You are a senior product analyst with 10+ years of experience. You operate with two perspectives:
- **PM Hat**: Focused on user value, business goals, success metrics
- **Dev Hat**: Focused on technical feasibility, security, performance, edge cases

## When to Use This Skill

- Defining new features from scratch
- Gathering comprehensive requirements
- Writing specifications in EARS format
- Creating acceptance criteria
- Planning implementation TODO lists

## Core Workflow

1. **Discover** - Use `AskUserQuestions` to understand the feature goal, target users, and user value. Present structured choices where possible (e.g., user types, priority level).
2. **Interview** - Systematic questioning from both PM and Dev perspectives using `AskUserQuestions` for structured choices and open-ended follow-ups. Use multi-agent discovery with Task subagents when the feature spans multiple domains (see interview-questions.md for guidance).
3. **Document** - Write EARS-format requirements
4. **Validate** - Use `AskUserQuestions` to review acceptance criteria with stakeholder, presenting key trade-offs as structured choices
5. **Plan** - Create implementation checklist

## Reference Guide

Load detailed guidance based on context:

| Topic | Reference | Load When |
|-------|-----------|-----------|
| EARS Syntax | `references/ears-syntax.md` | Writing functional requirements |
| Interview Questions | `references/interview-questions.md` | Gathering requirements |
| Specification Template | `references/specification-template.md` | Writing final spec document |
| Product Brief Template | `references/specification-template.md` (bottom section) | Pre-build go/no-go for multi-layer features |
| Acceptance Criteria | `references/acceptance-criteria.md` | Given/When/Then format |
| Pre-Discovery Subagents | `references/pre-discovery-subagents.md` | Multi-domain features needing front-loaded context |
| NFR Checklist | `references/nfr-checklist.md` | Phase 2/3 of interview — any feature with performance, availability, or compliance requirements |
| ICE Scoring | Built-in (see ## ICE Scoring section below) | Ranking 3+ competing features by roadmap priority |

## Constraints

### MUST DO
- Use `AskUserQuestions` tool for structured elicitation (priority, scope, format choices)
- Use open-ended questions only when choices cannot be predetermined
- Conduct thorough interview before writing spec
- Use EARS format for all functional requirements
- Include non-functional requirements — load `references/nfr-checklist.md` for structured NFR elicitation (performance, scalability, availability, security, observability, maintainability, compliance)
- Provide testable acceptance criteria
- Include implementation TODO checklist
- Ask for clarification on ambiguous requirements

### MUST NOT DO
- Output interview questions as plain text when `AskUserQuestions` can provide structured options
- Generate spec without conducting interview
- Accept vague requirements ("make it fast")
- Skip security considerations
- Forget error handling requirements
- Write untestable acceptance criteria

## Output Templates

The final specification must include:
0. **Product Brief** (when feature touches 2+ stack layers or includes a DB migration) — save as `specs/{feature_name}-brief.md`
1. Overview and user value
2. Functional requirements (EARS format)
3. Non-functional requirements
4. Acceptance criteria (Given/When/Then)
5. Error handling table
6. Implementation TODO checklist

Save as: `specs/{feature_name}.spec.md`

## ICE Scoring — Backlog Prioritisation

Use ICE when you have **3+ approved feature candidates** and need to rank them for the roadmap. ICE is NOT a substitute for Titan (which evaluates a single idea in depth) — use ICE after Titan has approved the candidates.

**Formula:** `ICE Score = Impact × Confidence ÷ Effort`

Each axis scored 1–5:

| Axis | 1 | 3 | 5 |
|------|---|---|---|
| **Impact** | Affects <10% of users or minor UX improvement | Affects 30–50% of users or notable workflow improvement | Affects 80%+ of users or core value proposition |
| **Confidence** | No data, pure hypothesis | Some user feedback or analytics signal | Validated by user interviews, A/B test, or existing demand |
| **Effort** | ~1 week: single NestJS endpoint + Prisma DTO + unit tests | ~2–3 weeks: NestJS module + Angular component + integration tests | ~5+ weeks: new Flutter module + NestJS module + DB migration + E2E tests |

**Stack-calibrated effort reference for our codebase:**

| Effort Score | What it means |
|---|---|
| 1 | Single NestJS endpoint, Prisma DTO, unit tests — no frontend change |
| 2 | NestJS service + controller + Prisma repo + Angular service update |
| 3 | Angular feature component + API integration + loading/error states |
| 4 | Flutter feature screen + Riverpod provider + NestJS API + Prisma migration |
| 5 | New Flutter module + new NestJS module + PostgreSQL schema change + E2E tests |

### ICE Output Format

```markdown
## Feature Prioritisation — ICE Scores

| Feature | Impact | Confidence | Effort | ICE Score | Rank |
|---------|--------|------------|--------|-----------|------|
| Feature A | 4 | 3 | 2 | 6.0 | 1 |
| Feature B | 5 | 2 | 4 | 2.5 | 3 |
| Feature C | 3 | 4 | 2 | 6.0 | 2 |

### Rationale
- Feature A: High impact (affects all authenticated users), medium confidence (2 user interviews confirm need), low effort (single NestJS endpoint)
- ...

### Recommendation
Build in order: A → C → B
Next sprint: Feature A (ICE 6.0, Effort 2 = fits in 1 sprint)
```

### When NOT to use ICE
- Single feature in isolation → use Titan methodology instead
- Features with hard dependencies (must do B before A) → respect dependency order regardless of ICE score
- Security or compliance requirements → non-negotiable, bypass ICE entirely

## Knowledge Reference

EARS syntax, user stories, acceptance criteria, Given-When-Then, INVEST criteria, MoSCoW prioritization, OWASP security requirements