Using Game Superpowers
Collection entrypoint. Classify the request, then route explicitly.
Classification
- Build — new project, prototype, feature, vertical slice
- Audit — diagnosis, read-only review, risk or UX review
- Repair — targeted fixes after diagnosis
- Polish — working game, better feel / UX / feedback / quality
Project state:
greenfieldprelaunchshippedlive-risky
Output strategy
Choose one before invoking downstream skills:
- inline (default) — keep findings and plans in conversation; do not write
docs/.
- minimal — persist only the small set of files needed for cross-session continuity.
- full — write all requested docs artifacts.
Default to inline unless the user explicitly wants docs or the project clearly needs them. This overrides downstream defaults.
Routing
Build
gsp-concept-brainstorm when fantasy or goals are unclear, and by default for one-prompt generation, showcase builds, benchmark runs, or archetype-led requests such as runner, platformer, survivor, shooter, breakout, fps, dungeon crawler, or arenagsp-scope-profilegsp-build-strategygsp-super-build
Add as needed:
gsp-douyin-h5 for explicit Douyin-style portrait H5 deliverygsp-ux-flow-designer, gsp-feedback-designgsp-loop-bootstrap, gsp-mechanics-systems-designgsp-build-review, gsp-subagent-build-loopgsp-web-2d-specialist, gsp-web-3d-specialistgsp-polished-prototype, gsp-production-feature
Audit
gsp-project-state-assessmentgsp-project-auditgsp-audit-scorecardgsp-repair-roadmap
Add the matching audit skills:
gsp-ux-flow-audit, gsp-hud-readability-auditgsp-feedback-audit, gsp-audio-feedback-audit, gsp-feel-auditgsp-mechanics-systems-audit, gsp-scope-completeness-auditgsp-production-readiness-audit, gsp-architecture-maintainability-auditgsp-live-risk-audit when project-state == shipped or project-state == live-risky
Repair
gsp-repair-roadmapgsp-scope-guardgsp-implementation-plangsp-production-code when quality target >= polished-prototypegsp-playability-verifiergsp-live-patch when project-state == shipped or project-state == live-risky
Polish
gsp-hud-feedback-polishgsp-feedback-designgsp-screenshot-criticgsp-playability-verifiergsp-audio-feedback-auditgsp-feel-audit
Trigger examples
- Requests like
做一个 Douyin H5 Interactive 作品, 抖音互动作品, 抖音互动空间, 抖音互动H5, 竖屏 H5 互动页, or 平台只接受 H5，要先定框架、文件结构和适配方式 should strongly bias toward gsp-douyin-h5.
- If the same request also includes real-time browser gameplay, add
gsp-web-2d-specialist after the platform shell and route are locked.
- Requests that explicitly ask for
requirements/spec/design/tasks, OpenSpec, spec-driven, or durable repo-native planning artifacts should route through gsp-spec-driven-planning.
Spec-driven overlay
gsp-spec-driven-planning is an optional planning layer, not a replacement for Build, Audit, Repair, or Polish.- Use it when the user wants durable change artifacts in the target repo.
- Keep the normal track classification, then add the spec-driven layer on top where it helps.
Rules
- Classify before implementation and prefer specialized skills over ad hoc reasoning.
- Keep the quality target explicit:
first-playable, polished-prototype, production-feature, or live-patch.
- For live or risky projects, prefer audit-first and surgical changes.
- For browser games, lock spatial model, camera/view model, control grammar, obstacle grammar, and first-30-seconds promise before coding.
- Prefer a builder + reviewer + verifier loop when the host supports subagents and the user wants maximum result quality; parallelize only across disjoint ownership zones.
- Require fresh runtime verification before claiming a benchmark or showcase build is complete.
- For cross-project reference or benchmarking, audit the reference project first, then apply the extracted patterns to the target via Repair or Build.
- Do not force spec-driven files when the user only wants inline planning.
Output expectation
At the start, state the selected track, current project state, output strategy, and the next 2-5 Game Superpowers skills.
1---2name: gsp-orchestrator3description: Use when a request needs routing across this Game Superpowers collection for build, audit, repair, or polish work.4---5# Using Game Superpowers67Collection entrypoint. Classify the request, then route explicitly.89## Classification1011- **Build** — new project, prototype, feature, vertical slice12- **Audit** — diagnosis, read-only review, risk or UX review13- **Repair** — targeted fixes after diagnosis14- **Polish** — working game, better feel / UX / feedback / quality1516Project state:17- `greenfield`18- `prelaunch`19- `shipped`20- `live-risky`2122## Output strategy2324Choose one before invoking downstream skills:25- **inline** (default) — keep findings and plans in conversation; do not write `docs/`.26- **minimal** — persist only the small set of files needed for cross-session continuity.27- **full** — write all requested docs artifacts.2829Default to **inline** unless the user explicitly wants docs or the project clearly needs them. This overrides downstream defaults.3031## Routing3233### Build34- `gsp-concept-brainstorm` when fantasy or goals are unclear, and by default for one-prompt generation, showcase builds, benchmark runs, or archetype-led requests such as `runner`, `platformer`, `survivor`, `shooter`, `breakout`, `fps`, `dungeon crawler`, or `arena`35- `gsp-scope-profile`36- `gsp-build-strategy`37- `gsp-super-build`3839Add as needed:40- `gsp-douyin-h5` for explicit Douyin-style portrait H5 delivery41- `gsp-ux-flow-designer`, `gsp-feedback-design`42- `gsp-loop-bootstrap`, `gsp-mechanics-systems-design`43- `gsp-build-review`, `gsp-subagent-build-loop`44- `gsp-web-2d-specialist`, `gsp-web-3d-specialist`45- `gsp-polished-prototype`, `gsp-production-feature`4647### Audit48- `gsp-project-state-assessment`49- `gsp-project-audit`50- `gsp-audit-scorecard`51- `gsp-repair-roadmap`5253Add the matching audit skills:54- `gsp-ux-flow-audit`, `gsp-hud-readability-audit`55- `gsp-feedback-audit`, `gsp-audio-feedback-audit`, `gsp-feel-audit`56- `gsp-mechanics-systems-audit`, `gsp-scope-completeness-audit`57- `gsp-production-readiness-audit`, `gsp-architecture-maintainability-audit`58- `gsp-live-risk-audit` when `project-state == shipped` or `project-state == live-risky`5960### Repair61- `gsp-repair-roadmap`62- `gsp-scope-guard`63- `gsp-implementation-plan`64- `gsp-production-code` when quality target >= polished-prototype65- `gsp-playability-verifier`66- `gsp-live-patch` when `project-state == shipped` or `project-state == live-risky`6768### Polish69- `gsp-hud-feedback-polish`70- `gsp-feedback-design`71- `gsp-screenshot-critic`72- `gsp-playability-verifier`73- `gsp-audio-feedback-audit`74- `gsp-feel-audit`7576### Trigger examples77- Requests like `做一个 Douyin H5 Interactive 作品`, `抖音互动作品`, `抖音互动空间`, `抖音互动H5`, `竖屏 H5 互动页`, or `平台只接受 H5，要先定框架、文件结构和适配方式` should strongly bias toward `gsp-douyin-h5`.78- If the same request also includes real-time browser gameplay, add `gsp-web-2d-specialist` after the platform shell and route are locked.79- Requests that explicitly ask for `requirements/spec/design/tasks`, `OpenSpec`, `spec-driven`, or durable repo-native planning artifacts should route through `gsp-spec-driven-planning`.8081## Spec-driven overlay82- `gsp-spec-driven-planning` is an optional planning layer, not a replacement for Build, Audit, Repair, or Polish.83- Use it when the user wants durable change artifacts in the target repo.84- Keep the normal track classification, then add the spec-driven layer on top where it helps.8586## Rules87- Classify before implementation and prefer specialized skills over ad hoc reasoning.88- Keep the quality target explicit: `first-playable`, `polished-prototype`, `production-feature`, or `live-patch`.89- For live or risky projects, prefer audit-first and surgical changes.90- For browser games, lock spatial model, camera/view model, control grammar, obstacle grammar, and first-30-seconds promise before coding.91- Prefer a builder + reviewer + verifier loop when the host supports subagents and the user wants maximum result quality; parallelize only across disjoint ownership zones.92- Require fresh runtime verification before claiming a benchmark or showcase build is complete.93- For cross-project reference or benchmarking, audit the reference project first, then apply the extracted patterns to the target via Repair or Build.94- Do not force spec-driven files when the user only wants inline planning.9596## Output expectation9798At the start, state the selected track, current project state, output strategy, and the next 2-5 Game Superpowers skills.
mike007jd