gamedev-skills/awesome-gamedev-agent-skills実行前に内容を確認
SKILL DETAIL
create-game-assets
gamedev-skills/awesome-gamedev-agent-skills/create-game-assets
Plan, generate, source, normalize, and validate cohesive visual game assets. Use for art direction, style bibles, sprites, tilesets, backgrounds, UI art, icons, textures, concept art, or 3D asset briefs.
インストール · 263出典を見る
Installation
npx skills add https://github.com/gamedev-skills/awesome-gamedev-agent-skills --skill create-game-assets
スキルファイル
SKILL.md
最終同期 · 2026/10/23
agents/openai.yaml›
interface:
display_name: "Create Game Assets"
short_description: "Direct cohesive production-ready game art"
default_prompt: "Use $create-game-assets to define an art direction and build a consistent sprite set for my game."
assets/art-direction-brief.md›
# Art direction brief
## Game frame
- Player fantasy:
- Core verbs:
- Engine and renderer:
- Target platforms:
- Camera/view/facing:
- Native viewport and common display scale:
- Typical asset size on screen:
## Visual system
- Shape language:
- Silhouette priorities:
- Value structure:
- Palette roles and exact swatches:
- Materials and surface cues:
- Edge/line treatment:
- Lighting direction and contrast:
- Detail density and focal hierarchy:
- Motion character:
- Explicit exclusions:
## Technical contract
- Asset dimensions/aspect:
- Alpha/background:
- Grid/tile/frame size:
- Anchor/pivot/baseline:
- Filtering/mipmaps/compression:
- Color space:
- Texture/poly/material budgets:
- Naming and folders:
## Visual target
- Approved seed/reference paths:
- Required do/don't examples:
- Native-scale gameplay capture:
- Approval owner/date:
assets/asset-manifest.json›
{
"schema_version": 1,
"art_direction_brief": "docs/art-direction-brief.md",
"assets": [
{
"id": "player-idle",
"role": "player base pose",
"path": "assets/player/player-idle.png",
"status": "planned",
"technical": {
"dimensions": "64x64",
"alpha": true,
"anchor": "bottom-center",
"frames": 1,
"filtering": "nearest"
},
"visual_locks": [
"palette",
"silhouette",
"proportions",
"facing",
"light-direction"
],
"source": {
"kind": "generated-or-authored",
"url_or_tool": "",
"creator": "",
"created_at": "",
"license": "",
"attribution": "",
"prompt_or_source_record": ""
},
"verification": {
"native_scale_reviewed": false,
"in_engine_reviewed": false,
"technical_checks_passed": false,
"approved_by": ""
}
}
]
}
references/art-direction.md›
# Art direction and consistency
Use this reference when a game needs a new visual direction, a style refresh, or a way to keep
many assets coherent across generation sessions and contributors.
## Describe a system, not a mood word
Define each axis explicitly:
| Axis | Questions to settle |
|------|---------------------|
| Shape | Rounded, angular, chunky, slender, geometric, organic? Which shapes signal friendly, dangerous, rare, or interactive? |
| Silhouette | What must read at game scale? Which parts may never merge into the body mass? |
| Value | How many value bands? Is the subject readable in grayscale against common backgrounds? |
| Color | What roles do accent, danger, reward, neutral, environment, and UI colors play? |
| Edge | Hard pixel clusters, clean vector edges, ink line, painterly lost edges, soft 3D bevels? |
| Material | How do metal, cloth, skin, stone, foliage, glass, and magic differ? |
| Light | Direction, softness, contrast, ambient color, rim light, baked shading policy? |
| Detail | Where is detail concentrated? What disappears at the native viewing size? |
| Camera | Orthographic/perspective, angle, focal length, horizon, facing and turn conventions? |
| Motion | Snappy, elastic, weighty, restrained? How far may forms deform in animation? |
Avoid phrases such as “beautiful,” “cinematic,” or “high quality” without observable constraints.
Avoid using a living artist's name as the style definition. Translate references into properties
such as palette, geometry, composition, material, lighting, and mark-making.
## Build a visual target
1. Capture the real game viewport and native resolution.
2. Place a representative character/object, environment patch, effect, and HUD fragment together.
3. Show common and worst-case backgrounds.
4. Add a small palette with semantic roles rather than an unlabelled color cloud.
5. Record do/don't examples: acceptable silhouette, forbidden outline drift, allowed texture noise.
6. Approve this target before producing a large catalog.
The target is a contract, not inspiration. Later outputs should be compared against it at the same
size and under the same background/light assumptions.
## Keep a family coherent
- Reuse one approved seed/reference for related variants.
- Keep a stable prompt card with the invariant blocks separate from the asset-specific block.
- Generate related items in small batches when shared scale and lighting matter.
- Change one variable per edit pass; broad “make it better” edits increase drift.
- Carry explicit color values or a palette image when color identity matters.
- Keep naming, pivots, canvas size, and padding deterministic outside the model.
- Reject outputs that are attractive alone but belong to a different visual system.
## Evaluate at three distances
1. **Thumbnail/native game scale:** gameplay identity and state must read immediately.
2. **Working scale:** edge quality, anatomy, seams, clusters, and material cues are inspectable.
3. **Context:** the asset sits in a real gameplay capture with lighting, effects, UI, and neighbors.
An asset that only succeeds when zoomed in is not successful game art.
## Common drift signals
- character height, head ratio, limb thickness, or costume layers change between states
- outline color/width changes between adjacent assets
- highlights imply different light directions
- palette grows with near-duplicate colors and muddy intermediates
- texture/noise density increases on later generations
- camera angle or object projection changes across an isometric/top-down set
- ground contact and shadow footprint move unpredictably
- UI icons mix filled, outlined, beveled, and painterly treatments
When drift appears, return to the approved seed and use a constrained edit. Do not keep editing a
drifted derivative until it becomes the new accidental reference.
references/provenance.md›
# Asset rights and provenance
Use this reference for generated, purchased, commissioned, open, or remixed assets. This is a
production recordkeeping workflow, not legal advice.
## Record per shipped asset
- stable asset ID and repository path
- creator/source URL or vendor order
- acquisition or generation date
- source tool/model/version when generated
- original prompt/reference IDs when available
- license name/version and a saved copy or link to the terms
- attribution text and placement requirements
- whether commercial use, modification, redistribution, or AI training is restricted
- edits, derivatives, and the person/tool responsible
- approval status and reviewer
The bundled `assets/asset-manifest.json` has fields for these records. Keep proof of purchase and
license snapshots outside a public repository when they contain personal or account data.
## Decision rules
1. Do not treat “free,” “royalty-free,” search-engine-visible, or model-generated as a license.
2. Verify terms at the original source, not a repost or aggregator preview.
3. Keep attribution through atlas packing, renaming, conversion, and derivative edits.
4. Check whether a marketplace license permits redistribution of raw source files; shipping a game
and publishing editable source assets can have different permissions.
5. Do not request direct imitation of a living artist. Describe visual properties or use references
the project has permission to edit.
6. Preserve content credentials/provenance metadata where the file pipeline supports it. If
optimization strips metadata, retain the corresponding manifest record.
7. Review each store/platform's current disclosure rules before submission; rules change faster
than this skill.
## Useful primary references
- [Creative Commons license chooser](https://creativecommons.org/chooser/)
- [SPDX license list](https://spdx.org/licenses/)
- [OpenAI content provenance](https://openai.com/index/advancing-content-provenance/)
- [Steamworks documentation](https://partner.steamgames.com/doc/home)
When terms are unclear or the release is commercially important, flag the ambiguity for a human
rights review rather than guessing.
references/raster-pipeline.md›
# Raster, sprite, tile, background, and UI pipeline
Use this reference for production 2D art and raster textures. Generated output is source material;
dimensions, grids, alpha, anchors, and import settings remain deterministic engineering concerns.
## Sprites and animation
1. Approve one idle/neutral seed at the final view and approximate game scale.
2. Lock canvas size, baseline/ground point, facing, palette, outline, proportions, and costume.
3. For a short animation, request the whole action as one strip or sheet referenced to the seed.
Independent frame requests drift more. Treat the returned grid as a candidate, not exact data.
4. Slice and normalize frames with one shared scale and one shared anchor—usually bottom-center.
5. If frame 1 must equal a shipped idle pose, restore the exact seed after slicing.
6. Preview as a contact sheet and in motion. Check volume, foot sliding, silhouette, and cadence.
For true pixel art, enforce a real pixel grid after generation. Remove blended pseudo-pixels,
single-pixel noise, excess colors, banding, and inconsistent clusters. Resize only with
nearest-neighbor unless a deliberate preprocessing pass says otherwise.
## Tiles and repeatable textures
- Define tile dimensions and neighbor rules before creating art.
- Produce a base, transitions, corners, isolated pieces, and decoration as one visual family.
- Keep gameplay edges and collision meaning legible; decorative shadows must not imply false walls.
- Test seamless materials in a 3×3 repeat at full size and at minified camera scale.
- Inspect terrain combinations in the engine's autotile/terrain system, not only in a sheet.
- Keep padding/extrusion compatible with the engine/atlas tool to prevent texture bleeding.
## Backgrounds and parallax
- Split sky, far, mid, near, and foreground layers according to intended parallax speed.
- Avoid unique landmarks near horizontal seams when layers must scroll/repeat.
- Preserve a low-contrast playfield behind characters and projectiles.
- Keep focal detail away from HUD safe areas and critical navigation silhouettes.
- Export layers independently with overlap so camera movement cannot expose gaps.
## UI art and icons
- Keep labels, numbers, dynamic copy, focus state, and accessibility text code-native.
- Generate or draw ornament, frames, portraits, and texture—not rasterized functional text.
- Prefer one established icon family. Simple geometric symbols should usually be SVG/vector.
- Provide normal, hover/focus, pressed, disabled, selected, and warning states when art changes.
- Design scalable panels as 9-slice/nine-patch assets; verify corners and borders at several sizes.
## Import checkpoints
**Godot 4.7:** choose nearest filtering for crisp pixel art; use mipmaps when non-pixel textures
shrink substantially; set repeat only for textures designed to tile; verify `Sprite2D`,
`TileSet`, atlas regions, and animation frames in the editor.
**Unity 6.3 LTS:** set Texture Type to Sprite (2D and UI), choose Single/Multiple correctly, set a
consistent Pixels Per Unit, filter mode, compression, mipmaps, mesh type, and sprite slicing.
Disable Read/Write unless runtime pixel access is actually required because it adds memory cost.
**Phaser/PixiJS/web:** keep atlas metadata and image filenames stable; use nearest sampling and
integer camera scaling for pixel art; prevent browser/CSS resizing from introducing blur; inspect
texture bleeding under the real renderer.
## Primary documentation
- [Godot 4.7 Image](https://docs.godotengine.org/en/4.7/classes/class_image.html)
- [Godot 4.7 Texture2D](https://docs.godotengine.org/en/4.7/classes/class_texture2d.html)
- [Unity sprite import settings](https://docs.unity3d.com/Manual/texture-type-sprite.html)
- [Phaser asset concepts](https://docs.phaser.io/phaser/concepts/loader)
- [PixiJS Assets guide](https://pixijs.com/8.x/guides/components/assets)
references/three-d-pipeline.md›
# 3D concept-to-runtime pipeline
Use this reference when the output is a model, material, texture set, rig, animation, or 3D prop
family. An appealing render proves appearance only; it does not prove production geometry.
## Default pipeline
1. Lock camera/view, scale, gameplay footprint, material language, polygon/texture budgets, target
engine, renderer, and platform.
2. Create or select orthographic/turnaround concepts with consistent proportions. Treat generated
multi-view sheets as references that still require geometric interpretation.
3. Author or clean the model in a DCC such as Blender. Inspect topology, normals, watertightness,
UVs, texel density, material slots, rig, weights, and animation clips.
4. Apply/normalize transforms and set a gameplay-meaningful origin and pivot.
5. Create simplified collision proxies. Do not use a detailed render mesh as default collision.
6. Define LODs and material/texture reuse for repeated or distant objects.
7. Export using the engine's preferred interchange path. Use GLB/glTF 2.0 as the general runtime
delivery default when the target supports it; keep editable DCC sources separately.
8. Import into the real engine, check scale/orientation/materials/animation, profile memory and draw
calls, and capture representative screenshots before approval.
## Geometry gates
- silhouette fits gameplay and LOD transitions preserve it
- no accidental internal faces, non-manifold regions, inverted normals, or degenerate geometry
- deformation loops support the required rig motion
- pivots/origins support doors, wheels, pickups, weapons, placement, and snapping
- units and forward/up axes match the project convention
- collision proxies match gameplay intent without excessive detail
## Material and texture gates
- use consistent PBR channel conventions and color spaces
- avoid baking lighting into base color unless the art direction explicitly requires it
- pack channels only when the target pipeline documents the mapping
- keep texel density consistent across an asset family
- size textures from on-screen coverage; source resolution is not a runtime budget
- reuse materials/atlases where it reduces draw calls without harming iteration
- validate normal-map orientation and compression in the target renderer
## Generated 3D caution
If a tool can generate meshes, inspect the result with the same gates as an authored mesh. Never
infer clean topology, UVs, rigging, licensing, or efficient materials from a preview render. Keep
the tool/version and generation input in the asset manifest.
## Primary documentation
- [Khronos glTF registry and 2.0.1 specification](https://registry.khronos.org/glTF/)
- [Godot 4.7 importing 3D scenes](https://docs.godotengine.org/en/4.7/tutorials/assets_pipeline/importing_3d_scenes/index.html)
- [Unity model import settings](https://docs.unity3d.com/Manual/class-ModelImporter.html)
- [Unreal Engine importing static meshes](https://dev.epicgames.com/documentation/en-us/unreal-engine/importing-static-meshes-using-fbx-in-unreal-engine)
- [three.js GLTFLoader](https://threejs.org/docs/#examples/en/loaders/GLTFLoader)
scripts/asset_report.py›
#!/usr/bin/env python3
"""Inspect raster game assets and enforce simple production constraints.
Requires Pillow 10+. The command exits 1 when an explicit constraint fails and
otherwise prints either a compact table or JSON suitable for build tooling.
"""
from __future__ import annotations
import argparse
import json
from pathlib import Path
from typing import Any
from PIL import Image
def parse_size(value: str) -> tuple[int, int]:
try:
width_text, height_text = value.lower().split("x", 1)
width, height = int(width_text), int(height_text)
except (ValueError, AttributeError) as exc:
raise argparse.ArgumentTypeError("size must look like WIDTHxHEIGHT") from exc
if width <= 0 or height <= 0:
raise argparse.ArgumentTypeError("size dimensions must be positive")
return width, height
def alpha_stats(image: Image.Image) -> dict[str, Any]:
has_alpha = "A" in image.getbands() or "transparency" in image.info
if not has_alpha:
return {
"has_alpha": False,
"alpha_min": 255,
"alpha_max": 255,
"transparent_pixels": 0,
"content_bounds": [0, 0, image.width, image.height],
}
alpha = image.convert("RGBA").getchannel("A")
extrema = alpha.getextrema()
histogram = alpha.histogram()
return {
"has_alpha": True,
"alpha_min": extrema[0],
"alpha_max": extrema[1],
"transparent_pixels": histogram[0],
"content_bounds": list(alpha.getbbox() or (0, 0, 0, 0)),
}
def inspect(path: Path, max_colors: int | None) -> dict[str, Any]:
with Image.open(path) as image:
image.load()
colors = image.convert("RGBA").getcolors(maxcolors=(max_colors or 65535) + 1)
result: dict[str, Any] = {
"path": path.as_posix(),
"format": image.format,
"mode": image.mode,
"width": image.width,
"height": image.height,
"bytes": path.stat().st_size,
"color_count": len(colors) if colors is not None else f">{max_colors or 65535}",
}
result.update(alpha_stats(image))
return result
def main() -> int:
parser = argparse.ArgumentParser(description=__doc__)
parser.add_argument("paths", nargs="+", type=Path, help="Raster image files to inspect")
parser.add_argument("--expect-size", type=parse_size, metavar="WIDTHxHEIGHT")
parser.add_argument("--require-alpha", action="store_true")
parser.add_argument("--max-colors", type=int)
parser.add_argument("--json", action="store_true", dest="as_json")
args = parser.parse_args()
if args.max_colors is not None and args.max_colors <= 0:
parser.error("--max-colors must be positive")
reports: list[dict[str, Any]] = []
failed = False
for path in args.paths:
problems: list[str] = []
if not path.is_file():
reports.append({"path": path.as_posix(), "problems": ["file does not exist"]})
failed = True
continue
try:
report = inspect(path, args.max_colors)
except (OSError, ValueError) as exc:
reports.append({"path": path.as_posix(), "problems": [f"cannot read image: {exc}"]})
failed = True
continue
if args.expect_size and (report["width"], report["height"]) != args.expect_size:
problems.append(
f"size is {report['width']}x{report['height']}; expected "
f"{args.expect_size[0]}x{args.expect_size[1]}"
)
if args.require_alpha and not report["has_alpha"]:
problems.append("image has no alpha channel")
if args.max_colors is not None and isinstance(report["color_count"], str):
problems.append(f"image has more than {args.max_colors} colors")
report["problems"] = problems
reports.append(report)
failed = failed or bool(problems)
if args.as_json:
print(json.dumps({"ok": not failed, "assets": reports}, indent=2))
else:
for report in reports:
if "width" not in report:
print(f"FAIL {report['path']}: {', '.join(report['problems'])}")
continue
state = "PASS" if not report["problems"] else "FAIL"
print(
f"{state} {report['path']} {report['width']}x{report['height']} "
f"{report['mode']} colors={report['color_count']} alpha={report['has_alpha']}"
)
for problem in report["problems"]:
print(f" - {problem}")
return 1 if failed else 0
if __name__ == "__main__":
raise SystemExit(main())
scripts/build_preview_sheet.py›
#!/usr/bin/env python3
"""Build a labelled nearest-neighbor contact sheet for raster game assets.
Requires Pillow 10+. Inputs are sorted by path so repeated runs stay stable.
"""
from __future__ import annotations
import argparse
import math
from pathlib import Path
from PIL import Image, ImageDraw, ImageFont
def checkerboard(size: tuple[int, int], tile: int = 12) -> Image.Image:
image = Image.new("RGBA", size, "#c9c9c9")
draw = ImageDraw.Draw(image)
for y in range(0, size[1], tile):
for x in range(0, size[0], tile):
if (x // tile + y // tile) % 2:
draw.rectangle((x, y, x + tile - 1, y + tile - 1), fill="#eeeeee")
return image
def fit_nearest(image: Image.Image, max_size: tuple[int, int]) -> Image.Image:
source = image.convert("RGBA")
scale = min(max_size[0] / source.width, max_size[1] / source.height)
if scale >= 1:
scale = max(1, math.floor(scale))
width = max(1, round(source.width * scale))
height = max(1, round(source.height * scale))
return source.resize((width, height), Image.Resampling.NEAREST)
def main() -> int:
parser = argparse.ArgumentParser(description=__doc__)
parser.add_argument("inputs", nargs="+", type=Path)
parser.add_argument("--out", required=True, type=Path)
parser.add_argument("--columns", type=int, default=4)
parser.add_argument("--cell-size", type=int, default=192)
parser.add_argument("--padding", type=int, default=12)
args = parser.parse_args()
if args.columns <= 0 or args.cell_size <= 0 or args.padding < 0:
parser.error("columns/cell-size must be positive and padding cannot be negative")
paths = sorted({path.resolve() for path in args.inputs})
missing = [path for path in paths if not path.is_file()]
if missing:
parser.error("missing input(s): " + ", ".join(path.as_posix() for path in missing))
label_height = 24
cell_width = args.cell_size + args.padding * 2
cell_height = args.cell_size + label_height + args.padding * 2
rows = math.ceil(len(paths) / args.columns)
sheet = Image.new("RGBA", (cell_width * args.columns, cell_height * rows), "#202124")
draw = ImageDraw.Draw(sheet)
font = ImageFont.load_default()
for index, path in enumerate(paths):
column, row = index % args.columns, index // args.columns
left, top = column * cell_width, row * cell_height
preview = checkerboard((args.cell_size, args.cell_size))
with Image.open(path) as source:
fitted = fit_nearest(source, (args.cell_size, args.cell_size))
x = (args.cell_size - fitted.width) // 2
y = (args.cell_size - fitted.height) // 2
preview.alpha_composite(fitted, (x, y))
sheet.alpha_composite(preview, (left + args.padding, top + args.padding))
label = path.name
if len(label) > 30:
label = label[:27] + "..."
draw.text(
(left + args.padding, top + args.padding + args.cell_size + 6),
label,
fill="#ffffff",
font=font,
)
args.out.parent.mkdir(parents=True, exist_ok=True)
sheet.convert("RGB").save(args.out, quality=95)
print(f"Wrote {args.out} ({len(paths)} assets, {args.columns} columns)")
return 0
if __name__ == "__main__":
raise SystemExit(main())
scripts/requirements.txt›
Pillow>=10,<13
SKILL.md›
---
name: create-game-assets
description: Plan, generate, source, normalize, and validate cohesive visual game assets. Use for art direction, style bibles, sprites, tilesets, backgrounds, UI art, icons, textures, concept art, or 3D asset briefs.
---
# 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.
## 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.
## 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.
Build prompts from these blocks:
```text
ROLE/PURPOSE: production asset for [gameplay role]
SUBJECT: [specific object/character and action]
VIEW: [orthographic/top-down/side/three-quarter], [camera and facing]
ART DIRECTION: [shape language], [palette roles], [materials], [edge treatment]
GAME-SCALE READ: [silhouette and focal details that must survive at WxH]
TECHNICAL OUTPUT: [dimensions/aspect], [transparent or scene background], [frame/slot count]
LOCKS: preserve [identity, proportions, palette, costume, lighting, line weight]
EXCLUDE: text, labels, mockup frames, scenery, duplicate objects, cropped edges, signatures
```
For edits, say both what changes and what stays fixed. Ask for transparent output through the
tool's native transparency option when available, then verify the alpha channel—prompt wording
alone does not guarantee transparency.
## Raster QA recipes
Inspect constraints and emit a machine-readable report:
```bash
python scripts/asset_report.py assets/player-idle.png \
--expect-size 64x64 --require-alpha --max-colors 48 --json
```
Build a nearest-neighbor contact sheet over a checkerboard:
```bash
python scripts/build_preview_sheet.py output/player/*.png \
--out output/player-preview.png --columns 4 --cell-size 192
```
Run script paths relative to this skill directory, or resolve the installed skill path first.
Both scripts require Python 3.10+ and Pillow. Install the only dependency with
`python -m pip install -r scripts/requirements.txt` when it is not already available.
## Quality gates
- **Cohesion:** related assets share palette roles, line/edge treatment, view, light direction,
scale, and detail density.
- **Gameplay read:** silhouettes and state changes remain clear at native resolution, in motion,
and over real backgrounds.
- **Technical fit:** exact size/frame count, usable alpha, stable anchors/pivots, correct color
space/filtering, no clipped content, no accidental labels or baked mockup chrome.
- **Animation:** identity, volume, proportions, costume, facing, and baseline do not drift; timing
and anticipation read in an in-engine preview.
- **Tiles/backgrounds:** required edges tile without seams; repetition is tolerable; parallax
layers have intentional depth and no baked collision cues.
- **3D:** transforms, scale, pivot, normals, UVs, materials, topology, rig, collision proxies,
LODs, and runtime format are checked rather than inferred from a render.
- **Rights:** every shipped file has recorded provenance and terms compatible with the project.
Do not call an asset production-ready from a prompt result alone. Approval requires the relevant
technical checks plus an in-engine or native-scale visual inspection.
## References
- For visual-system decisions and maintaining consistency, read
`references/art-direction.md`.
- For sprites, animation strips, tiles, backgrounds, UI art, and engine import settings, read
`references/raster-pipeline.md`.
- For concept-to-mesh, textures, glTF/GLB, LOD, collision, and runtime validation, read
`references/three-d-pipeline.md`.
- For licenses, generated-media records, and provenance, read
`references/provenance.md`.
## Related skills
- `game-ui-ux` for layout, navigation, readability, and accessible interaction.
- `game-feel`, `shader-programming`, and `audio-design` for presentation after the source art fits.
- Engine import/rendering skills such as `godot-tilemap`, `unity-tilemap-2d`,
`pixijs-rendering`, and `threejs-gltf-loading`.