Design Game Studio

View saved version →

---
name: asset-pipeline
description: Acquire, create, import, optimize, and track rights for sprites, textures, 3D models, animation, sounds, and game UI assets.
---

# Asset Pipeline


1. List every asset required for the vertical slice and its role, source type, desired style and required format.
2. Prefer user-supplied assets with usage rights; original generated assets where tools permit; verified CC0/MIT/commercially usable sources as appropriate. Verify each specific asset license and attribution; never assume a whole website uses one license.
3. Maintain `../../templates/asset-register.csv` including origin, asset URL, license, credit, file path, modifications and verification state. Record AI generation where applicable.
4. For sprites, check frame indexing and tile seams; for 3D, check scale, orientation, topology/rig/animation, collision and LODs; for audio, check format, clipping, loudness and loop points.
5. Use Blender or other supported editors only when available. Do not imply automatic rigging, sound synthesis or 3D model generation in a skills-only plugin.
6. Convert/compress to engine-supported assets without altering licenses or losing source. Place generated originals under appropriate asset subpaths.
7. Run import/build smoke checks and visually inspect representative assets before accepting them.

## Execution truth and safeguards
- A skill is an instruction workflow, not a remotely running game engine or a separately running AI agent. Inspect tools and repo state before claiming execution.
- Preserve existing projects, names, dependencies, save formats, and user work unless a change is explicitly requested. Obtain approval for deployment, payments, destructive edits, publication, and major third-party connections.
- Avoid reproducing protected commercial characters, levels, dialogue, soundtracks, logos, or copyrighted assets unless authorized. For assets, record origin and license. Read `../../references/security-and-rights.md`.
- Report what was implemented, what was actually run, what failed, and what remains unverified; never describe proposed tests as passed.

View saved version →

---
name: audio-animation
description: Add coherent game animation, audio feedback and ambience with asset provenance, responsiveness and accessible settings.
---

# Audio Animation


1. Identify every interaction that needs feedback (input accepted, impact, collectible, success/failure, warning, menu navigation).
2. Use a consistent animation and audio language from `../../references/art-direction.md` and `../../references/audio-and-animation.md`.
3. Prefer original generated/synthesized sound effects or explicitly licensed clips. Do not copy recognizable commercial game audio or copyrighted soundtrack fragments.
4. Separate gameplay state from audio/animation state; handle pause/resume, mute, repeated triggers, loading delays, frame timing and effects prioritization.
5. On browser, account for autoplay restrictions and first user gesture. Include volume controls and reduced-motion alternatives where relevant.
6. Validate files decode in the actual engine and events play at expected times; do not mark auditory QA passed without hearing or instrumented playback.

## Execution truth and safeguards
- A skill is an instruction workflow, not a remotely running game engine or a separately running AI agent. Inspect tools and repo state before claiming execution.
- Preserve existing projects, names, dependencies, save formats, and user work unless a change is explicitly requested. Obtain approval for deployment, payments, destructive edits, publication, and major third-party connections.
- Avoid reproducing protected commercial characters, levels, dialogue, soundtracks, logos, or copyrighted assets unless authorized. For assets, record origin and license. Read `../../references/security-and-rights.md`.
- Report what was implemented, what was actually run, what failed, and what remains unverified; never describe proposed tests as passed.

View saved version →

---
name: build-2d-phaser
description: Implement or modify a playable browser 2D game in Phaser, including scenes, physics, input, and a browser build.
---

# Build 2D Phaser


1. Read `../../references/phaser.md` and official versioned Phaser docs. Phaser 4 is 2D-focused; check current APIs instead of copying outdated Phaser 3 examples uncritically.
2. Use the project’s existing build system or scaffold an official Phaser/Vite/TypeScript project when tools/network are available; don't invent installs. Set a baseline before editing.
3. Create a minimal scene with render loop, deterministic game state, keyboard input plus touch when mobile is a target, collision, feedback and reset. Ensure canvas fits viewport without distortion or illegible text.
4. Keep assets importable and consistent; use generated geometric textures until authorized assets are ready. Do not depend on unstable CDN assets to make a deliverable runnable.
5. Isolate mechanics from presentation where practical and avoid fragile one-file megascenes for projects with multiple systems.
6. Validate `npm` installation and build with actual commands when available; run browser smoke tests using real key/touch interactions and watch console/errors.
7. Check win, lose, pause, restart, focus loss and resize. Record an evidence log and exact files changed.

## Execution truth and safeguards
- A skill is an instruction workflow, not a remotely running game engine or a separately running AI agent. Inspect tools and repo state before claiming execution.
- Preserve existing projects, names, dependencies, save formats, and user work unless a change is explicitly requested. Obtain approval for deployment, payments, destructive edits, publication, and major third-party connections.
- Avoid reproducing protected commercial characters, levels, dialogue, soundtracks, logos, or copyrighted assets unless authorized. For assets, record origin and license. Read `../../references/security-and-rights.md`.
- Report what was implemented, what was actually run, what failed, and what remains unverified; never describe proposed tests as passed.

View saved version →

---
name: build-3d-playcanvas
description: Build a small interactive browser 3D game using PlayCanvas Engine with camera, movement, collisions, and gameplay.
---

# Build 3D Playcanvas


1. Read `../../references/playcanvas.md`; distinguish the open-source Engine code-first workflow from the hosted PlayCanvas Editor and its account requirements.
2. Validate target devices and rendering fallback. Prefer basic WebGL compatibility before WebGPU-only techniques; ensure test browser actually supports required features.
3. Create a working 3D scene with camera, one controlled entity, lighting, ground/world, clear objectives, interactions and restart. Use simple procedurally created primitives when no asset tools exist.
4. Separate controls, camera, interactions and world state. Ensure sensible depth perception, camera clipping, movement speed, collision handling and state transitions.
5. Choose a practical camera mode (third-person, top-down, first-person) consistent with the core loop. For mobile targets include touch UI and performance budgets.
6. Run actual build/serve tests and browser WebGL checks where available; capture console and runtime failures. Visually inspect multiple views and performance.
7. Return runnable source, verified commands, generated artifacts when present and known limitations.

## Execution truth and safeguards
- A skill is an instruction workflow, not a remotely running game engine or a separately running AI agent. Inspect tools and repo state before claiming execution.
- Preserve existing projects, names, dependencies, save formats, and user work unless a change is explicitly requested. Obtain approval for deployment, payments, destructive edits, publication, and major third-party connections.
- Avoid reproducing protected commercial characters, levels, dialogue, soundtracks, logos, or copyrighted assets unless authorized. For assets, record origin and license. Read `../../references/security-and-rights.md`.
- Report what was implemented, what was actually run, what failed, and what remains unverified; never describe proposed tests as passed.

View saved version →

---
name: build-godot
description: Create, extend, or debug a Godot 2D/3D project using GDScript and editor/headless verification where supported.
---

# Build Godot


1. Read `../../references/godot.md` and determine installed Godot version, project format, GDScript versus C#, target exports and available editor/templates.
2. Respect existing project.godot, scenes, resources and autoloads. Set a baseline and inspect signals, node paths and input actions before changing them.
3. Implement a minimal playable scene using appropriate CharacterBody2D/3D, input mapping, collisions, camera and a win/lose/restart mechanism. Avoid outdated APIs copied from Godot 3.
4. Model reusable scenes, resource references and signal connections explicitly. Do not hardcode fragile absolute node paths.
5. Run `godot --headless --path PROJECT --editor --quit` or version-appropriate import/parse commands when installed, then actual gameplay input tests if a display is available.
6. Only claim exports after necessary export templates/presets exist and commands complete successfully; web exports and C# availability must be checked separately.
7. Deliver the editable Godot project, controls, scene map, test output and any missing engine/export prerequisites.

## Execution truth and safeguards
- A skill is an instruction workflow, not a remotely running game engine or a separately running AI agent. Inspect tools and repo state before claiming execution.
- Preserve existing projects, names, dependencies, save formats, and user work unless a change is explicitly requested. Obtain approval for deployment, payments, destructive edits, publication, and major third-party connections.
- Avoid reproducing protected commercial characters, levels, dialogue, soundtracks, logos, or copyrighted assets unless authorized. For assets, record origin and license. Read `../../references/security-and-rights.md`.
- Report what was implemented, what was actually run, what failed, and what remains unverified; never describe proposed tests as passed.

View saved version →

---
name: build-mobile-game
description: Adapt or build a touch-first game for Android or iOS with correct aspect ratios, performance, platform controls, and export guidance.
---

# Build Mobile Game


1. Determine whether user wants a browser-playable mobile game, installable Android APK/AAB, or signed iOS app; these are not interchangeable.
2. Read `../../references/platform-and-input.md` and choose Godot or Unity for native-oriented builds, or Phaser/PlayCanvas for mobile web when justified.
3. Design touch targets, multi-touch gestures, on-screen controls, safe areas, portrait/landscape, pause/resume, interruptions and accessibility.
4. Define performance/memory and battery budgets for target devices. Avoid dense 3D rendering on devices without a suitable GPU budget.
5. Verify graphics, audio, assets and input on device/simulator only when available; list any untested devices honestly.
6. Packaging requires platform-specific export templates/signing credentials and developer accounts. Ask for approval before external store submission or credentials.
7. Return portable source and valid local build/export instructions; never claim App Store/Play Store readiness without real device and policy checks.

## Execution truth and safeguards
- A skill is an instruction workflow, not a remotely running game engine or a separately running AI agent. Inspect tools and repo state before claiming execution.
- Preserve existing projects, names, dependencies, save formats, and user work unless a change is explicitly requested. Obtain approval for deployment, payments, destructive edits, publication, and major third-party connections.
- Avoid reproducing protected commercial characters, levels, dialogue, soundtracks, logos, or copyrighted assets unless authorized. For assets, record origin and license. Read `../../references/security-and-rights.md`.
- Report what was implemented, what was actually run, what failed, and what remains unverified; never describe proposed tests as passed.

View saved version →

---
name: build-multiplayer-game
description: Architect and implement a small networked game prototype with authoritative state, synchronization, and abuse considerations.
---

# Build Multiplayer Game


1. Start by checking if multiplayer is genuinely required. A local/turn-based mode may satisfy an MVP faster and more reliably.
2. Read `../../references/multiplayer.md`; choose a suitable transport and hosted service only with user approval and an available environment.
3. Define a network authority model, session lifecycle, player identity, latency expectations, disconnect/reconnect, state sync and deterministic rules.
4. Never trust client-provided scores, health, inventory or paid entitlements. Require server-side validation for consequential game state.
5. Separate networking from core gameplay and build local single-player/loopback tests first; then two-client tests with simulated lag/loss where tools permit.
6. Document infrastructure costs, moderation/reporting for user-generated content when relevant, and security limits.
7. Do not claim cross-internet multiplayer is live without tested servers, clients and connectivity.

## Execution truth and safeguards
- A skill is an instruction workflow, not a remotely running game engine or a separately running AI agent. Inspect tools and repo state before claiming execution.
- Preserve existing projects, names, dependencies, save formats, and user work unless a change is explicitly requested. Obtain approval for deployment, payments, destructive edits, publication, and major third-party connections.
- Avoid reproducing protected commercial characters, levels, dialogue, soundtracks, logos, or copyrighted assets unless authorized. For assets, record origin and license. Read `../../references/security-and-rights.md`.
- Report what was implemented, what was actually run, what failed, and what remains unverified; never describe proposed tests as passed.

View saved version →

---
name: build-narrative-game
description: Design or implement visual novels, branching dialogue, interactive fiction, and story-driven game mechanics with coherent state.
---

# Build Narrative Game


1. Define player agency, branching structure, variables/flags, pacing, scene transitions and narrative endings; avoid fake choice branches that immediately converge without consequence.
2. Read `../../references/renpy.md` for Ren’Py-focused visual novel implementation. Existing custom engines may be retained.
3. Model dialogue and conditional state separately from presentation when possible. Track dead ends, unreachable branches, missing assets and uninitialized variables.
4. Provide accessible typography, readable pacing, rollback/skip settings if supported, clear choices and consistent UI.
5. Validate branch completeness with a graph walkthrough and actual engine lint/build commands when available; include save/load tests.
6. Use original or appropriately licensed narrative, character assets and music. If user requests an existing commercial IP, prefer an original alternative unless rights are confirmed.
7. Deliver scripts, branch map, input/output state definitions, tested endings, and unresolved narrative assumptions.

## Execution truth and safeguards
- A skill is an instruction workflow, not a remotely running game engine or a separately running AI agent. Inspect tools and repo state before claiming execution.
- Preserve existing projects, names, dependencies, save formats, and user work unless a change is explicitly requested. Obtain approval for deployment, payments, destructive edits, publication, and major third-party connections.
- Avoid reproducing protected commercial characters, levels, dialogue, soundtracks, logos, or copyrighted assets unless authorized. For assets, record origin and license. Read `../../references/security-and-rights.md`.
- Report what was implemented, what was actually run, what failed, and what remains unverified; never describe proposed tests as passed.

View saved version →

---
name: build-unity-unreal
description: Work on an existing or explicitly requested Unity or Unreal game project with correct editor version, scripting patterns, and packaging limits.
---

# Build Unity Unreal


1. Determine Unity versus Unreal and inspect actual project metadata, editor version, plugins, packages and source-control status. These are distinct engines; never silently migrate.
2. Read `../../references/unity-unreal.md` and official versioned docs. For Unity, preserve C# assemblies, scenes and serialization; for Unreal, preserve Blueprints, C++ modules, project settings and cooked assets.
3. Scope a small feature/bug fix before new content generation. Request missing project assets or toolchain details only when blocking.
4. Use editor/build/automation tooling only if installed and authorized. Avoid invoking expensive graphical/cook processes or downloading huge SDKs without approval.
5. Conduct compile/import tests and gameplay testing when possible; distinguish script compilation from actual editor-level or packaged-game verification.
6. Respect commercial license and marketplace content restrictions, including third-party asset terms. Return meaningful source diffs, commands and blockers.

## Execution truth and safeguards
- A skill is an instruction workflow, not a remotely running game engine or a separately running AI agent. Inspect tools and repo state before claiming execution.
- Preserve existing projects, names, dependencies, save formats, and user work unless a change is explicitly requested. Obtain approval for deployment, payments, destructive edits, publication, and major third-party connections.
- Avoid reproducing protected commercial characters, levels, dialogue, soundtracks, logos, or copyrighted assets unless authorized. For assets, record origin and license. Read `../../references/security-and-rights.md`.
- Report what was implemented, what was actually run, what failed, and what remains unverified; never describe proposed tests as passed.

View saved version →

---
name: debug-game
description: Reproduce and fix a game bug such as crashes, physics glitches, broken controls, missing assets, or failing exports.
---

# Debug Game


1. Ask for missing reproducible steps only if essential; otherwise inspect logs, scene files, code and build settings. Reproduce before modifying when possible.
2. Classify: runtime error, import/asset, physics/collision, state/progression, camera/input, device/export, performance, network, or visual defect.
3. Form one or more testable hypotheses, inspect engine/runtime evidence and identify a minimal root cause.
4. Implement a focused fix, add a regression check and rerun the original reproduction plus related systems.
5. When hardware/engine tooling is unavailable, state the diagnosis confidence and exact commands or steps the user should run; never fabricate traces or reproduction.
6. Output before/after behavior, changed files, test evidence and known limitations. Read `../../references/testing-and-evidence.md`.

## Execution truth and safeguards
- A skill is an instruction workflow, not a remotely running game engine or a separately running AI agent. Inspect tools and repo state before claiming execution.
- Preserve existing projects, names, dependencies, save formats, and user work unless a change is explicitly requested. Obtain approval for deployment, payments, destructive edits, publication, and major third-party connections.
- Avoid reproducing protected commercial characters, levels, dialogue, soundtracks, logos, or copyrighted assets unless authorized. For assets, record origin and license. Read `../../references/security-and-rights.md`.
- Report what was implemented, what was actually run, what failed, and what remains unverified; never describe proposed tests as passed.

View saved version →

---
name: game-art-direction
description: Create a coherent, platform-appropriate game visual identity across world, characters, UI, animation, camera, and effects.
---

# Game Art Direction


1. Define visual pillars (2-3), mood, era, color palette, silhouette language, camera composition, lighting, materials and UI treatment.
2. Choose pixel art, hand-painted 2D, vector, flat 2D, isometric, low-poly, retro 3D, stylized 3D or realistic 3D based on genre and performance; do not mix incompatible sources without adaptation.
3. Specify production rules: sprite pixel density/frame size, tile dimensions, world units, PBR/flat materials, outlines, animation frame rate and export formats as applicable.
4. Design world readability first: interactables, hazards, player/enemy silhouette, HUD contrast and color-blind cues. Do not use decorative effects that obscure gameplay.
5. Review examples and user references; use `../../references/art-direction.md` and `../../templates/art-bible.md`.
6. When image generation tools exist, create consistent, original assets or sprite sheets. When unavailable, implement truthful placeholders with an art specification; no claims that assets were generated.
7. Test art in the actual scene and at target resolution. Review texture filtering, scaling, camera legibility, animation and performance.

## Execution truth and safeguards
- A skill is an instruction workflow, not a remotely running game engine or a separately running AI agent. Inspect tools and repo state before claiming execution.
- Preserve existing projects, names, dependencies, save formats, and user work unless a change is explicitly requested. Obtain approval for deployment, payments, destructive edits, publication, and major third-party connections.
- Avoid reproducing protected commercial characters, levels, dialogue, soundtracks, logos, or copyrighted assets unless authorized. For assets, record origin and license. Read `../../references/security-and-rights.md`.
- Report what was implemented, what was actually run, what failed, and what remains unverified; never describe proposed tests as passed.

View saved version →

---
name: game-design
description: Turn a game concept into a playable loop, progression model, state transitions, and scoped acceptance criteria.
---

# Game Design


1. Define fantasy, player agency, target session duration, intended feeling, core verbs, reward signals, and failure/retry.
2. Write a two-sentence **core loop**: player action -> world response -> reward/risk -> next decision. Avoid systems that do not reinforce it.
3. Specify game states: launch, gameplay, paused, won, lost, restarted, saved/loaded when in scope. Define deterministic level/score transitions and scoring rules.
4. Separate must-have vertical-slice mechanics from optional production expansion. Set one measurable completion condition for each.
5. Model difficulty with observable parameters: time, speed, enemy cadence, spawn counts, health, level length; avoid promising game is 'fun' without human playtesting.
6. Address onboarding, discoverability, feedback loops and accessible options. Use `../../references/gameplay-quality.md` and `../../templates/game-brief.md`.
7. Produce a compact game-design spec, state chart in prose, feature priority and test criteria. If asked to build, pass to engine-specific workflow rather than stopping at design.

## Execution truth and safeguards
- A skill is an instruction workflow, not a remotely running game engine or a separately running AI agent. Inspect tools and repo state before claiming execution.
- Preserve existing projects, names, dependencies, save formats, and user work unless a change is explicitly requested. Obtain approval for deployment, payments, destructive edits, publication, and major third-party connections.
- Avoid reproducing protected commercial characters, levels, dialogue, soundtracks, logos, or copyrighted assets unless authorized. For assets, record origin and license. Read `../../references/security-and-rights.md`.
- Report what was implemented, what was actually run, what failed, and what remains unverified; never describe proposed tests as passed.

View saved version →

---
name: game-from-idea
description: Build a playable game from a natural-language idea, organizing the core game loop, engine, assets, and actual verification.
---

# Game From Idea


## End-to-end workflow
1. Create a concise playable brief using `../../templates/game-brief.md`; require a player verb, challenge, feedback, success/failure condition, and restart. If missing, derive a minimal plausible version.
2. Route through `select-engine` and record why the engine/platform is appropriate. Avoid automatic Unity/Unreal selection for simple browser games.
3. Use `game-design` and `game-art-direction` to establish mechanics and coherent visual language. Define keyboard/gamepad/touch needs; accessibility; no mandatory network unless the concept requires it.
4. Build the **first vertical slice**: launch/title or immediate start, core interaction, game state, a meaningful goal, failure/success, restart. Include pause and sound toggles where relevant.
5. Add one level/scene, smallest useful content set, simple but consistent artwork, and feedback sounds. Defer large maps, shops, inventory, online accounts, and elaborate progression until the core loop is playable.
6. Run a real executable smoke check if environment allows it. For browser games, capture browser errors and test keyboard/touch; for desktop use editor/headless checks plus interactive verification when available.
7. Independently review against acceptance criteria, repair failures, then package source, setup instructions, build artifacts actually produced and evidence.
8. When execution tools are missing, provide complete source files in a deliverable format where possible and clear unverified run instructions. Never report a functioning preview that wasn't run.
## Deliverable contract
Provide playable scope, engine, project tree, assets and licenses, implemented mechanics, controls, exact test commands and results, remaining defects and next expansion options. Read `../../references/testing-and-evidence.md`.

## Execution truth and safeguards
- A skill is an instruction workflow, not a remotely running game engine or a separately running AI agent. Inspect tools and repo state before claiming execution.
- Preserve existing projects, names, dependencies, save formats, and user work unless a change is explicitly requested. Obtain approval for deployment, payments, destructive edits, publication, and major third-party connections.
- Avoid reproducing protected commercial characters, levels, dialogue, soundtracks, logos, or copyrighted assets unless authorized. For assets, record origin and license. Read `../../references/security-and-rights.md`.
- Report what was implemented, what was actually run, what failed, and what remains unverified; never describe proposed tests as passed.

View saved version →

---
name: gameplay-systems
description: Design and implement modular gameplay mechanics such as movement, combat, inventory, crafting, enemies, saving, and progression.
---

# Gameplay Systems


1. Translate feature requests into player actions, game-state transitions, preconditions, feedback and outcomes. Define invariants for health, score, ownership, inventory or quest state.
2. Keep systems separated where useful: input, rules, physics, rendering, audio, persistence and UI. Prefer engine-native conventions over custom frameworks.
3. For movement, verify delta-time handling, jump/coyote time if appropriate, camera behavior, collisions and boundaries. For combat, model damage, invulnerability and death/retry.
4. For inventory/crafting, validate capacity, duplicate handling, resource costs and failure states. For saves, version data and check missing/corrupt files.
5. Use `../../references/gameplay-quality.md` for tuning and `../../templates/acceptance-checks.md` for mechanical test cases.
6. Implement one complete mechanic at a time; test edge cases then integrate it into a level that demonstrates it.

## Execution truth and safeguards
- A skill is an instruction workflow, not a remotely running game engine or a separately running AI agent. Inspect tools and repo state before claiming execution.
- Preserve existing projects, names, dependencies, save formats, and user work unless a change is explicitly requested. Obtain approval for deployment, payments, destructive edits, publication, and major third-party connections.
- Avoid reproducing protected commercial characters, levels, dialogue, soundtracks, logos, or copyrighted assets unless authorized. For assets, record origin and license. Read `../../references/security-and-rights.md`.
- Report what was implemented, what was actually run, what failed, and what remains unverified; never describe proposed tests as passed.

View saved version →

---
name: get-started
description: Choose the right Design Game Studio workflow when a user wants to make a game, explore capabilities, or work on an existing game project.
---

# Get Started


## First interaction
1. Identify whether the user wants (a) a new playable game, (b) a game design only, (c) an edit/debug of an existing game, or (d) release assistance. Do not reduce a build request to a design document.
2. Extract platform, presentation (2D / 2.5D / 3D), genre, intended player actions, art style, input method, scale, and supplied files. If the idea is broad, make transparent defaults and proceed; ask only for a blocking choice such as target platform when it cannot be reasonably inferred.
3. Check actual host tools: filesystem, terminal, browser, image/asset generation, installed editors, simulator, source control, and genuine subagent APIs. No claims of independent cloud game creation without a working runtime.
4. Route new-game requests to `game-from-idea`; existing-game edits to `improve-existing-game`; failures to `debug-game`; one engine or component request to its specific skill; test/ship requests to corresponding skills.
5. Select a minimum playable loop before expanding visuals or scope. Use `../../references/engine-matrix.md` and `../../references/platform-and-input.md`.
6. For substantial multi-part tasks use `orchestrate-game-agents` only if actual agent delegation tools exist; otherwise follow the same sequence in one session.
## Output
State game concept, chosen first playable scope, engine rationale, available tool capabilities, and the concrete next build step. Then carry out authorized work immediately where tools exist.

## Execution truth and safeguards
- A skill is an instruction workflow, not a remotely running game engine or a separately running AI agent. Inspect tools and repo state before claiming execution.
- Preserve existing projects, names, dependencies, save formats, and user work unless a change is explicitly requested. Obtain approval for deployment, payments, destructive edits, publication, and major third-party connections.
- Avoid reproducing protected commercial characters, levels, dialogue, soundtracks, logos, or copyrighted assets unless authorized. For assets, record origin and license. Read `../../references/security-and-rights.md`.
- Report what was implemented, what was actually run, what failed, and what remains unverified; never describe proposed tests as passed.

View saved version →

---
name: improve-existing-game
description: Understand and extend an existing game repository, feature, scene, or mechanic with minimal justified changes and regression checks.
---

# Improve Existing Game


1. Inspect project and engine version, run instructions, build baseline, scenes and source ownership; do not replace the whole project with a fresh scaffold.
2. Identify exact requested behavior and relevant scenes/scripts/assets. Specify expected observable acceptance criteria before editing.
3. Create the smallest change compatible with current architecture. Preserve save files, user data, asset licenses, input mappings and unrelated styling.
4. Run original tests and a focused regression test for the change, plus one smoke test in the relevant level or scene when tools permit.
5. If existing implementation is broken, distinguish pre-existing failures from introduced ones; avoid claiming the entire game passes if only isolated checks ran.
6. Deliver diff summary, changed files, evidence, remaining risks, and reversible instructions.

## Execution truth and safeguards
- A skill is an instruction workflow, not a remotely running game engine or a separately running AI agent. Inspect tools and repo state before claiming execution.
- Preserve existing projects, names, dependencies, save formats, and user work unless a change is explicitly requested. Obtain approval for deployment, payments, destructive edits, publication, and major third-party connections.
- Avoid reproducing protected commercial characters, levels, dialogue, soundtracks, logos, or copyrighted assets unless authorized. For assets, record origin and license. Read `../../references/security-and-rights.md`.
- Report what was implemented, what was actually run, what failed, and what remains unverified; never describe proposed tests as passed.

View saved version →

---
name: level-design
description: Design levels and game environments with readable objectives, pacing, difficulty, progression, and meaningful player decisions.
---

# Level Design


1. Derive the level's teaching objective, player path, points of challenge, optional discovery, and exit state from game mechanics.
2. Create blockouts before final art. Establish start/safe area, checkpoints, signposting, enemy/hazard placement and completion condition.
3. For 2D, validate tile collision, jump distances and camera bounds; for 3D, validate traversal, collision geometry, line of sight, scale and navigation.
4. Introduce new mechanics safely, then vary challenge and create a final competence test. Avoid long empty corridors and decorative rooms with no gameplay contribution.
5. Read `../../references/level-design.md` and record a playable flow from spawn to win/lose/restart.
6. Test with scripted walkthroughs or human playtest, include stuck-state detection and ensure the level is completable without undocumented controls.

## Execution truth and safeguards
- A skill is an instruction workflow, not a remotely running game engine or a separately running AI agent. Inspect tools and repo state before claiming execution.
- Preserve existing projects, names, dependencies, save formats, and user work unless a change is explicitly requested. Obtain approval for deployment, payments, destructive edits, publication, and major third-party connections.
- Avoid reproducing protected commercial characters, levels, dialogue, soundtracks, logos, or copyrighted assets unless authorized. For assets, record origin and license. Read `../../references/security-and-rights.md`.
- Report what was implemented, what was actually run, what failed, and what remains unverified; never describe proposed tests as passed.

View saved version →

---
name: orchestrate-game-agents
description: Coordinate real specialist agents for a complex game project while maintaining single-agent fallback and independent verification.
---

# Orchestrate Game Agents


1. Read `../../references/orchestration.md`. A role description is not an independent agent; check whether real subagent tools or an authorized backend are available.
2. Lead Game Director owns project scope, game-design brief, engine choice, task graph, user approvals and integration.
3. Delegate independent subproblems only when helpful: Game Designer, Engine Architect, Art Director, Gameplay Developer, Level Designer, Audio, QA/Playtester and Release. Use few agents for small games.
4. Freeze interfaces and shared asset naming before parallel implementation. Give separate non-overlapping files/branches/worktrees and concrete acceptance checks.
5. Keep security and QA review read-only and independent of implementers. Reconcile cross-agent decisions centrally; never claim '8 agents completed' based on simulated personas.
6. Limit token/time/cost budgets and external side effects. Report actual subagent tasks, commands, artifacts and failures, with sequential fallback identified when used.

## Execution truth and safeguards
- A skill is an instruction workflow, not a remotely running game engine or a separately running AI agent. Inspect tools and repo state before claiming execution.
- Preserve existing projects, names, dependencies, save formats, and user work unless a change is explicitly requested. Obtain approval for deployment, payments, destructive edits, publication, and major third-party connections.
- Avoid reproducing protected commercial characters, levels, dialogue, soundtracks, logos, or copyrighted assets unless authorized. For assets, record origin and license. Read `../../references/security-and-rights.md`.
- Report what was implemented, what was actually run, what failed, and what remains unverified; never describe proposed tests as passed.

View saved version →

---
name: playtest-optimize
description: Verify gameplay, usability, performance, bugs, and game feel through measured playtests and reproducible evidence.
---

# Playtest Optimize


1. Read `../../references/testing-and-evidence.md` and choose checks for actual platform and engine. Distinguish compile success, scene launch, interactive playtest and full release qualification.
2. Run real build/import tests, then verify player input, menu, progression, collision, score, win/lose, restart, save/load, pause, resize and asset/audio loading as relevant.
3. For 3D, review camera occlusion, clipping, collision/navigability, visual readability and frame performance under representative load.
4. Collect evidence with timestamps in logs or test artifacts as appropriate; no invented screenshots, benchmark frames or 'playtested' claims.
5. Profile performance before optimizing; prioritize frame-time spikes, asset bloat, overdraw, expensive physics and leaks. Report device/browser/hardware conditions for measurements.
6. Evaluate subjective fun and difficulty through actual human players; automated agents can assess controls and pacing proxies, not certify fun.
7. Apply a bounded fix-and-retest loop; fail the gate when essential mechanics are unverified or broken.

## Execution truth and safeguards
- A skill is an instruction workflow, not a remotely running game engine or a separately running AI agent. Inspect tools and repo state before claiming execution.
- Preserve existing projects, names, dependencies, save formats, and user work unless a change is explicitly requested. Obtain approval for deployment, payments, destructive edits, publication, and major third-party connections.
- Avoid reproducing protected commercial characters, levels, dialogue, soundtracks, logos, or copyrighted assets unless authorized. For assets, record origin and license. Read `../../references/security-and-rights.md`.
- Report what was implemented, what was actually run, what failed, and what remains unverified; never describe proposed tests as passed.

View saved version →

---
name: prepare-game-release
description: Package an editable game and verified builds for browser, desktop, mobile or game marketplaces with licensing and submission checks.
---

# Prepare Game Release


1. Confirm intended destination: source archive, browser demo, itch.io, Steam, app store, desktop executable, or private collaboration; no deployment/publishing without approval.
2. Read `../../references/release-and-compliance.md`; inventory source, engine and exact version, third-party assets/licenses, controls, rating/content obligations and dependencies.
3. Produce build/export only with verified engine, required templates/signing profiles and permission. For browser: include entrypoint and assets, check base paths, mobile browser constraints and server MIME behavior.
4. Verify launching the packaged artifact (not only the development server). Run applicable platform smoke tests, update licensing notices and give a README with controls.
5. Include `../../templates/evidence-report.md` with passed/failed/not run checks, environments and blockers. Never describe an unbuilt ZIP as an installed app or a hosted game.
6. Include production warnings for credentials, network services, analytics, store rules and underage audiences when relevant.

## Execution truth and safeguards
- A skill is an instruction workflow, not a remotely running game engine or a separately running AI agent. Inspect tools and repo state before claiming execution.
- Preserve existing projects, names, dependencies, save formats, and user work unless a change is explicitly requested. Obtain approval for deployment, payments, destructive edits, publication, and major third-party connections.
- Avoid reproducing protected commercial characters, levels, dialogue, soundtracks, logos, or copyrighted assets unless authorized. For assets, record origin and license. Read `../../references/security-and-rights.md`.
- Report what was implemented, what was actually run, what failed, and what remains unverified; never describe proposed tests as passed.

View saved version →

---
name: select-engine
description: Select a suitable game engine and target architecture for a 2D, 3D, mobile, browser, narrative, or existing game idea.
---

# Select Engine


1. Determine primary target: browser link, Windows/macOS/Linux desktop, mobile package, console, VR, or narrative. Check performance target, internet access, rendering style, coding skills and existing technology.
2. Consult `../../references/engine-matrix.md` and `../../references/platform-and-input.md`.
3. Default to Phaser for 2D browser games; PlayCanvas Engine for code-first web 3D; Godot for standalone indie 2D/3D when editor is available; Ren'Py for visual novels; preserve existing Unity/Unreal projects when appropriate.
4. Do not conflate 2.5D or isometric camera with an engine; these can be achieved in multiple engines. For Unity/Unreal request large runtime budgets explicitly.
5. Check relevant official docs and installed engine/API versions before drafting imports or config. Don't hardcode unverified package versions or export names.
6. Explain export and platform limitations (e.g., device-specific tools, signatures, simulators, controller support, browser physics/performance, license obligations) where materially relevant.
7. Output a short decision record with selected engine, alternates, constraints and exact first-scene implementation plan. Continue development if requested.

## Execution truth and safeguards
- A skill is an instruction workflow, not a remotely running game engine or a separately running AI agent. Inspect tools and repo state before claiming execution.
- Preserve existing projects, names, dependencies, save formats, and user work unless a change is explicitly requested. Obtain approval for deployment, payments, destructive edits, publication, and major third-party connections.
- Avoid reproducing protected commercial characters, levels, dialogue, soundtracks, logos, or copyrighted assets unless authorized. For assets, record origin and license. Read `../../references/security-and-rights.md`.
- Report what was implemented, what was actually run, what failed, and what remains unverified; never describe proposed tests as passed.