feature-forge

Define structured feature specifications with EARS requirements and Given/When/Then acceptance criteria.

Updated Mar 17, 2026
One-click install
npx skills add https://github.com/Estom/aiflex --skill feature-forge-estom
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: feature-forge
Source: https://github.com/Estom/aiflex/tree/main/skills-repo/Jeffallan-skills/feature-forge
Command: npx skills add https://github.com/Estom/aiflex --skill feature-forge-estom

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

Feature Forge eliminates ambiguous feature definitions by guiding structured discovery and producing clear, testable specifications so teams can build with shared understanding and measurable acceptance criteria.

Core Features & Use Cases

  • Structured Elicitation: Conducts PM- and Dev-oriented interviews with a mix of open-ended prompts and structured choices to surface requirements, priorities, and constraints.
  • EARS-format Requirements: Produces functional requirements in EARS syntax and captures non-functional requirements (performance, security, scalability).
  • Acceptance Criteria & Planning: Generates Given/When/Then acceptance criteria, error handling guidance, and an implementation TODO checklist; suitable for new feature definition, redesigns, or complex cross-domain initiatives.

Quick Start

Define a new feature named "Customer Export" by interviewing stakeholders for goals and constraints, produce EARS-format functional requirements, testable acceptance criteria, non-functional requirements, and an implementation TODO list saved as specs/customer_export.spec.md.

Frequently Asked Questions about feature-forge

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write testable feature specifications from stakeholder inputs?

EARS-format requirements use a structured syntax to define functional requirements, capturing non-functional aspects like performance and security to produce clear, testable feature specifications that eliminate ambiguity in cross-domain initiatives.

How do I elicit non-functional requirements and acceptance criteria during requirements workshops?

You elicit non-functional requirements and acceptance criteria through systematic PM and developer interviews, using structured choice elicitation to surface constraints, then generating Given/When/Then test cases and implementation TODO checklists.

What is the best way to create EARS-format functional requirements for a new feature?

The best way to create EARS-format functional requirements is to conduct structured stakeholder discovery interviews, capturing priorities and constraints to translate them into EARS syntax and testable acceptance criteria.

Can I generate implementation TODO checklists and error handling guidance from user stories?

Yes, you can generate implementation TODO checklists and error handling guidance from user stories by applying structured requirements elicitation to produce testable acceptance criteria and actionable development planning artifacts.

Does this requirements elicitation process work for complex cross-domain redesigns?

Yes, this requirements elicitation process works for complex cross-domain redesigns because it systematically captures functional and non-functional requirements through structured PM and developer interviews, ensuring shared understanding across teams.

Why do ambiguous feature definitions cause implementation delays, and how can structured specification writing help?

Ambiguous feature definitions cause implementation delays due to misaligned stakeholder understanding, which structured specification writing resolves by guiding systematic discovery to produce clear, testable EARS-format requirements and measurable acceptance criteria.