Feature forge

Skill Jeffallan/claude-skills/skills/feature-forge

Conducts structured requirements workshops to produce feature specifications, user stories, EARS-format functional requirements, acceptance criteria, and implementation checklists. Use when defining new features, gathering requirements, or writing specifications. Invoke for feature definition, requirements gathering, user stories, EARS format specs, PRDs, acceptance criteria, or requirement matrices.From its SKILL.md

Install

npx -y skills add Jeffallan/claude-skills --skill feature-forge

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

What its file declares

Copied from the file, not written here

The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

4.2 KB, 726 tokens by cl100k_base, as published. Nobody here has run it

Feature Forge

Requirements specialist conducting structured workshops to define comprehensive feature specifications.

Role Definition

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

Discover - Use AskUserQuestions to understand the feature goal, target users, and user value. Present structured choices where possible (e.g., user types, priority level).
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).
Document - Write EARS-format requirements
Validate - Use AskUserQuestions to review acceptance criteria with stakeholder, presenting key trade-offs as structured choices
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
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

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 (performance, security)
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:

Overview and user value
Functional requirements (EARS format)
Non-functional requirements
Acceptance criteria (Given/When/Then)
Error handling table
Implementation TODO checklist

Inline EARS format examples (load references/ears-syntax.md for full syntax):

When <trigger>, the <system> shall <response>.
Where <feature> is active, the <system> shall <behaviour>.
The <system> shall <action> within <measure>.

Inline acceptance criteria example (load references/acceptance-criteria.md for full format):

Given a registered user is on the login page,
When they submit valid credentials,
Then they are redirected to the dashboard within 2 seconds.

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

Documentation

What ships with it: 5 files

15.5 KB alongside SKILL.md

references/

Gives 1 of the 12 instructions most product spec skills give in 726 tokens

Counted across 483 of the 502 authors here whose files we hold, read 2026-09-06

Write the PRD using the templatein 39 of 483, across 36 files
Ask one question at a timein 24 of 483
Write acceptance criteria in Given-When-Then formatin 24 of 483
Write user stories with acceptance criteriain 22 of 483, across 21 files
Respect ADRs in areas you touchin 21 of 483, across 17 files
Use the domain glossary vocabulary throughout the PRDin 20 of 483, across 16 files
Explore the repo to understand the current codebasein 19 of 483, across 15 files
Provide testable acceptance criteriahere, and in 19 of 483, across 17 files
Publish the PRD to the issue trackerin 18 of 483, across 14 files
Apply the ready-for-agent triage labelin 15 of 483, across 13 files
Prefer existing seams over new onesin 14 of 483, across 12 files
Save the PRD as a markdown filein 14 of 483, across 9 files

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.