elicit-requirements

Name: elicit-requirements
Author: faizkhairi

61stars19forks

How to install elicit-requirements?

faizkhairi/claude-code-blueprint/elicit-requirements

$npx -y skills add faizkhairi/claude-code-blueprint --skill elicit-requirements

Installs into the current project.

Summary

Structured pre-feature requirements gathering. Run before writing any new feature or API endpoint to clarify scope, acceptance criteria, and technical constraints. Produces: a Requirements Summary (Problem | Scope | Stories | Acceptance Criteria | Out of Scope | Open Questions),

Files · 1

View on GitHub

SKILL.md

1	# Elicit Requirements: Structured Pre-Feature Clarification
2
3	Run this before writing any new feature to avoid scope creep, missed edge cases, and
4	mid-implementation discoveries that force rewrites.
5
6	## Elicitation Workflow
7
8	Work through these sections with the user. Ask grouped questions; do not ask one at a time.
9
10	---
11
12	### 1. Problem Statement
13
14	Ask:
15	- What problem are we solving, and for whom?
16	- What triggers this feature? (user action, external system push, scheduled job, webhook)
17	- What is the expected outcome when it works correctly?
18	- What is the expected behaviour when it fails?
19
20	---
21
22	### 2. User Roles and Stakeholders
23
24	Ask:
25	- Which user roles interact with this directly? (admin, developer, end user, external system)
26	- Which roles are indirectly affected? (e.g., reports they see change, notifications they receive)
27	- For integration features: which external system is involved? (identify from project context or ask)
28
29	---
30
31	### 3. Technical Constraints
32
33	For integration or API features, always clarify:
34
35	\| Constraint \| Questions \|
36	\|---\|---\|
37	\| System \| Which external system? \|
38	\| Direction \| INBOUND (system pushes to us) or OUTBOUND (we push to system)? \|
39	\| Trigger \| API call, webhook, scheduled job, file arrival? \|
40	\| Data format \| JSON? XML? CSV? Other? \|
41	\| Auth \| JWT? API key? mTLS? None (internal only)? \|
42	\| Error handling \| Retry? Dead-letter queue? Alert? Silent fail? \|
43	\| Idempotency \| Must duplicate calls be safe? \|
44
45	---
46
47	### 4. Acceptance Criteria
48
49	For each piece of functionality, define:
50	- What HTTP endpoint (method + path) if applicable
51	- What the success response looks like (status code, key fields)
52	- What DB rows are created/updated and with which values
53	- What external calls are made (APIs, storage, queues)
54	- What happens on error (validation fail, external system down, duplicate)
55
56	Acceptance criteria must be verifiable without human judgement. If it says "looks good" or "works correctly" it is not an acceptance criterion.
57
58	Good: `POST /api/v1/orders returns 202 with { "jobId": "<uuid>" } and creates job row with status='PENDING'`
59
60	Bad: "The endpoint should handle the data correctly"
61
62	---
63
64	### 5. Out of Scope
65
66	Explicitly list what is NOT included in this feature to prevent scope creep:
67	- Which related endpoints are deferred?
68	- Which error scenarios are explicitly not handled yet?
69	- Which UI/dashboard elements are not part of this backend feature?
70
71	---
72
73	### 6. Dependencies and Ordering
74
75	- Does this feature depend on another feature being complete first?
76	- Does another feature depend on this being complete?
77	- What environment is needed to test? (running dev server, specific DB records, external system mock?)
78
79	---
80
81	## Output
82
83	After elicitation, produce a structured summary:
84
85	```markdown
86	## Requirements Summary: [Feature Name]
87
88	### Problem
89	[1-2 sentences]
90
91	### Scope
92	- System: [external system if applicable]
93	- Direction: [inbound/outbound]
94	- Trigger: [how it starts]
95
96	### Stories (ordered by dependency)
97	1. [Story 1 title] — [one-line description]
98	2. [Story 2 title] — [one-line description]
99
100	### Acceptance Criteria (per story)
101	Story 1:
102	- ...
103
104	### Out of Scope
105	- ...
106
107	### Open Questions
108	- ...
109	```
110
111	## Step 7: Confirmation Before Saving
112
113	After drafting the Requirements Summary, present it to the user in readable markdown and ask:
114
115	> "Does this requirements summary look complete and accurate? Should I save it?"
116
117	Do NOT save until the user confirms (yes / save / proceed / looks good). If the user wants revisions, loop back to the relevant section, update the draft, and re-present.
118
119	Only after confirmation: save the requirements to a structured markdown file the user can reference during implementation.

People who liked this also viewed

6 picks

Type

elicit-requirements

61stars19forks

View on GitHub

How to install elicit-requirements?

faizkhairi/claude-code-blueprint/elicit-requirements

$npx -y skills add faizkhairi/claude-code-blueprint --skill elicit-requirements

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Elicit Requirements: Structured Pre-Feature Clarification
2
3	Run this before writing any new feature to avoid scope creep, missed edge cases, and
4	mid-implementation discoveries that force rewrites.
5
6	## Elicitation Workflow
7
8	Work through these sections with the user. Ask grouped questions; do not ask one at a time.
9
10	---
11
12	### 1. Problem Statement
13
14	Ask:
15	- What problem are we solving, and for whom?
16	- What triggers this feature? (user action, external system push, scheduled job, webhook)
17	- What is the expected outcome when it works correctly?
18	- What is the expected behaviour when it fails?
19
20	---
21
22	### 2. User Roles and Stakeholders
23
24	Ask:
25	- Which user roles interact with this directly? (admin, developer, end user, external system)
26	- Which roles are indirectly affected? (e.g., reports they see change, notifications they receive)
27	- For integration features: which external system is involved? (identify from project context or ask)
28
29	---
30
31	### 3. Technical Constraints
32
33	For integration or API features, always clarify:
34
35	\| Constraint \| Questions \|
36	\|---\|---\|
37	\| System \| Which external system? \|
38	\| Direction \| INBOUND (system pushes to us) or OUTBOUND (we push to system)? \|
39	\| Trigger \| API call, webhook, scheduled job, file arrival? \|
40	\| Data format \| JSON? XML? CSV? Other? \|
41	\| Auth \| JWT? API key? mTLS? None (internal only)? \|
42	\| Error handling \| Retry? Dead-letter queue? Alert? Silent fail? \|
43	\| Idempotency \| Must duplicate calls be safe? \|
44
45	---
46
47	### 4. Acceptance Criteria
48
49	For each piece of functionality, define:
50	- What HTTP endpoint (method + path) if applicable
51	- What the success response looks like (status code, key fields)
52	- What DB rows are created/updated and with which values
53	- What external calls are made (APIs, storage, queues)
54	- What happens on error (validation fail, external system down, duplicate)
55
56	Acceptance criteria must be verifiable without human judgement. If it says "looks good" or "works correctly" it is not an acceptance criterion.
57
58	Good: `POST /api/v1/orders returns 202 with { "jobId": "<uuid>" } and creates job row with status='PENDING'`
59
60	Bad: "The endpoint should handle the data correctly"
61
62	---
63
64	### 5. Out of Scope
65
66	Explicitly list what is NOT included in this feature to prevent scope creep:
67	- Which related endpoints are deferred?
68	- Which error scenarios are explicitly not handled yet?
69	- Which UI/dashboard elements are not part of this backend feature?
70
71	---
72
73	### 6. Dependencies and Ordering
74
75	- Does this feature depend on another feature being complete first?
76	- Does another feature depend on this being complete?
77	- What environment is needed to test? (running dev server, specific DB records, external system mock?)
78
79	---
80
81	## Output
82
83	After elicitation, produce a structured summary:
84
85	```markdown
86	## Requirements Summary: [Feature Name]
87
88	### Problem
89	[1-2 sentences]
90
91	### Scope
92	- System: [external system if applicable]
93	- Direction: [inbound/outbound]
94	- Trigger: [how it starts]
95
96	### Stories (ordered by dependency)
97	1. [Story 1 title] — [one-line description]
98	2. [Story 2 title] — [one-line description]
99
100	### Acceptance Criteria (per story)
101	Story 1:
102	- ...
103
104	### Out of Scope
105	- ...
106
107	### Open Questions
108	- ...
109	```
110
111	## Step 7: Confirmation Before Saving
112
113	After drafting the Requirements Summary, present it to the user in readable markdown and ask:
114
115	> "Does this requirements summary look complete and accurate? Should I save it?"
116
117	Do NOT save until the user confirms (yes / save / proceed / looks good). If the user wants revisions, loop back to the relevant section, update the draft, and re-present.
118
119	Only after confirmation: save the requirements to a structured markdown file the user can reference during implementation.

People who liked this also viewed

6 picks

Type