game-dev-first-steps

Name: game-dev-first-steps
Author: Stanestane

34stars3forks

How to install game-dev-first-steps?

stanestane/game-design-skills-bundle/game-dev-first-steps

$npx -y skills add Stanestane/game-design-skills-bundle --skill game-dev-first-steps

Installs into the current project.

Summary

Help a beginner or early-stage indie team turn a game idea into a practical starting plan. Use when someone asks how to start making a game, what to build first, how to approach development order, how to scope a concept for a solo dev, duo, or small team, or how to turn a rough g

Files · 1

View on GitHub

SKILL.md

1	# Game Dev First Steps
2
3	Turn an idea into a sensible early development strategy.
4
5	Use this skill when the user does not need a deep production plan yet. The goal is to help a beginner or lightly experienced team avoid common early mistakes, understand what matters first, and leave with a practical order of work.
6
7	Read `references/team-size-guidance.md` when team composition strongly affects the answer.
8	Read `references/development-order.md` when you need a default build order or beginner-safe sequencing.
9
10	## Core behavior
11
12	- Keep the language simple and non-jargony.
13	- Do not overwhelm the user with giant checklists.
14	- Ask only the minimum questions needed to give useful advice.
15	- Give strategy, not fake precision.
16	- Prefer scope reduction over feature ambition.
17	- Prefer testing and prototyping before content production.
18	- Treat solo, duo, and small-team realities differently.
19	- Support beginners first, but remain useful for slightly more experienced teams that still need structure.
20	- Explain assumptions when key information is missing instead of stalling.
21
22	## What to ask first
23
24	Ask a small set of questions before giving the plan. Adapt to what the user already told you.
25
26	Prioritize these:
27	1. What is the game idea in plain language?
28	2. Who is making it: solo, duo, or small team?
29	3. What skills does the team actually have right now?
30	4. What platform is the first version for?
31	5. What is the intended first milestone: prototype, vertical slice, hobby release, portfolio piece, or commercial launch?
32	6. How big is the intended first version?
33	7. What important constraints exist: time, money, tools, content pipeline, or experience?
34
35	If the user gives partial answers, do not stall. Infer carefully, state assumptions, and continue.
36
37	## What to diagnose
38
39	Quickly identify:
40	- the probable core loop
41	- the likely hardest part
42	- the main scope risk
43	- whether the concept is prototype-first or content-heavy
44	- whether the team ambition does not match the team size or skill mix
45	- whether the user is mixing up prototype, vertical slice, and full production
46
47	## Beginner traps to watch for
48
49	Flag these when relevant:
50	- starting with lore, worldbuilding, or story instead of the playable core
51	- planning too many features before proving the main loop
52	- choosing multiplayer too early
53	- making custom tech before proving the design
54	- making lots of art before the prototype is fun
55	- unclear ownership in a duo or small team
56	- no distinction between prototype, vertical slice, and full production
57	- trying to make the dream version first instead of the smallest convincing version
58	- treating monetization and platform features as proof of fun
59
60	## Response structure
61
62	Always organize the answer using this structure.
63
64	### Idea Snapshot
65	- one short summary of what they are trying to make
66	- one sentence on what matters most right now
67
68	### Team Reality
69	- team size
70	- skill mix
71	- likely strengths
72	- likely blind spots
73	- assumptions if information is missing
74
75	### Recommended Development Order
76	1. define the core player action and core loop
77	2. choose the smallest playable version that tests the main promise
78	3. build a rough prototype fast
79	4. test whether the main interaction is actually fun or interesting
80	5. revise scope and cut weak ideas
81	6. build a tiny vertical slice or first presentable version if the user needs to pitch
82	7. only then expand content, progression, interface, economy, and polish
83	8. prepare for release, handoff, or pitch usage
84
85	### What to Postpone
86	- list features or workstreams that should wait
87	- especially warn about multiplayer, advanced tech, large content production, social features, monetization scaffolding, and polish-heavy work if they are premature
88
89	### Biggest Risks
90	- give the top 2 to 4 risks
91	- explain them in plain language
92
93	### Best Next Steps
94	- give 3 to 5 concrete next actions
95	- at least one should be something they can do today
96
97	## Milestone adaptation
98
99	### If the user needs a prototype
100	- optimize for speed of learning
101	- use placeholder assets
102	- reduce to the smallest loop that tests the idea
103	- focus on whether the idea works at all
104
105	### If the user needs a vertical slice
106	- first prove the loop in rough form
107	- then polish one narrow band of the experience
108	- include only enough progression, economy, or UI to communicate the final direction
109	- do not mistake vertical slice work for full production work
110
111	### If t

People who liked this also viewed

6 picks

Type

game-dev-first-steps

34stars3forks

View on GitHub

How to install game-dev-first-steps?

stanestane/game-design-skills-bundle/game-dev-first-steps

$npx -y skills add Stanestane/game-design-skills-bundle --skill game-dev-first-steps

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Game Dev First Steps
2
3	Turn an idea into a sensible early development strategy.
4
5	Use this skill when the user does not need a deep production plan yet. The goal is to help a beginner or lightly experienced team avoid common early mistakes, understand what matters first, and leave with a practical order of work.
6
7	Read `references/team-size-guidance.md` when team composition strongly affects the answer.
8	Read `references/development-order.md` when you need a default build order or beginner-safe sequencing.
9
10	## Core behavior
11
12	- Keep the language simple and non-jargony.
13	- Do not overwhelm the user with giant checklists.
14	- Ask only the minimum questions needed to give useful advice.
15	- Give strategy, not fake precision.
16	- Prefer scope reduction over feature ambition.
17	- Prefer testing and prototyping before content production.
18	- Treat solo, duo, and small-team realities differently.
19	- Support beginners first, but remain useful for slightly more experienced teams that still need structure.
20	- Explain assumptions when key information is missing instead of stalling.
21
22	## What to ask first
23
24	Ask a small set of questions before giving the plan. Adapt to what the user already told you.
25
26	Prioritize these:
27	1. What is the game idea in plain language?
28	2. Who is making it: solo, duo, or small team?
29	3. What skills does the team actually have right now?
30	4. What platform is the first version for?
31	5. What is the intended first milestone: prototype, vertical slice, hobby release, portfolio piece, or commercial launch?
32	6. How big is the intended first version?
33	7. What important constraints exist: time, money, tools, content pipeline, or experience?
34
35	If the user gives partial answers, do not stall. Infer carefully, state assumptions, and continue.
36
37	## What to diagnose
38
39	Quickly identify:
40	- the probable core loop
41	- the likely hardest part
42	- the main scope risk
43	- whether the concept is prototype-first or content-heavy
44	- whether the team ambition does not match the team size or skill mix
45	- whether the user is mixing up prototype, vertical slice, and full production
46
47	## Beginner traps to watch for
48
49	Flag these when relevant:
50	- starting with lore, worldbuilding, or story instead of the playable core
51	- planning too many features before proving the main loop
52	- choosing multiplayer too early
53	- making custom tech before proving the design
54	- making lots of art before the prototype is fun
55	- unclear ownership in a duo or small team
56	- no distinction between prototype, vertical slice, and full production
57	- trying to make the dream version first instead of the smallest convincing version
58	- treating monetization and platform features as proof of fun
59
60	## Response structure
61
62	Always organize the answer using this structure.
63
64	### Idea Snapshot
65	- one short summary of what they are trying to make
66	- one sentence on what matters most right now
67
68	### Team Reality
69	- team size
70	- skill mix
71	- likely strengths
72	- likely blind spots
73	- assumptions if information is missing
74
75	### Recommended Development Order
76	1. define the core player action and core loop
77	2. choose the smallest playable version that tests the main promise
78	3. build a rough prototype fast
79	4. test whether the main interaction is actually fun or interesting
80	5. revise scope and cut weak ideas
81	6. build a tiny vertical slice or first presentable version if the user needs to pitch
82	7. only then expand content, progression, interface, economy, and polish
83	8. prepare for release, handoff, or pitch usage
84
85	### What to Postpone
86	- list features or workstreams that should wait
87	- especially warn about multiplayer, advanced tech, large content production, social features, monetization scaffolding, and polish-heavy work if they are premature
88
89	### Biggest Risks
90	- give the top 2 to 4 risks
91	- explain them in plain language
92
93	### Best Next Steps
94	- give 3 to 5 concrete next actions
95	- at least one should be something they can do today
96
97	## Milestone adaptation
98
99	### If the user needs a prototype
100	- optimize for speed of learning
101	- use placeholder assets
102	- reduce to the smallest loop that tests the idea
103	- focus on whether the idea works at all
104
105	### If the user needs a vertical slice
106	- first prove the loop in rough form
107	- then polish one narrow band of the experience
108	- include only enough progression, economy, or UI to communicate the final direction
109	- do not mistake vertical slice work for full production work
110
111	### If t

People who liked this also viewed

6 picks

Type