/create-game-assets

name: create-game-assets
description: >
  Plans, generates or sources, and validates consistent game art: style guides, sprites, pixel
  art, tilesets, icons and textures, with QA and licence records. Use when making or AI-generating
  game art, fixing fake transparency, or checking Steam AI disclosure. Not for engine import
  (`godot-tilemap`, `godot-animation`, `unity-tilemap-2d`), UI layout (`game-ui-ux`) or sound
  (`audio-design`).

Create Game Assets

Turn a game's visual intent into a consistent, engine-ready asset set. Treat image generation as one production tool inside a controlled pipeline, never as proof that an asset is shippable.

When to use

• Defining or refreshing an art direction, or writing a style guide other contributors follow.
• Producing a family of sprites, tiles, icons, backgrounds or textures that must match.
• Generating art with an image tool, or sourcing licensed packs, and making the result usable.
• Auditing what was generated or licensed before release.

**Not this skill:** importing into the engine (`godot-tilemap`, `unity-tilemap-2d`, `pixijs-rendering`, `threejs-gltf-loading`), animating the sprites (`godot-animation`, `unity-animation`), atlas and texture-memory budgets at runtime (`performance-optimization`).

Core workflow

1. **Inspect before inventing.** Find existing screenshots, concept art, sprites, models, fonts, import settings, camera framing, target resolution, and naming conventions. Preserve a coherent existing direction unless the user asks for a redesign. 2. **Lock the technical frame.** Record engine, 2D/3D, camera/view, native display size, asset dimensions, world scale, transparency, palette, filtering, animation frames, texture budget, and target platforms. Use `assets/art-direction-brief.md` as a copyable brief. 3. **Name the visual system.** Define shape language, silhouette priorities, value structure, palette roles, materials, lighting, detail density, edge treatment, and motion character. Use concrete visual properties; do not substitute a living artist's name for an art direction. 4. **Make an asset manifest.** Copy `assets/asset-manifest.json`, then list every required asset, state, variant, size, pivot, collision role, source, license, and approval status. Separate production assets from disposable greybox placeholders. 5. **Approve one visual target.** Create or select a representative hero asset or small style board before producing a full set. Judge it at actual game scale and against a gameplay background. If the user delegated the choice, pick the strongest viable direction and record the decision instead of blocking. 6. **Produce related assets as families.** Reuse the approved target as an edit/reference input. Keep palette, view, proportions, lighting, outline, and texture density invariant. Generate small coherent batches; avoid unrelated one-off prompts that drift. 7. **Normalize deterministically.** Crop, size, anchor, slice, name, compress, and check alpha with ordinary image/DCC tools. Never trust generated grids, transparency, seams, pivots, topology, or dimensions without inspection. Use the bundled scripts for raster QA and contact sheets. 8. **Import with engine-native settings.** Set filtering, mipmaps, pixels-per-unit/world scale, color space, compression, sprite slicing, texture types, materials, and collision deliberately. Read the relevant engine skill before editing engine files. 9. **Validate in context.** Inspect a contact sheet and the actual game at native resolution. Check silhouette, scale, animation stability, seams, legibility, palette, collision fit, memory, and compression artifacts. Iterate on the source asset, not only on runtime compensations. 10. **Record provenance.** Keep the source URL/tool, license or generation note, edit history, and restrictions beside the manifest. Preserve embedded provenance metadata when the pipeline can. 11. **Finish with the checks.** Run `scripts/asset_report.py` over every file in the batch with the manifest's size, alpha and colour limits and `--json`; it must exit 0. Build a contact sheet with `scripts/build_preview_sheet.py` and look at it. Confirm every shipped manifest entry has a source, licence and `technical_checks_passed: true`. Then ask the user to view the assets in the running game at native resolution and report anything that does not read.

Choose the production path

| Need | Default path | |------|--------------| | Existing asset needs a controlled change | Edit the original/reference; state what must remain unchanged | | New 2D visual family | Approve seed → generate/source family → normalize → preview → import | | True pixel art | Use generated work as a draft; enforce grid, palette, clusters, and frames with pixel tools | | Tileable surface or tileset | Produce a small family; repair seams; test repeated 3×3 before approval | | UI art or icons | Keep text and interaction code-native; prefer SVG/vector for simple geometric symbols | | 3D model or material | Use concepts as reference; author/clean in a DCC; validate topology, UVs, scale, pivots, and LODs | | No generation/edit tool is available | Build the brief and manifest; source licensed assets or keep explicit greybox placeholders | | Audio asset | Route sound implementation and mixing to `audio-design`; still track source/license in the manifest |

Image-generation handoff

When a capable image generation or editing tool is installed, use it for live visual creation. If the workspace exposes an `imagegen` skill, read and follow it for the actual generation/edit call; this skill owns the game-art brief, constraints, normalization, and acceptance gates. Generation APIs usually bill per image: tell the user the batch size and ask before large or repeated runs.

Build prompts from these blocks:

ROLE/PURPOSE: production asset for [gameplay role]
SUBJECT: [specific object/character a