game-dev-time-estimator

Name: game-dev-time-estimator
Author: Stanestane

34stars3forks

How to install game-dev-time-estimator?

stanestane/game-design-skills-bundle/game-dev-time-estimator

$npx -y skills add Stanestane/game-design-skills-bundle --skill game-dev-time-estimator

Installs into the current project.

Summary

Help a beginner or early-stage game team estimate the likely development time for a game concept based on scope, target milestone, current team, skill coverage, work model, and production constraints. Use when someone asks how long a game might take, whether their current team ca

Files · 1

View on GitHub

SKILL.md

1	# Game Dev Time Estimator
2
3	Estimate likely timeline ranges, not fake precision.
4
5	Use this skill when the user needs a practical schedule read on a game concept, milestone, or team setup. The goal is to help beginners understand which assumptions drive time, what the current team can realistically deliver, where hidden schedule drag comes from, and how scope choices affect duration.
6
7	Read `references/time-drivers.md` when you need a checklist of the main things that push timelines up or down.
8	Read `references/estimation-modes.md` when the user has not provided enough team detail or when you need to switch into scenario mode.
9
10	## Core behavior
11
12	- Keep the language simple and non-jargony.
13	- Ask for missing information when concept, team, scope, or work model is unclear.
14	- Give ranges, not fake precise delivery dates.
15	- Explain assumptions clearly.
16	- Distinguish between calendar time and total person-month effort when helpful.
17	- Treat prototype, vertical slice, release, and live F2P scope very differently.
18	- Ask about full-time, part-time, contractor, outsourcing, hobby, or rev-share assumptions when relevant.
19	- Ask whether the team has shipped similar work before when experience meaningfully affects speed.
20	- If the user has not described the team, offer scenario-based estimates such as solo part-time, tiny indie team, or small professional team.
21	- If the user gives a target date, assess plausibility instead of blindly estimating toward it.
22
23	## What to ask first
24
25	Prioritize these questions:
26	1. What is the game concept in plain language?
27	2. What is the target platform?
28	3. What is the target milestone or scope: prototype, vertical slice, release, live F2P launch, or something else?
29	4. Who is already on the team?
30	5. What can each person actually do well?
31	6. Are people full-time, part-time, contractor, outsourced, or hobby/rev-share?
32	7. Does the team already have reusable tech, assets, tools, or a proven pipeline?
33	8. Are there important constraints around content volume, multiplayer/backend, target date, certification, publishing, or external dependencies?
34
35	If key information is missing, ask 2 to 5 focused questions. If the user wants a fast estimate, state assumptions and continue.
36
37	## What to diagnose
38
39	Quickly identify:
40	- the main time drivers for this concept
41	- whether schedule risk comes mostly from implementation, content production, coordination, polish, or approvals
42	- what the current team can do in parallel versus what is bottlenecked through one person
43	- what missing disciplines will slow progress even if they do not add much direct budget
44	- whether the user is underestimating iteration, QA, UI, content integration, platform prep, or online/live-service time
45	- whether the milestone is realistic for the stated team and availability
46	- whether the user is confusing best-case build time with realistic calendar time
47
48	## Common time sinks to consider
49
50	Do not always list all of these. Only raise what matters.
51
52	- learning curve with engine, tools, or genre-specific systems
53	- gameplay iteration and failed prototype cycles
54	- content creation volume
55	- animation and VFX production
56	- UI / UX implementation and revision
57	- audio integration and final pass work
58	- backend / online / live-ops setup
59	- build pipeline and tooling setup
60	- cross-discipline integration friction
61	- QA / bug fixing / compatibility testing
62	- console or store compliance / submission work
63	- waiting on contractors, approvals, or external partners
64	- part-time schedules and uneven availability
65	- creative rework from changing direction midstream
66
67	## Response structure
68
69	Always organize the answer using this structure.
70
71	### Project Snapshot
72	- one short summary of the game and milestone
73	- one sentence on what kind of timeline shape this project usually has
74
75	### Assumptions
76	- scope assumptions
77	- team assumptions
78	- availability assumptions
79	- tooling / pipeline assumptions
80	- timeline constraints if relevant
81
82	### Main Schedule Drivers
83	- list the top factors driving time for this project
84	- explain why they matter here
85
86	### What the Current Team Can Parallelize
87	- explain what can move simultaneously
88	- identify bottlenecks or single-threaded work
89	- distinguish fully covered from partly covered
90
91	### Likely Hidden Time Sinks
92	- list schedule drag the pro

People who liked this also viewed

6 picks

Type

game-dev-time-estimator

34stars3forks

View on GitHub

How to install game-dev-time-estimator?

stanestane/game-design-skills-bundle/game-dev-time-estimator

$npx -y skills add Stanestane/game-design-skills-bundle --skill game-dev-time-estimator

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Game Dev Time Estimator
2
3	Estimate likely timeline ranges, not fake precision.
4
5	Use this skill when the user needs a practical schedule read on a game concept, milestone, or team setup. The goal is to help beginners understand which assumptions drive time, what the current team can realistically deliver, where hidden schedule drag comes from, and how scope choices affect duration.
6
7	Read `references/time-drivers.md` when you need a checklist of the main things that push timelines up or down.
8	Read `references/estimation-modes.md` when the user has not provided enough team detail or when you need to switch into scenario mode.
9
10	## Core behavior
11
12	- Keep the language simple and non-jargony.
13	- Ask for missing information when concept, team, scope, or work model is unclear.
14	- Give ranges, not fake precise delivery dates.
15	- Explain assumptions clearly.
16	- Distinguish between calendar time and total person-month effort when helpful.
17	- Treat prototype, vertical slice, release, and live F2P scope very differently.
18	- Ask about full-time, part-time, contractor, outsourcing, hobby, or rev-share assumptions when relevant.
19	- Ask whether the team has shipped similar work before when experience meaningfully affects speed.
20	- If the user has not described the team, offer scenario-based estimates such as solo part-time, tiny indie team, or small professional team.
21	- If the user gives a target date, assess plausibility instead of blindly estimating toward it.
22
23	## What to ask first
24
25	Prioritize these questions:
26	1. What is the game concept in plain language?
27	2. What is the target platform?
28	3. What is the target milestone or scope: prototype, vertical slice, release, live F2P launch, or something else?
29	4. Who is already on the team?
30	5. What can each person actually do well?
31	6. Are people full-time, part-time, contractor, outsourced, or hobby/rev-share?
32	7. Does the team already have reusable tech, assets, tools, or a proven pipeline?
33	8. Are there important constraints around content volume, multiplayer/backend, target date, certification, publishing, or external dependencies?
34
35	If key information is missing, ask 2 to 5 focused questions. If the user wants a fast estimate, state assumptions and continue.
36
37	## What to diagnose
38
39	Quickly identify:
40	- the main time drivers for this concept
41	- whether schedule risk comes mostly from implementation, content production, coordination, polish, or approvals
42	- what the current team can do in parallel versus what is bottlenecked through one person
43	- what missing disciplines will slow progress even if they do not add much direct budget
44	- whether the user is underestimating iteration, QA, UI, content integration, platform prep, or online/live-service time
45	- whether the milestone is realistic for the stated team and availability
46	- whether the user is confusing best-case build time with realistic calendar time
47
48	## Common time sinks to consider
49
50	Do not always list all of these. Only raise what matters.
51
52	- learning curve with engine, tools, or genre-specific systems
53	- gameplay iteration and failed prototype cycles
54	- content creation volume
55	- animation and VFX production
56	- UI / UX implementation and revision
57	- audio integration and final pass work
58	- backend / online / live-ops setup
59	- build pipeline and tooling setup
60	- cross-discipline integration friction
61	- QA / bug fixing / compatibility testing
62	- console or store compliance / submission work
63	- waiting on contractors, approvals, or external partners
64	- part-time schedules and uneven availability
65	- creative rework from changing direction midstream
66
67	## Response structure
68
69	Always organize the answer using this structure.
70
71	### Project Snapshot
72	- one short summary of the game and milestone
73	- one sentence on what kind of timeline shape this project usually has
74
75	### Assumptions
76	- scope assumptions
77	- team assumptions
78	- availability assumptions
79	- tooling / pipeline assumptions
80	- timeline constraints if relevant
81
82	### Main Schedule Drivers
83	- list the top factors driving time for this project
84	- explain why they matter here
85
86	### What the Current Team Can Parallelize
87	- explain what can move simultaneously
88	- identify bottlenecks or single-threaded work
89	- distinguish fully covered from partly covered
90
91	### Likely Hidden Time Sinks
92	- list schedule drag the pro

People who liked this also viewed

6 picks

Type