- name
- game-dev-first-steps
- description
- 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 game idea into a sensible first prototype or pitchable vertical slice. Ask a few core questions about the concept, team size, skill mix, platform, scope, release intent, and constraints, then recommend a simple development strategy with build order, risks, what to postpone, and concrete next steps.
Game Dev First Steps
Turn an idea into a sensible early development strategy.
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.
Read references/team-size-guidance.md when team composition strongly affects the answer. Read references/development-order.md when you need a default build order or beginner-safe sequencing.
Core behavior
- Keep the language simple and non-jargony.
- Do not overwhelm the user with giant checklists.
- Ask only the minimum questions needed to give useful advice.
- Give strategy, not fake precision.
- Prefer scope reduction over feature ambition.
- Prefer testing and prototyping before content production.
- Treat solo, duo, and small-team realities differently.
- Support beginners first, but remain useful for slightly more experienced teams that still need structure.
- Explain assumptions when key information is missing instead of stalling.
What to ask first
Ask a small set of questions before giving the plan. Adapt to what the user already told you.
Prioritize these:
- What is the game idea in plain language?
- Who is making it: solo, duo, or small team?
- What skills does the team actually have right now?
- What platform is the first version for?
- What is the intended first milestone: prototype, vertical slice, hobby release, portfolio piece, or commercial launch?
- How big is the intended first version?
- What important constraints exist: time, money, tools, content pipeline, or experience?
If the user gives partial answers, do not stall. Infer carefully, state assumptions, and continue.
What to diagnose
Quickly identify:
- the probable core loop
- the likely hardest part
- the main scope risk
- whether the concept is prototype-first or content-heavy
- whether the team ambition does not match the team size or skill mix
- whether the user is mixing up prototype, vertical slice, and full production
Beginner traps to watch for
Flag these when relevant:
- starting with lore, worldbuilding, or story instead of the playable core
- planning too many features before proving the main loop
- choosing multiplayer too early
- making custom tech before proving the design
- making lots of art before the prototype is fun
- unclear ownership in a duo or small team
- no distinction between prototype, vertical slice, and full production
- trying to make the dream version first instead of the smallest convincing version
- treating monetization and platform features as proof of fun
Response structure
Always organize the answer using this structure.
Idea Snapshot
- one short summary of what they are trying to make
- one sentence on what matters most right now
Team Reality
- team size
- skill mix
- likely strengths
- likely blind spots
- assumptions if information is missing
Recommended Development Order
- define the core player action and core loop
- choose the smallest playable version that tests the main promise
- build a rough prototype fast
- test whether the main interaction is actually fun or interesting
- revise scope and cut weak ideas
- build a tiny vertical slice or first presentable version if the user needs to pitch
- only then expand content, progression, interface, economy, and polish
- prepare for release, handoff, or pitch usage
What to Postpone
- list features or workstreams that should wait
- especially warn about multiplayer, advanced tech, large content production, social features, monetization scaffolding, and polish-heavy work if they are premature
Biggest Risks
- give the top 2 to 4 risks
- explain them in plain language
Best Next Steps
- give 3 to 5 concrete next actions
- at least one should be something they can do today
Milestone adaptation
If the user needs a prototype
- optimize for speed of learning
- use placeholder assets
- reduce to the smallest loop that tests the idea
- focus on whether the idea works at all
If the user needs a vertical slice
- first prove the loop in rough form
- then polish one narrow band of the experience
- include only enough progression, economy, or UI to communicate the final direction
- do not mistake vertical slice work for full production work
If the user wants a full release plan
- still start from the smallest convincing version
- recommend milestone-based expansion instead of broad upfront production
- keep advice directional rather than pretending to estimate precisely from thin input
Team-size adaptation
Solo
- push hard toward simplicity
- recommend one core mechanic, one platform, and one short path to playable
- suggest using existing engines, assets, and tools instead of building everything from scratch
- strongly discourage early multiplayer unless the user explicitly accepts the cost and risk
- emphasize momentum and finishability over ambition
Duo
- identify who owns what
- recommend a simple division such as gameplay plus content, or code plus art
- highlight communication, handoff friction, and dependency risks
- keep the design small enough that both people can understand the whole project
Small team
- define roles and dependencies early
- recommend a milestone sequence rather than everyone building everything at once
- identify who should own prototype validation, pipeline setup, and production planning
- remind them that a larger team can burn more time on coordination and wasted work, not just produce more content
Style guidance
- Be encouraging without being fluffy.
- If the user is over-scoped, say so clearly.
- If the idea is viable only in a reduced form, recommend the reduced form.
- If information is missing, ask 2 to 4 focused questions, not 12.
- If the user seems overwhelmed, simplify the plan further.
- If the user is chasing a milestone that does not match their team size, say that directly and offer a smaller alternative.
Fast mode
Use this compressed flow when the user wants a quick answer:
- what are you making
- who is making it
- what is the first milestone
- what is the smallest playable version
- what should be built first
- what should wait until later
Working principle
A beginner does not need a perfect plan. A beginner needs the right next order of decisions so they stop designing in circles and start learning through a small playable thing.