# Gsp Build Strategy

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

- Skill: `mike007jd/gsp-build-strategy-2` (Agent Skill, multi-file: 10 files)
- Install (CLI): `npx skillmds@latest add mike007jd/gsp-build-strategy-2`
- Raw SKILL.md: https://api.skillmd.com/api/skills/mike007jd/gsp-build-strategy-2/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: mike007jd (https://skillmd.com/u/mike007jd)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/mike007jd/gsp-build-strategy-2

---


# 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.