Gsp build strategy

Skill mike007jd/game-superpowers/skills/gsp-build-strategy

Skills-first game development superpowers for Claude Code and Codex: build, audit, polish, and productionize game projects with reusable Agent Skills.

Install

npx -y skills add mike007jd/game-superpowers --skill gsp-build-strategy

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

5 stars5 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Use when deciding development mode, quality target, task granularity, or refactor policy for game work.

SKILL.md

2.5 KB, as published. Nobody here has run it

Game Build Strategy

Goal

Choose the right build strategy for the project.

Outputs

Follow the gsp-orchestrator output strategy:

inline (default): present build strategy and quality target in conversation.
minimal or full: write docs/game-studio/build-strategy.md and docs/game-studio/quality-target.md.

Use:

../../shared/reference/development-modes.md
../../shared/reference/quality-targets.md
../../shared/templates/build-strategy.md
../../shared/templates/quality-target.md

Development modes

yolo-super
guided-build
refactor-open
surgical-live

Quality targets

first-playable
polished-prototype
production-feature
live-patch

Selection rules

greenfield + narrow mechanic spike -> yolo-super + first-playable
greenfield + serious showcase build -> usually yolo-super or guided-build + polished-prototype
existing product-facing feature work -> usually guided-build or refactor-open + production-feature
shipped or live-risky -> surgical-live + live-patch

Planning policy

Match task size to the mode:

aggressive modes can use large coherent implementation chunks
production-feature work can use medium coherent chunks
live work should use smaller changes with tighter verification

Choose the exploration budget explicitly:

minimal when the task is narrow and already shape-locked
standard for normal product work
high for single-prompt showcase generation, benchmark runs, or any task where first-result quality matters more than token thrift

For high exploration budget work:

spend more tokens up front on concept lock, UX shape, and visual anchor decisions
prefer polished-prototype over first-playable unless the user explicitly wants only a spike
add runtime verification and screenshot critique before claiming completion
if the host supports subagents, default to builder + reviewer + verifier instead of a single uninterrupted build pass
if the task splits cleanly, allow multiple builders in parallel with a shared reviewer / verifier gate

Guardrail

Do not let “safe” planning ruin the result on low-risk greenfield work. Do not let “fast” planning justify broad rewrites on live products. For benchmark or showcase builds, do not optimize for token thrift if that weakens the result.