feature-forge
Scannednpx machina-cli add skill Jeffallan/claude-skills/feature-forge --openclawFeature 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
- Discover - Use
AskUserQuestionsto 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
AskUserQuestionsfor 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
AskUserQuestionsto 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
AskUserQuestionstool 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
AskUserQuestionscan 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
Save as: specs/{feature_name}.spec.md
Knowledge Reference
EARS syntax, user stories, acceptance criteria, Given-When-Then, INVEST criteria, MoSCoW prioritization, OWASP security requirements
Source
git clone https://github.com/Jeffallan/claude-skills/blob/main/skills/feature-forge/SKILL.mdView on GitHub Overview
Feature Forge is a requirements workflow for defining new features, gathering complete requirements, and writing specifications using EARS. It blends PM value with Dev feasibility, guiding structured interviews and delivering a documented spec plus an implementation plan.
How This Skill Works
Follow a five-step core workflow: Discover with AskUserQuestions to establish goals and value, Interview from PM and Dev perspectives to surface constraints, Document by writing EARS-format requirements, Validate with stakeholders using structured choices, and Plan by creating an implementation checklist. Capture both functional and non-functional requirements and finalize with a saved specs document at specs/{feature_name}.spec.md.
When to Use It
- Defining new features from scratch
- Gathering comprehensive requirements
- Writing specifications in EARS format
- Creating acceptance criteria
- Planning implementation TODO lists
Quick Start
- Step 1: Discover the feature goal and value using AskUserQuestions, prioritizing user types and success metrics.
- Step 2: Interview stakeholders (PM and Dev) to surface requirements, constraints, and edge cases across domains.
- Step 3: Document in EARS format, validate with stakeholders, and save as specs/{feature_name}.spec.md with a complete implementation checklist.
Best Practices
- Use AskUserQuestions for structured elicitation (priority, scope, format).
- Conduct a thorough interview across PM and Dev perspectives before writing the spec.
- Write all functional requirements in EARS format.
- Include non-functional requirements (security, performance) and error handling.
- Provide testable acceptance criteria and an implementation TODO checklist.
Example Use Cases
- Define a new feature for a shopping cart upgrade and capture user value, edge cases, and performance expectations using EARS.
- Gather requirements for an authentication flow with MFA, outlining success paths, failures, and security constraints.
- Write an EARS-based spec for a search feature with advanced filters and sorting behavior.
- Create acceptance criteria for an API rate limiter with thresholds, bursts, and retry semantics.
- Plan cross-domain feature work like multi-tenant support, including deployment and security considerations.
