roadmap

Name: roadmap
Author: jezweb

900installs96forks

How to install roadmap?

jezweb/claude-skills/roadmap

$npx -y skills add jezweb/claude-skills --skill roadmap

Installs into the current project.

Summary

Plan and execute entire application builds. Generates phased delivery roadmaps, then executes them autonomously — phase by phase, committing at milestones, deploying, testing, and continuing until done or stuck. Modes: plan (generate roadmap), start (begin executing), resume (con

Files · 1

View on GitHub

SKILL.md

1	# Roadmap
2
3	Generate a comprehensive technical roadmap for building an entire application. Detailed enough that Claude Code can pick up any phase and execute it autonomously for hours.
4
5	This is not a high-level strategy doc. It's a delivery blueprint — every phase has concrete tasks, every task is actionable, and the whole thing is ordered so you can build from phase 1 through to launch without backtracking.
6
7	## When to Use
8
9	- Starting a major new product (after deep-research, or from a product brief)
10	- Converting a vague idea into an executable plan
11	- Planning a multi-week build that will span many Claude Code sessions
12	- Before saying "build this" — the roadmap is what you hand Claude Code to execute
13
14	## Inputs
15
16	The skill needs one of these:
17
18	\| Input \| Where to find it \|
19	\|-------\|-----------------\|
20	\| Deep research brief \| `.jez/artifacts/research-brief-{topic}.md` (from `/deep-research`) \|
21	\| Product brief \| User describes what they want to build \|
22	\| Existing partial app \| Read CLAUDE.md + codebase to understand what exists \|
23	\| Competitor to clone/improve \| URL or product name — skill analyses it \|
24
25	If the user just says "plan a note-taking app on Cloudflare", that's enough — ask clarifying questions as needed.
26
27	## Workflow
28
29	### 1. Establish the Vision
30
31	Before any technical planning, nail down:
32
33	- One sentence: What is this? ("A cloud-native markdown knowledge workspace for teams and AI agents")
34	- Who: Primary users, secondary users, agents? ("Jez first, then Jezweb team, then clients")
35	- Why: What existing tools fail at? What's the gap? ("Existing tools are headless — you can't browse them or stumble across things")
36	- Constraint: Stack, budget, timeline, must-haves? ("Cloudflare, must have MCP, needs to be a PWA")
37	- Not building: What's explicitly out of scope? ("No real-time CRDT collab, no plugin ecosystem")
38
39	### 2. Define the Stack
40
41	Based on the vision and constraints, lock in the technical stack:
42
43	```markdown
44	\| Layer \| Choice \| Why \|
45	\|-------\|--------\|-----\|
46	\| Frontend \| [framework] \| [reason] \|
47	\| Backend \| [framework + runtime] \| [reason] \|
48	\| Database \| [engine + ORM] \| [reason] \|
49	\| Auth \| [provider] \| [reason] \|
50	\| Storage \| [service] \| [reason] \|
51	\| Search \| [method] \| [reason] \|
52	\| Hosting \| [platform] \| [reason] \|
53	```
54
55	If a deep-research brief exists, pull the recommendations from there. If not, make opinionated choices based on the user's existing stack (check `~/Documents/` for patterns).
56
57	### 3. Design the Data Model
58
59	Sketch all tables/collections the full product will need. Not just phase 1 — the complete model. This prevents schema redesigns mid-build.
60
61	```markdown
62	## Data Model
63
64	### [entity]
65	id, [type]
66	[field], [type], [constraints]
67	...
68	created_at, updated_at
69
70	### [entity]
71	...
72
73	### Relationships
74	- [entity] has many [entity] via [field]
75	- [entity] belongs to [entity] via [field]
76	```
77
78	Mark which tables are needed in which phase. Phase 1 might only need 3 of 8 tables, but designing them all upfront avoids migration pain.
79
80	### 4. Plan the Phases
81
82	This is the core of the roadmap. Each phase must:
83
84	- Have a clear goal — one sentence describing what's different when this phase is done
85	- Be independently deployable — the app works (with reduced features) after each phase
86	- Build on the previous phase — no phase requires ripping out what came before
87	- Be completable in 1-3 Claude Code sessions — if a phase takes more than a day, split it
88
89	#### Phase Structure
90
91	For each phase:
92
93	```markdown
94	## Phase N — [Name]
95	Goal: [One sentence — what the user can do after this phase that they couldn't before]
96	Depends on: Phase N-1
97	Estimated effort: [hours/sessions]
98
99	### What's New
100	[Bullet list of user-visible features]
101
102	### Database Changes
103	[New tables, new columns, migrations needed]
104
105	### API Routes
106	[New endpoints this phase adds]
107
108	### Frontend
109	[New pages, components, UI changes]
110
111	### Infrastructure
112	[New Cloudflare resources, secrets, config]
113
114	### Task Checklist
115	[Actionable tasks grouped by area — these are what Claude Code executes]
116
117	#### Setup
118	- [ ] [task]
119
120	#### Data Layer
121	- [ ] [task]
122	- [ ] [task]
123
124	#### API
125	- [ ] [task]
126
127	#### Frontend
128	- [ ] [task]
129
130	#### Testing & Polish
131	- [ ] [task]
132	- [ ] [task]
133
134	### Definition of Done
135	[How to verify this phase is complete — what to test, what to deploy]
136	```
137
138	### 5. Phase Planning Patterns
139
140	#### Phase 1 — Always the MV

People who liked this also viewed

6 picks

Type

roadmap

900installs96forks

View on GitHub

How to install roadmap?

jezweb/claude-skills/roadmap

$npx -y skills add jezweb/claude-skills --skill roadmap

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Roadmap
2
3	Generate a comprehensive technical roadmap for building an entire application. Detailed enough that Claude Code can pick up any phase and execute it autonomously for hours.
4
5	This is not a high-level strategy doc. It's a delivery blueprint — every phase has concrete tasks, every task is actionable, and the whole thing is ordered so you can build from phase 1 through to launch without backtracking.
6
7	## When to Use
8
9	- Starting a major new product (after deep-research, or from a product brief)
10	- Converting a vague idea into an executable plan
11	- Planning a multi-week build that will span many Claude Code sessions
12	- Before saying "build this" — the roadmap is what you hand Claude Code to execute
13
14	## Inputs
15
16	The skill needs one of these:
17
18	\| Input \| Where to find it \|
19	\|-------\|-----------------\|
20	\| Deep research brief \| `.jez/artifacts/research-brief-{topic}.md` (from `/deep-research`) \|
21	\| Product brief \| User describes what they want to build \|
22	\| Existing partial app \| Read CLAUDE.md + codebase to understand what exists \|
23	\| Competitor to clone/improve \| URL or product name — skill analyses it \|
24
25	If the user just says "plan a note-taking app on Cloudflare", that's enough — ask clarifying questions as needed.
26
27	## Workflow
28
29	### 1. Establish the Vision
30
31	Before any technical planning, nail down:
32
33	- One sentence: What is this? ("A cloud-native markdown knowledge workspace for teams and AI agents")
34	- Who: Primary users, secondary users, agents? ("Jez first, then Jezweb team, then clients")
35	- Why: What existing tools fail at? What's the gap? ("Existing tools are headless — you can't browse them or stumble across things")
36	- Constraint: Stack, budget, timeline, must-haves? ("Cloudflare, must have MCP, needs to be a PWA")
37	- Not building: What's explicitly out of scope? ("No real-time CRDT collab, no plugin ecosystem")
38
39	### 2. Define the Stack
40
41	Based on the vision and constraints, lock in the technical stack:
42
43	```markdown
44	\| Layer \| Choice \| Why \|
45	\|-------\|--------\|-----\|
46	\| Frontend \| [framework] \| [reason] \|
47	\| Backend \| [framework + runtime] \| [reason] \|
48	\| Database \| [engine + ORM] \| [reason] \|
49	\| Auth \| [provider] \| [reason] \|
50	\| Storage \| [service] \| [reason] \|
51	\| Search \| [method] \| [reason] \|
52	\| Hosting \| [platform] \| [reason] \|
53	```
54
55	If a deep-research brief exists, pull the recommendations from there. If not, make opinionated choices based on the user's existing stack (check `~/Documents/` for patterns).
56
57	### 3. Design the Data Model
58
59	Sketch all tables/collections the full product will need. Not just phase 1 — the complete model. This prevents schema redesigns mid-build.
60
61	```markdown
62	## Data Model
63
64	### [entity]
65	id, [type]
66	[field], [type], [constraints]
67	...
68	created_at, updated_at
69
70	### [entity]
71	...
72
73	### Relationships
74	- [entity] has many [entity] via [field]
75	- [entity] belongs to [entity] via [field]
76	```
77
78	Mark which tables are needed in which phase. Phase 1 might only need 3 of 8 tables, but designing them all upfront avoids migration pain.
79
80	### 4. Plan the Phases
81
82	This is the core of the roadmap. Each phase must:
83
84	- Have a clear goal — one sentence describing what's different when this phase is done
85	- Be independently deployable — the app works (with reduced features) after each phase
86	- Build on the previous phase — no phase requires ripping out what came before
87	- Be completable in 1-3 Claude Code sessions — if a phase takes more than a day, split it
88
89	#### Phase Structure
90
91	For each phase:
92
93	```markdown
94	## Phase N — [Name]
95	Goal: [One sentence — what the user can do after this phase that they couldn't before]
96	Depends on: Phase N-1
97	Estimated effort: [hours/sessions]
98
99	### What's New
100	[Bullet list of user-visible features]
101
102	### Database Changes
103	[New tables, new columns, migrations needed]
104
105	### API Routes
106	[New endpoints this phase adds]
107
108	### Frontend
109	[New pages, components, UI changes]
110
111	### Infrastructure
112	[New Cloudflare resources, secrets, config]
113
114	### Task Checklist
115	[Actionable tasks grouped by area — these are what Claude Code executes]
116
117	#### Setup
118	- [ ] [task]
119
120	#### Data Layer
121	- [ ] [task]
122	- [ ] [task]
123
124	#### API
125	- [ ] [task]
126
127	#### Frontend
128	- [ ] [task]
129
130	#### Testing & Polish
131	- [ ] [task]
132	- [ ] [task]
133
134	### Definition of Done
135	[How to verify this phase is complete — what to test, what to deploy]
136	```
137
138	### 5. Phase Planning Patterns
139
140	#### Phase 1 — Always the MV

People who liked this also viewed

6 picks

Type