game-design-prototyping-companion

Name: game-design-prototyping-companion
Author: Stanestane

34stars3forks

How to install game-design-prototyping-companion?

stanestane/game-design-skills-bundle/game-design-prototyping-companion

$npx -y skills add Stanestane/game-design-skills-bundle --skill game-design-prototyping-companion

Installs into the current project.

Summary

Track game design prototype ideas, branching outcomes, dead ends, baselines, and next experiments, and optionally generate a simple SVG visualization of prototype evolution. Use when a prototype leads to several possible follow-up paths, when the team needs to backtrack without l

Files · 1

View on GitHub

SKILL.md

1	# Game Design Prototyping Companion
2
3	Track prototype evolution, not just prototype results.
4
5	Use this skill when prototyping produces branching decisions, dead ends, alternative paths, and backtracking. The aim is to preserve learning structure: what was tested, what was learned, what branch it created, which path was followed, and which paths remain available to revisit.
6
7	This skill can also generate a simple SVG branch map from a lightweight text or JSON structure.
8
9	## What to produce
10
11	Generate one or more of these outputs:
12	1. Prototype log - what was tested and why
13	2. Branch record - what paths emerged from the result
14	3. Decision state - which branch is current, parked, dead, baseline, or promising
15	4. Backtrack notes - what can be revisited later and under what condition
16	5. SVG branch map - a visual map of prototype evolution
17
18	## Core principle
19
20	A prototype is not just a yes/no answer.
21	It often creates a tree:
22	- one branch becomes the current path
23	- another becomes a dead end
24	- another becomes a parked idea worth revisiting later
25	- another reveals a stronger question than the original one
26
27	The skill should preserve that tree.
28
29	## Workflow
30
31	### 1. Define the prototype node
32	For each prototype node, record:
33	- Node ID
34	- Prototype name
35	- Question being tested
36	- What was built or simulated
37	- What was learned
38	- Result state
39
40	Use result states such as:
41	- baseline
42	- promising
43	- branch trigger
44	- dead end
45	- parked
46	- production candidate
47
48	### 2. Record branch options
49	When a prototype produces several next moves, capture each branch explicitly.
50
51	For each branch, record:
52	- Branch ID
53	- Parent node
54	- New idea or variation
55	- Reason it exists
56	- Current status
57
58	### 3. Mark the chosen path without deleting the others
59	Do not treat the selected branch as the only meaningful output.
60	Preserve:
61	- abandoned paths
62	- deferred paths
63	- weird side paths
64	- stronger substitute ideas revealed by the test
65
66	### 4. Add backtrack logic
67	If a branch is not chosen now, record:
68	- what would justify revisiting it
69	- what blocker currently prevents it
70	- what later discovery might make it relevant again
71
72	### 5. Generate a visual map when useful
73	Use `scripts/branch_map_svg.py` to render a simple SVG from a branch-map JSON file.
74
75	Read:
76	- `references/branch-map-format.md` for the input structure
77	- `references/example-branch-map.json` for an example
78
79	## Response structure
80
81	Use this structure unless the user asks for something else:
82
83	### Prototype Node
84	- Node ID: ...
85	- Question: ...
86	- Built / simulated: ...
87	- Learned: ...
88	- State: ...
89
90	### Branches Created
91	1. ...
92	2. ...
93	3. ...
94
95	### Current Chosen Path
96	- ...
97
98	### Parked / Revisit Later
99	- ...
100
101	### Suggested Next Prototype
102	- ...
103
104	## Visualization workflow
105
106	When the user wants a visual branch map:
107	1. write the branch data to JSON using the format in `references/branch-map-format.md`
108	2. run `scripts/branch_map_svg.py <input.json> <output.svg>`
109	3. return the SVG path and summarize what the map shows
110
111	## Style rules
112	- Preserve branching history.
113	- Prefer explicit node IDs over vague prose.
114	- Distinguish clearly between what was learned and what was merely assumed.
115	- Do not erase dead ends; label them.
116	- Do not confuse the current path with the best possible path forever.
117
118	## References
119
120	- `references/branch-map-format.md` for the JSON structure
121	- `references/example-branch-map.json` for a starter example
122	- `references/state-labels.md` for recommended branch/node labels
123
124	## Working principle
125
126	Prototype trees are design memory.
127	If you only remember the path you chose, you lose the intelligence of the paths you rejected.

People who liked this also viewed

6 picks

Type

game-design-prototyping-companion

34stars3forks

View on GitHub

How to install game-design-prototyping-companion?

stanestane/game-design-skills-bundle/game-design-prototyping-companion

$npx -y skills add Stanestane/game-design-skills-bundle --skill game-design-prototyping-companion

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Game Design Prototyping Companion
2
3	Track prototype evolution, not just prototype results.
4
5	Use this skill when prototyping produces branching decisions, dead ends, alternative paths, and backtracking. The aim is to preserve learning structure: what was tested, what was learned, what branch it created, which path was followed, and which paths remain available to revisit.
6
7	This skill can also generate a simple SVG branch map from a lightweight text or JSON structure.
8
9	## What to produce
10
11	Generate one or more of these outputs:
12	1. Prototype log - what was tested and why
13	2. Branch record - what paths emerged from the result
14	3. Decision state - which branch is current, parked, dead, baseline, or promising
15	4. Backtrack notes - what can be revisited later and under what condition
16	5. SVG branch map - a visual map of prototype evolution
17
18	## Core principle
19
20	A prototype is not just a yes/no answer.
21	It often creates a tree:
22	- one branch becomes the current path
23	- another becomes a dead end
24	- another becomes a parked idea worth revisiting later
25	- another reveals a stronger question than the original one
26
27	The skill should preserve that tree.
28
29	## Workflow
30
31	### 1. Define the prototype node
32	For each prototype node, record:
33	- Node ID
34	- Prototype name
35	- Question being tested
36	- What was built or simulated
37	- What was learned
38	- Result state
39
40	Use result states such as:
41	- baseline
42	- promising
43	- branch trigger
44	- dead end
45	- parked
46	- production candidate
47
48	### 2. Record branch options
49	When a prototype produces several next moves, capture each branch explicitly.
50
51	For each branch, record:
52	- Branch ID
53	- Parent node
54	- New idea or variation
55	- Reason it exists
56	- Current status
57
58	### 3. Mark the chosen path without deleting the others
59	Do not treat the selected branch as the only meaningful output.
60	Preserve:
61	- abandoned paths
62	- deferred paths
63	- weird side paths
64	- stronger substitute ideas revealed by the test
65
66	### 4. Add backtrack logic
67	If a branch is not chosen now, record:
68	- what would justify revisiting it
69	- what blocker currently prevents it
70	- what later discovery might make it relevant again
71
72	### 5. Generate a visual map when useful
73	Use `scripts/branch_map_svg.py` to render a simple SVG from a branch-map JSON file.
74
75	Read:
76	- `references/branch-map-format.md` for the input structure
77	- `references/example-branch-map.json` for an example
78
79	## Response structure
80
81	Use this structure unless the user asks for something else:
82
83	### Prototype Node
84	- Node ID: ...
85	- Question: ...
86	- Built / simulated: ...
87	- Learned: ...
88	- State: ...
89
90	### Branches Created
91	1. ...
92	2. ...
93	3. ...
94
95	### Current Chosen Path
96	- ...
97
98	### Parked / Revisit Later
99	- ...
100
101	### Suggested Next Prototype
102	- ...
103
104	## Visualization workflow
105
106	When the user wants a visual branch map:
107	1. write the branch data to JSON using the format in `references/branch-map-format.md`
108	2. run `scripts/branch_map_svg.py <input.json> <output.svg>`
109	3. return the SVG path and summarize what the map shows
110
111	## Style rules
112	- Preserve branching history.
113	- Prefer explicit node IDs over vague prose.
114	- Distinguish clearly between what was learned and what was merely assumed.
115	- Do not erase dead ends; label them.
116	- Do not confuse the current path with the best possible path forever.
117
118	## References
119
120	- `references/branch-map-format.md` for the JSON structure
121	- `references/example-branch-map.json` for a starter example
122	- `references/state-labels.md` for recommended branch/node labels
123
124	## Working principle
125
126	Prototype trees are design memory.
127	If you only remember the path you chose, you lose the intelligence of the paths you rejected.

People who liked this also viewed

6 picks

Type