Gsp implementation plan
Skill mike007jd/game-superpowers/skills/gsp-implementation-plan
Skills-first game development superpowers for Claude Code and Codex: build, audit, polish, and productionize game projects with reusable Agent Skills.
npx -y skills add mike007jd/game-superpowers --skill gsp-implementation-planAssembled 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 turning an approved game brief into verifiable implementation tasks matched to the chosen build mode.
SKILL.md
1.5 KB, as published. Nobody here has run it
Game Implementation Plan
Turn the approved build brief into an execution plan.
Use ../../shared/templates/task-plan.md.
Outputs
Follow the gsp-orchestrator output strategy:
- inline (default): present implementation plan in conversation.
- minimal or full: write
docs/game-studio/plan.md.
Spec-driven compatibility
When gsp-spec-driven-planning is active:
- write the implementation plan to
changes/<change-id>/tasks.md - keep each task traceable to the requirement or design area it implements
Key rule
Do not use one default task size for all situations. Use the chosen development mode.
Planning bias
- In yolo-super, larger end-to-end tasks are allowed and often preferred.
- In guided-build, keep the plan comprehensible but still fast.
- In refactor-open, plan migrations and replacements explicitly.
- In surgical-live, keep tasks tight and rollbackable.
Execution bias
Unless the user explicitly wants a cheap or minimal pass, assume the plan should support:
- a builder stage
- a reviewer stage
- a verifier stage
For benchmark, showcase, or polished-prototype work, plan with this loop in mind instead of assuming one pass from build to done.
Important
Do not produce fake progress tasks like “set up scaffolding” unless that scaffold immediately enables real implementation. Prefer tasks that end in a stronger running build.