draft-spec

Name: draft-spec
Author: tobihagemann

3installs29forks

How to install draft-spec?

tobihagemann/turbo/draft-spec

$npx -y skills add tobihagemann/turbo --skill draft-spec

Installs into the current project.

Summary

Guide a collaborative discussion that produces a specification document at .turbo/specs/<slug>.md. Use when the user asks to \"draft a spec\", \"create a spec\", \"write a spec\", \"discuss a project plan\", \"spec out a project\", \"design a system\", \"let's plan this project\"

Files · 1

View on GitHub

SKILL.md

1	# Draft Spec
2
3	Guide a collaborative discussion to explore a project idea, then synthesize the conversation into a comprehensive specification at `.turbo/specs/<slug>.md`.
4
5	## Task Tracking
6
7	At the start, use `TaskCreate` to create a task for each step:
8
9	1. Capture the vision and pick a slug
10	2. Consult task-specific skills and docs
11	3. Deep-dive discussion
12	4. Draft the spec
13	5. Resolve open questions
14	6. Present and finalize
15
16	## Step 1: Capture the Vision and Pick a Slug
17
18	Absorb whatever the user has provided — a sentence, a paragraph, a brain dump. Do not interrupt or ask questions yet. Restate the vision back in two or three sentences to confirm understanding.
19
20	Pick a slug for the spec file derived from the project or feature name:
21
22	- Lowercase
23	- Replace non-alphanumeric characters with hyphens
24	- Collapse consecutive hyphens
25	- Trim leading and trailing hyphens
26	- Truncate to 40 characters at a word boundary
27
28	Example: "Photo Sorter v2" → `photo-sorter-v2`. The user may pass an explicit slug; if so, honor it.
29
30	If `.turbo/specs/<slug>.md` already exists, use `AskUserQuestion` to ask whether to overwrite, append a numeric suffix (`-2`, `-3`, ...), or pick a different slug.
31
32	State the chosen slug and the resulting spec path before continuing.
33
34	Then use `AskUserQuestion` to ask 1-4 focused opening questions targeting the biggest unknowns. Skip anything the user already answered. Prioritize from:
35
36	- What problem does this solve, and for whom?
37	- Is this greenfield or does existing code/infrastructure exist?
38	- Are there strong technology preferences or constraints?
39	- What does the MVP look like versus the full vision?
40	- Are there hard deadlines, budget limits, or team size constraints?
41
42	## Step 2: Consult Task-Specific Skills and Docs
43
44	Ground architecture and tech-stack choices in current reality before the deep-dive discussion.
45
46	1. Scan for matching skills. Compare the vision and opening-question answers against available skill trigger descriptions. For each unambiguous match, run the skill via the Skill tool. This loads decision-level guidance (idiomatic patterns, known pitfalls, version constraints) before architectural choices are made. If unsure, do not load.
47	2. Look up library or framework docs. For any library, framework, or platform the user mentioned or the project clearly needs, query documentation MCP tools (or WebSearch as a fallback) when the decision hinges on current capabilities, supported versions, or known constraints.
48
49	Keep findings at the decision level: what tools can do, which approaches are idiomatic, which versions to target. Do not embed specific API signatures or code snippets into the spec. Those belong in implementation-time skill loads.
50
51	## Step 3: Deep-Dive Discussion
52
53	Interview the user relentlessly about every aspect of the project until you reach shared understanding. Gather behavioral requirements (the "what") before architectural design (the "how"), so design decisions land against a concrete set of requirements instead of being taken in the abstract. Track coverage internally but do not present the list as a rigid checklist. When the user jumps to architecture early, engage briefly then circle back to confirm the behavioral picture is complete.
54
55	### Requirements (gather first)
56
57	\| Category \| What to explore \|
58	\|---\|---\|
59	\| Users and personas \| Who uses this? Goals, pain points, technical sophistication \|
60	\| Core behaviors \| Primary capabilities and user-facing workflows — the behaviors the system must exhibit \|
61	\| Non-functional requirements \| Performance, security, accessibility, i18n, compliance \|
62
63	### Design (gather after requirements are clear)
64
65	\| Category \| What to explore \|
66	\|---\|---\|
67	\| Architecture \| Client/server split, monolith vs services, real-time needs, offline support \|
68	\| Tech stack \| Languages, frameworks, databases, hosting — preferences and constraints \|
69	\| Data model \| Key entities, relationships, storage strategy \|
70	\| Integrations \| Third-party APIs, auth providers, external data sources \|
71
72	### Cross-cutting
73
74	\| Category \| What to explore \|
75	\|---\|---\|
76	\| MVP scope \| What ships first? What is explicitly deferred? \|
77	\| Open questions \| Unknowns needing research, prototyping, or external input \|
78
79	### Discussion Guidelines
80
81	- If a question can be answered by exploring the codebase, explore the codebase instead
82	- Use `AskUserQuestion` to ask one question at a time. Use options with descriptions to frame trade-offs and offer concrete suggestions. Use `multiSelect` when choices are not mutually exclusive.
83	- When the user gives a short an

People who liked this also viewed

6 picks

Type

draft-spec

3installs29forks

View on GitHub

How to install draft-spec?

tobihagemann/turbo/draft-spec

$npx -y skills add tobihagemann/turbo --skill draft-spec

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Draft Spec
2
3	Guide a collaborative discussion to explore a project idea, then synthesize the conversation into a comprehensive specification at `.turbo/specs/<slug>.md`.
4
5	## Task Tracking
6
7	At the start, use `TaskCreate` to create a task for each step:
8
9	1. Capture the vision and pick a slug
10	2. Consult task-specific skills and docs
11	3. Deep-dive discussion
12	4. Draft the spec
13	5. Resolve open questions
14	6. Present and finalize
15
16	## Step 1: Capture the Vision and Pick a Slug
17
18	Absorb whatever the user has provided — a sentence, a paragraph, a brain dump. Do not interrupt or ask questions yet. Restate the vision back in two or three sentences to confirm understanding.
19
20	Pick a slug for the spec file derived from the project or feature name:
21
22	- Lowercase
23	- Replace non-alphanumeric characters with hyphens
24	- Collapse consecutive hyphens
25	- Trim leading and trailing hyphens
26	- Truncate to 40 characters at a word boundary
27
28	Example: "Photo Sorter v2" → `photo-sorter-v2`. The user may pass an explicit slug; if so, honor it.
29
30	If `.turbo/specs/<slug>.md` already exists, use `AskUserQuestion` to ask whether to overwrite, append a numeric suffix (`-2`, `-3`, ...), or pick a different slug.
31
32	State the chosen slug and the resulting spec path before continuing.
33
34	Then use `AskUserQuestion` to ask 1-4 focused opening questions targeting the biggest unknowns. Skip anything the user already answered. Prioritize from:
35
36	- What problem does this solve, and for whom?
37	- Is this greenfield or does existing code/infrastructure exist?
38	- Are there strong technology preferences or constraints?
39	- What does the MVP look like versus the full vision?
40	- Are there hard deadlines, budget limits, or team size constraints?
41
42	## Step 2: Consult Task-Specific Skills and Docs
43
44	Ground architecture and tech-stack choices in current reality before the deep-dive discussion.
45
46	1. Scan for matching skills. Compare the vision and opening-question answers against available skill trigger descriptions. For each unambiguous match, run the skill via the Skill tool. This loads decision-level guidance (idiomatic patterns, known pitfalls, version constraints) before architectural choices are made. If unsure, do not load.
47	2. Look up library or framework docs. For any library, framework, or platform the user mentioned or the project clearly needs, query documentation MCP tools (or WebSearch as a fallback) when the decision hinges on current capabilities, supported versions, or known constraints.
48
49	Keep findings at the decision level: what tools can do, which approaches are idiomatic, which versions to target. Do not embed specific API signatures or code snippets into the spec. Those belong in implementation-time skill loads.
50
51	## Step 3: Deep-Dive Discussion
52
53	Interview the user relentlessly about every aspect of the project until you reach shared understanding. Gather behavioral requirements (the "what") before architectural design (the "how"), so design decisions land against a concrete set of requirements instead of being taken in the abstract. Track coverage internally but do not present the list as a rigid checklist. When the user jumps to architecture early, engage briefly then circle back to confirm the behavioral picture is complete.
54
55	### Requirements (gather first)
56
57	\| Category \| What to explore \|
58	\|---\|---\|
59	\| Users and personas \| Who uses this? Goals, pain points, technical sophistication \|
60	\| Core behaviors \| Primary capabilities and user-facing workflows — the behaviors the system must exhibit \|
61	\| Non-functional requirements \| Performance, security, accessibility, i18n, compliance \|
62
63	### Design (gather after requirements are clear)
64
65	\| Category \| What to explore \|
66	\|---\|---\|
67	\| Architecture \| Client/server split, monolith vs services, real-time needs, offline support \|
68	\| Tech stack \| Languages, frameworks, databases, hosting — preferences and constraints \|
69	\| Data model \| Key entities, relationships, storage strategy \|
70	\| Integrations \| Third-party APIs, auth providers, external data sources \|
71
72	### Cross-cutting
73
74	\| Category \| What to explore \|
75	\|---\|---\|
76	\| MVP scope \| What ships first? What is explicitly deferred? \|
77	\| Open questions \| Unknowns needing research, prototyping, or external input \|
78
79	### Discussion Guidelines
80
81	- If a question can be answered by exploring the codebase, explore the codebase instead
82	- Use `AskUserQuestion` to ask one question at a time. Use options with descriptions to frame trade-offs and offer concrete suggestions. Use `multiSelect` when choices are not mutually exclusive.
83	- When the user gives a short an

People who liked this also viewed

6 picks

Type