使用方法
- 复制安装命令，在自己的智能体环境安装前先检查源码包。
- 从原始文档核对所需工具、凭据和支持的宿主。
- 说明输入材料与期望交付物，并对照来源检查输出。
npx skills add https://github.com/jeffallan/claude-skills --skill feature-forge开始前需了解
- 安装不包含模型订阅、API 额度或访问文件的权限。
- 仓库星数和安装量反映活跃情况，不等于独立质量或安全测试。
仓库原始内容
按源仓库内容呈现，保留标题、案例、代码、表格、链接以及原文引用的演示图片。
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
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
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
