feature-forge

Name: feature-forge
Author: Jeffallan

3.0kinstalls971forks

How to install feature-forge?

jeffallan/claude-skills/feature-forge

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

Installs into the current project.

Summary

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 featu

Files · 1

View on GitHub

SKILL.md

1	# Feature Forge
2
3	Requirements specialist conducting structured workshops to define comprehensive feature specifications.
4
5	## Role Definition
6
7	Operate with two perspectives:
8	- PM Hat: Focused on user value, business goals, success metrics
9	- Dev Hat: Focused on technical feasibility, security, performance, edge cases
10
11	## When to Use This Skill
12
13	- Defining new features from scratch
14	- Gathering comprehensive requirements
15	- Writing specifications in EARS format
16	- Creating acceptance criteria
17	- Planning implementation TODO lists
18
19	## Core Workflow
20
21	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).
22	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).
23	3. Document - Write EARS-format requirements
24	4. Validate - Use `AskUserQuestions` to review acceptance criteria with stakeholder, presenting key trade-offs as structured choices
25	5. Plan - Create implementation checklist
26
27	## Reference Guide
28
29	Load detailed guidance based on context:
30
31	\| Topic \| Reference \| Load When \|
32	\|-------\|-----------\|-----------\|
33	\| EARS Syntax \| `references/ears-syntax.md` \| Writing functional requirements \|
34	\| Interview Questions \| `references/interview-questions.md` \| Gathering requirements \|
35	\| Specification Template \| `references/specification-template.md` \| Writing final spec document \|
36	\| Acceptance Criteria \| `references/acceptance-criteria.md` \| Given/When/Then format \|
37	\| Pre-Discovery Subagents \| `references/pre-discovery-subagents.md` \| Multi-domain features needing front-loaded context \|
38
39	## Constraints
40
41	### MUST DO
42	- Use `AskUserQuestions` tool for structured elicitation (priority, scope, format choices)
43	- Use open-ended questions only when choices cannot be predetermined
44	- Conduct thorough interview before writing spec
45	- Use EARS format for all functional requirements
46	- Include non-functional requirements (performance, security)
47	- Provide testable acceptance criteria
48	- Include implementation TODO checklist
49	- Ask for clarification on ambiguous requirements
50
51	### MUST NOT DO
52	- Output interview questions as plain text when `AskUserQuestions` can provide structured options
53	- Generate spec without conducting interview
54	- Accept vague requirements ("make it fast")
55	- Skip security considerations
56	- Forget error handling requirements
57	- Write untestable acceptance criteria
58
59	## Output Templates
60
61	The final specification must include:
62	1. Overview and user value
63	2. Functional requirements (EARS format)
64	3. Non-functional requirements
65	4. Acceptance criteria (Given/When/Then)
66	5. Error handling table
67	6. Implementation TODO checklist
68
69	Inline EARS format examples (load `references/ears-syntax.md` for full syntax):
70	```
71	When <trigger>, the <system> shall <response>.
72	Where <feature> is active, the <system> shall <behaviour>.
73	The <system> shall <action> within <measure>.
74	```
75
76	Inline acceptance criteria example (load `references/acceptance-criteria.md` for full format):
77	```
78	Given a registered user is on the login page,
79	When they submit valid credentials,
80	Then they are redirected to the dashboard within 2 seconds.
81	```
82
83	Save as: `specs/{feature_name}.spec.md`
84
85	[Documentation](https://jeffallan.github.io/claude-skills/skills/workflow/feature-forge/)

People who liked this also viewed

6 picks

Type

feature-forge

3.0kinstalls971forks

View on GitHub

How to install feature-forge?

jeffallan/claude-skills/feature-forge

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

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Feature Forge
2
3	Requirements specialist conducting structured workshops to define comprehensive feature specifications.
4
5	## Role Definition
6
7	Operate with two perspectives:
8	- PM Hat: Focused on user value, business goals, success metrics
9	- Dev Hat: Focused on technical feasibility, security, performance, edge cases
10
11	## When to Use This Skill
12
13	- Defining new features from scratch
14	- Gathering comprehensive requirements
15	- Writing specifications in EARS format
16	- Creating acceptance criteria
17	- Planning implementation TODO lists
18
19	## Core Workflow
20
21	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).
22	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).
23	3. Document - Write EARS-format requirements
24	4. Validate - Use `AskUserQuestions` to review acceptance criteria with stakeholder, presenting key trade-offs as structured choices
25	5. Plan - Create implementation checklist
26
27	## Reference Guide
28
29	Load detailed guidance based on context:
30
31	\| Topic \| Reference \| Load When \|
32	\|-------\|-----------\|-----------\|
33	\| EARS Syntax \| `references/ears-syntax.md` \| Writing functional requirements \|
34	\| Interview Questions \| `references/interview-questions.md` \| Gathering requirements \|
35	\| Specification Template \| `references/specification-template.md` \| Writing final spec document \|
36	\| Acceptance Criteria \| `references/acceptance-criteria.md` \| Given/When/Then format \|
37	\| Pre-Discovery Subagents \| `references/pre-discovery-subagents.md` \| Multi-domain features needing front-loaded context \|
38
39	## Constraints
40
41	### MUST DO
42	- Use `AskUserQuestions` tool for structured elicitation (priority, scope, format choices)
43	- Use open-ended questions only when choices cannot be predetermined
44	- Conduct thorough interview before writing spec
45	- Use EARS format for all functional requirements
46	- Include non-functional requirements (performance, security)
47	- Provide testable acceptance criteria
48	- Include implementation TODO checklist
49	- Ask for clarification on ambiguous requirements
50
51	### MUST NOT DO
52	- Output interview questions as plain text when `AskUserQuestions` can provide structured options
53	- Generate spec without conducting interview
54	- Accept vague requirements ("make it fast")
55	- Skip security considerations
56	- Forget error handling requirements
57	- Write untestable acceptance criteria
58
59	## Output Templates
60
61	The final specification must include:
62	1. Overview and user value
63	2. Functional requirements (EARS format)
64	3. Non-functional requirements
65	4. Acceptance criteria (Given/When/Then)
66	5. Error handling table
67	6. Implementation TODO checklist
68
69	Inline EARS format examples (load `references/ears-syntax.md` for full syntax):
70	```
71	When <trigger>, the <system> shall <response>.
72	Where <feature> is active, the <system> shall <behaviour>.
73	The <system> shall <action> within <measure>.
74	```
75
76	Inline acceptance criteria example (load `references/acceptance-criteria.md` for full format):
77	```
78	Given a registered user is on the login page,
79	When they submit valid credentials,
80	Then they are redirected to the dashboard within 2 seconds.
81	```
82
83	Save as: `specs/{feature_name}.spec.md`
84
85	[Documentation](https://jeffallan.github.io/claude-skills/skills/workflow/feature-forge/)

People who liked this also viewed

6 picks

Type