About game-improvement-loop
game-improvement-loop is a skill for iteratively improving games through evidence-based playtesting. It guides agents from an approved design direction through implementation, timed tests, and recorded player-facing findings.
Key features
- 01Approval gate before specs or code
- 02Sequential improvement cycles
- 03Playtests tied to delivery evidence
- 04Structured evidence and verdict logs
- 05Sub-agent coordination guidance
Use cases
- 01Improving a game's player-facing behavior
- 02Testing a change in its target runtime
- 03Carrying findings into the next cycle
Install
Copy the command and run it in a terminal.
npx skills add https:/ / github.com/ gil-1/ skills --skill game-improvement-loopAfter installing, type/game-improvement-loopin Claude Code to confirm it loaded.
Details
From the project READMEGame Improvement Loop
Improve this game through short evidence loops. Keep player experience central and adapt the loop to the game's genre, platform, controls, and design promise.
Defaults
- Cycles: 3 unless user says otherwise.
- Playtest: 30 minutes per cycle unless user says otherwise.
- Log:
.scratch/game-improvement-loop/<YYYY-MM-DD>-<goal-slug>/cycle-N.md.
Do not shorten a requested/default playtest unless user approves. If full playtest cannot run, mark cycle incomplete.
Start Gate
Before PRD or code:
- Read local rules, docs, prior playtests, tickets/PRDs, and code paths relevant to the player-facing behavior.
- Research external references only when they help the requested goal.
- Return concise direction brief:
- player promise
- behavior to improve
- recommended direction plus key alternatives
- likely data/state needs
- primary player persona
- observable playtest signs
- cycle count and playtest duration
- Wait for user validation.
After validation, continue through all cycles unless blocked or direction becomes impossible.
Cycle
- Frame hypothesis: promise, design bet, observable signs.
- Research: code, docs, prior playtests, useful external sources.
- Create spec with
to-spec: hypothesis, persona, experience, non-goals, acceptance criteria, test/playtest plan. - Implement the cycle. If the spec already points to implementation-ready tickets, use
handle-ticketsand capture its PRs, branches, checks, blockers, and Codex outcomes. Otherwise use focused ticket-sized work withimplement, then runreview-fixandcodex-pr-reviewwhen a PR exists. Keep slices vertical and playable. - Choose the playtest target from delivery evidence: delivery worktree, preview URL, merged default branch, or blocked awaiting merge. Playtest in the target runtime for requested duration. Prefer clean session, representative viewport/device, and existing automation harness when available.
- Record evidence: method, runtime/build/URL, viewport/device, session id, start/end, duration, input count, transcript/log/screenshot paths, state contamination risk, and at least 5 relevant player-facing moments.
- Decide verdict:
validated,mixed,invalidated, orincomplete. - Turn strongest miss into next-cycle seed.
Sub-Agents
Use sub-agents when they materially help and the work can be split cleanly. Run cycles sequentially because each cycle seeds the next.
Parallelize independent work inside a cycle: codebase research, design references, test/tooling inspection, asset review, or bounded implementation with non-overlapping files.
Worker brief must include direction, cycle number, persona, log path, ticket/PRD expectations, likely modules, verification commands, playtest duration, dirty-worktree warning, and required handoff.
Cycle Log
# Cycle N: <goal>
## Approved Direction
## Persona
## Hypothesis
## Research
## PRD
## Implementation
## Verification
## Playtest Evidence
## Observations
## Verdict
## Next Seed
## Blockers Or Fallbacks
Finish
Summarize cycles, PRDs/tickets, PRs, worktrees or preview targets, checks, playtest evidence, verdicts, blockers, and next best improvement. State plainly if any cycle is incomplete.