mcpField
F
feature-forge

feature-forge

github.com/jeffallanDevelopment12.1k4.3k installsUpdated today
Repository

About feature-forge

feature-forge is a requirements specification skill for teams defining new features. It uses structured discovery from product and engineering perspectives, then produces EARS requirements, testable acceptance criteria, and an implementation checklist.

Key features

  1. 01Structured stakeholder interviews
  2. 02Product and engineering perspectives
  3. 03EARS-format requirements
  4. 04Testable acceptance criteria
  5. 05Implementation TODO checklist

Use cases

  1. 01Defining a new feature's scope
  2. 02Gathering requirements across domains
  3. 03Documenting functional and non-functional needs
  4. 04Preparing implementation plans

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/jeffallan/claude-skills --skill feature-forge

After installing, type/feature-forgein Claude Code to confirm it loaded.

Bundled files

References and scripts installed along with SKILL.md.

references/
acceptance-criteria.md
ears-syntax.md
interview-questions.md
pre-discovery-subagents.md
specification-template.md

Details

From the project README

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

  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:

TopicReferenceLoad When
EARS Syntaxreferences/ears-syntax.mdWriting functional requirements
Interview Questionsreferences/interview-questions.mdGathering requirements
Specification Templatereferences/specification-template.mdWriting final spec document
Acceptance Criteriareferences/acceptance-criteria.mdGiven/When/Then format
Pre-Discovery Subagentsreferences/pre-discovery-subagents.mdMulti-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:

  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

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

Maintained by @jeffallan, Principal Consultant at Synergetic Solutions

Documentation

Comments

Markdown supported