idea-to-spec

Name: idea-to-spec
Author: DevelopersGlobal

64stars10forks

How to install idea-to-spec?

developersglobal/ai-agent-skills/idea-to-spec

$npx -y skills add DevelopersGlobal/ai-agent-skills --skill idea-to-spec

Installs into the current project.

Summary

Converts vague ideas into concrete, testable specifications with acceptance criteria. No implementation begins without a spec.

Files · 1

View on GitHub

SKILL.md

1	## Overview
2
3	Vague ideas produce vague implementations. This skill transforms any idea — no matter how fuzzy — into a concrete specification with clear scope, acceptance criteria, and non-goals.
4
5	## When to Use
6
7	- At the start of any new feature
8	- When a request is ambiguous
9	- Before creating tasks or writing any code
10
11	## Process
12
13	### Step 1: Capture the Core Problem
14
15	1. Write: "Users currently can't [do X], which causes [pain Y]."
16	2. Identify: who has this problem? How often? What's the impact?
17	3. Distinguish problem from solution — don't spec a solution until the problem is understood.
18
19	Verify: You can state the problem without mentioning any implementation.
20
21	### Step 2: Define Success
22
23	4. Write 3–7 acceptance criteria in this format:
24	```
25	Given [context]
26	When [action]
27	Then [outcome]
28	```
29	5. Each criterion must be binary — either it passes or it doesn't.
30	6. Include negative cases: "Given X, the system must NOT do Y."
31
32	Verify: A QA engineer can test each criterion without asking for clarification.
33
34	### Step 3: Define Scope
35
36	7. In scope: List what is explicitly included.
37	8. Out of scope: List what is explicitly excluded — as important as what's included.
38	9. Open questions: List any decisions that still need resolution before implementation.
39
40	Verify: The out-of-scope list has at least 2 items.
41
42	### Step 4: Define Non-Functional Requirements
43
44	10. Performance: response time, throughput, scale targets.
45	11. Security: auth requirements, data sensitivity.
46	12. Reliability: uptime SLA, acceptable error rate.
47
48	## Verification
49
50	- [ ] Problem statement written without mentioning implementation
51	- [ ] Acceptance criteria in Given/When/Then format
52	- [ ] Each criterion is binary (pass/fail)
53	- [ ] Explicit out-of-scope list
54	- [ ] Open questions listed
55
56	## References
57
58	- [think-before-coding skill](../think-before-coding/SKILL.md)
59	- [task-decomposition skill](../task-decomposition/SKILL.md)

People who liked this also viewed

6 picks

Type

idea-to-spec

64stars10forks

View on GitHub

How to install idea-to-spec?

developersglobal/ai-agent-skills/idea-to-spec

$npx -y skills add DevelopersGlobal/ai-agent-skills --skill idea-to-spec

Installs into the current project.

Summary

Converts vague ideas into concrete, testable specifications with acceptance criteria. No implementation begins without a spec.

Files · 1

View on GitHub

SKILL.md

1	## Overview
2
3	Vague ideas produce vague implementations. This skill transforms any idea — no matter how fuzzy — into a concrete specification with clear scope, acceptance criteria, and non-goals.
4
5	## When to Use
6
7	- At the start of any new feature
8	- When a request is ambiguous
9	- Before creating tasks or writing any code
10
11	## Process
12
13	### Step 1: Capture the Core Problem
14
15	1. Write: "Users currently can't [do X], which causes [pain Y]."
16	2. Identify: who has this problem? How often? What's the impact?
17	3. Distinguish problem from solution — don't spec a solution until the problem is understood.
18
19	Verify: You can state the problem without mentioning any implementation.
20
21	### Step 2: Define Success
22
23	4. Write 3–7 acceptance criteria in this format:
24	```
25	Given [context]
26	When [action]
27	Then [outcome]
28	```
29	5. Each criterion must be binary — either it passes or it doesn't.
30	6. Include negative cases: "Given X, the system must NOT do Y."
31
32	Verify: A QA engineer can test each criterion without asking for clarification.
33
34	### Step 3: Define Scope
35
36	7. In scope: List what is explicitly included.
37	8. Out of scope: List what is explicitly excluded — as important as what's included.
38	9. Open questions: List any decisions that still need resolution before implementation.
39
40	Verify: The out-of-scope list has at least 2 items.
41
42	### Step 4: Define Non-Functional Requirements
43
44	10. Performance: response time, throughput, scale targets.
45	11. Security: auth requirements, data sensitivity.
46	12. Reliability: uptime SLA, acceptable error rate.
47
48	## Verification
49
50	- [ ] Problem statement written without mentioning implementation
51	- [ ] Acceptance criteria in Given/When/Then format
52	- [ ] Each criterion is binary (pass/fail)
53	- [ ] Explicit out-of-scope list
54	- [ ] Open questions listed
55
56	## References
57
58	- [think-before-coding skill](../think-before-coding/SKILL.md)
59	- [task-decomposition skill](../task-decomposition/SKILL.md)

People who liked this also viewed

6 picks

Type