# Game Character Sprites

> A Claude skill from ItamarZand88/awesome-agent-conventions.

- **Type:** Skill
- **Install:** `agentstack add skill-itamarzand88-awesome-agent-conventions-game-character-sprites`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [ItamarZand88](https://agentstack.voostack.com/s/itamarzand88)
- **Installs:** 0
- **Category:** [AI & ML](https://agentstack.voostack.com/c/ai-and-ml)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [ItamarZand88](https://github.com/ItamarZand88)
- **Source:** https://github.com/ItamarZand88/awesome-agent-conventions/tree/main/conventions/skill-md/examples/design-creative/game-character-sprites

## Install

```sh
agentstack add skill-itamarzand88-awesome-agent-conventions-game-character-sprites
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

---
name: game-character-sprites
description: Create game-ready fixed-cell pixel-art character spritesheets from text concepts, reference images, or existing character art. Use when Codex needs to design, generate, clean up, validate, and package 2D game characters with native 32x32, 64x64, or 128x128 cells; 4-way or 8-way directions; idle, walk/run, jump, attack, archer, caster, or other animation strips; transparent GIF/WebP previews; and per-direction targeted regeneration.
---

# Game Character Sprites

## Overview

Use this skill to make game-ready fixed-cell pixel-art character animations. If the user names cell sizes, those sizes are the required output scope. If no size is named, default to `64x64`.

Never expand or reduce scope silently. If the user asks for "attack and walk only," make only those actions. If they ask for GIFs, deliver GIF/WebP previews, not just atlas PNGs. If directions are not specified and the user asks for a full game character movement pack, default to full 8-way directions; for a quick sample, test, or one-direction request, use only one direction and label it.

Minimum workspace outputs:

```text
run/
  run-manifest.json
  source/.png
  /
    generated/-.png
    frames/-/.png
    final/-sheet-clean.png
    final/-metadata.json
    qa/-validation.json
    qa/-contact-sheet.png
    qa/visual-review.json
    qa/previews/*-transparent-x4.webp
    qa/previews/*-transparent-x4.gif
    qa/previews/*-checker-x4.gif
```

## Scope

Supported cell sizes: `32`, `64`, `128`.

## Size Contract

Requested sizes are a hard deliverable. If the user asks for `32x32 64x64 128x128`, create a native output set for each size:

```text
run/32/...
run/64/...
run/128/...
```

Do not collapse a multi-size request into a single `64x64` master plus resized variants unless the user explicitly says scaled variants are acceptable. If you must provide scaled variants as a fallback, label them as `scaled-32` or `upscaled-128`, state that they are not native assets, and do not describe them as authored/native sheets.

Do not ask imagegen for a combined `32/64/128` contact sheet as the normal workflow. Combined multi-size contact sheets make the model treat the sizes as layout elements inside one picture, not as separate pixel-art budgets. For native assets, generate each requested size as its own imagegen row strip at that size budget.

Multi-size sprites must follow a strict resolution hierarchy:

- Primary level is locked at `32x32`: silhouette, proportions, pose timing, and main color blocks.
- Secondary level starts at `64x64`: internal lines, larger facial/clothing details, and readable secondary forms inside the locked primary shape.
- Tertiary level starts at `128x128`: micro-highlights, small folds, surface pixels, and tiny accents inside the locked primary and secondary structure.
- Larger sizes must behave conceptually like a nearest-neighbor expansion of the 32px design with extra information added inside the same shapes.
- Larger sizes must not change the primary silhouette, limb lengths, body proportions, pose sequence, or main palette blocks.

For native multi-size jobs, run the workflow as a hierarchy, not as three unrelated drawings:

```text
generate the 32px strip directly as a 32px-budget pixel-art row
visually accept the 32px primary silhouette, pose timing, and main color blocks
generate the 64px strip directly as a 64px-budget row, using the accepted 32px strip as the primary-structure reference
generate the 128px strip directly as a 128px-budget row, using the accepted 32px and 64px strips as structure references
assemble each size with --cell 
clean each size with --cell 
validate each size with --cell 
run hierarchy QA by making thumbnail comparisons only; do not create assets by downsampling
export previews for each size
```

Cell-size guidance:

- `32x32`: simplify details, exaggerate silhouette, use fewer colors, avoid tiny face/accessory details that will blur.
- `64x64`: balanced default for game prototypes and readable chibi characters.
- `128x128`: native redraw with more pixel detail and smoother secondary motion, not a nearest-neighbor upscale from 64.

Blocked acceptance: if the user requested multiple sizes and the final response only includes 64px authored sheets plus scaled 32/128 variants, the task is incomplete unless the user approved that tradeoff.

Also block acceptance when 32/64/128 are three inconsistent drawings. Native larger sizes may add detail, but they must downsample back to the same 32px primary silhouette and main color layout.

Default directions:

```text
south, south-east, east, north-east, north, north-west, west, south-west
```

Only create directions requested by the user. For full 8-way exports, use the order above.

## Single Direction Jobs

Requests containing "one direction", "single direction", "just one direction", "1 direction", or "test one direction" mean:

```text
rows: 1
directions: 
```

Do not expand single-direction jobs into 4-way or 8-way sheets. If the user provides a front-facing reference and does not name the direction, use `south` and say that the test uses the reference-facing/front direction.

For one-direction multi-size tests, expected outputs look like:

```text
run/32/final/walk-sheet-clean.png   # 192x32 for 6 frames
run/64/final/walk-sheet-clean.png   # 384x64 for 6 frames
run/128/final/walk-sheet-clean.png  # 768x128 for 6 frames
```

Default frames:

```text
idle:   4 frames, optionally padded to 6 cells
walk:   6 frames
attack: 6 frames
```

## Agent Workflow

1. Establish the requested scope: cell size or sizes, actions, directions, frame count, weapon/class, and must-keep reference details. Treat explicit sizes as mandatory outputs.
2. Ground the character from the user reference. If the image tool cannot consume the file path, use the attached image from chat context; if no visual grounding is available, stop and say the reference could not be used instead of inventing a loose text-only character.
3. Create `run/run-manifest.json` before generation. Record the reference source, identity details, requested scope, and planned generation method.
4. Build one strong canonical base sprite first for the smallest requested size, usually `32x32`, so the primary design is locked before adding detail.
5. Generate one action-direction-size strip at a time, e.g. `32/walk-south`, then `64/walk-south`, then `128/walk-south`.
6. For multi-size jobs, each requested size must have its own imagegen output file. Do not use one imagegen contact sheet as the source for multiple native sizes.
7. Record every generated strip in `run/run-manifest.json` with `method: "imagegen"`, cell size, action, direction, imagegen output path, source path, and prompt path.
8. Assemble strips with `scripts/assemble_action_sheet.py`.
9. Clean with `scripts/pixel_snap.py` using chroma-key cleanup.
10. Validate geometry, residue, and motion with `scripts/validate_sheet.py` and `scripts/audit_sprite_motion.py`.
11. For multi-size jobs, validate resolution hierarchy with `scripts/validate_resolution_hierarchy.py`.
12. Export previews with `scripts/export_animation_previews.py`.
13. Visually inspect every contact sheet and at least one GIF/WebP per direction group, then write `qa/visual-review.json`. Do not rely on validation JSON alone for art quality.
14. Validate provenance and visual acceptance with `scripts/validate_run_manifest.py`.
15. Regenerate only weak directions or frames. Do not redo strong rows.

Do not generate a complete 8-direction sheet in one image prompt. One-shot sheets often create near-duplicate walk frames, direction drift, missing directions, and inconsistent characters.

For web/ChatGPT agents, keep the workflow CLI and file based. Write artifacts to the workspace, call the platform's file export/share tool when available, then return downloadable links to the final atlas, metadata, contact sheet, validation JSON, and preview GIF/WebP files. Plain `/workspace/...` text paths are not enough if the UI needs exported files.

Do not show raw generated chroma-key strips as final results. Raw strips are intermediate QA only. Final visual previews must be cleaned transparent WebP/GIF or checkerboard GIF/contact sheets.

When using a chat attachment as reference, record an identity note in the run folder listing the exact details preserved from the image. Do not write "falling back to a prompt" unless the image is truly unavailable. The visible chat image is valid grounding for identity notes even when it is not available as a normal filesystem path.

## Imagegen File Handoff

Imagegen output must become a local file before the skill can finish. In Codex Desktop, generated images are saved under:

```text
D:\CodexHome\generated_images\\.png
```

Copy the selected imagegen result into `run/source/` and leave the original in place. If the platform cannot expose the generated image as a file, stop and say the image was generated but cannot be processed into sprite files. Do not claim the sprite pack is complete.

Normal native workflow:

```text
imagegen -> run/source/32-walk-south.png -> run/32/generated/walk-south.png
imagegen -> run/source/64-walk-south.png -> run/64/generated/walk-south.png
imagegen -> run/source/128-walk-south.png -> run/128/generated/walk-south.png
```

Each source image must be generated specifically for that cell budget. For example, the `32` imagegen prompt should ask for one row of six `32x32` frames only. The `64` prompt should ask for one row of six `64x64` frames only. The `128` prompt should ask for one row of six `128x128` frames only.

Emergency fallback only: if imagegen already returned one multi-size contact sheet, `scripts/import_imagegen_contact_sheet.py` may be used to rescue it for diagnosis. That output must be marked as `imported_contact_sheet: true` in the manifest and must not be called a native multi-size pass unless the user explicitly accepts that fallback.

```bash
python "/scripts/import_imagegen_contact_sheet.py" \
  --input path/to/imagegen-output.png \
  --run-dir path/to/run \
  --action walk \
  --direction south \
  --sizes 32,64,128 \
  --columns 6 \
  --key-color "#00ff00" \
  --copy-source
```

This creates:

```text
run/32/generated/walk-south.png
run/64/generated/walk-south.png
run/128/generated/walk-south.png
run/source/.png
run/imagegen-import-report.json
```

Then continue with assembly, cleanup, validation, previews, manifest validation, and visual review.

## Reference And Provenance Gate

A run is not a valid art test unless the visual source strips came from `$imagegen` using the user's reference. Text-only identity notes are not enough.

Required manifest:

```json
{
  "reference": {
    "source_type": "chat_attachment",
    "source": "attached image #1 or path/to/reference.png",
    "used_for_generation": true,
    "identity_notes": [
      "green bird/penguin body",
      "red and white cap",
      "white unicorn float",
      "rainbow tail",
      "sandals"
    ]
  },
  "scope": {
    "sizes": [32, 64, 128],
    "actions": ["walk"],
    "directions": ["south"],
    "frames": 6
  },
  "generation": {
    "method": "imagegen",
    "imagegen_output_path": "run/source/32-walk-south.png",
    "procedural": false,
    "text_only": false,
    "imported_contact_sheet": false
  },
  "strips": [
    {
      "cell": 32,
      "action": "walk",
      "direction": "south",
      "method": "imagegen",
      "imagegen_output_path": "run/source/32-walk-south.png",
      "source_path": "run/32/generated/walk-south.png",
      "prompt_path": "run/32/prompts/walk-south.txt"
    }
  ],
  "visual_review": {
    "path": "run/32/qa/visual-review.json"
  }
}
```

Blocked acceptance:

- `generation.method` is `procedural`, `python_draw`, `script`, `text_only`, or anything other than `imagegen`
- `generation.imagegen_output_path` is missing or not a real local file
- one imagegen output is reused as the source for multiple requested native sizes without explicit fallback approval
- `generation.imported_contact_sheet` is true and the final response calls the output native
- `reference.used_for_generation` is not true
- generated strips were made by local drawing code
- the final response calls a procedural smoke test a real image/reference test
- visual review says the sprite does not match the reference, direction, or requested action

Local code may create tiny fixtures only for script unit tests. Those outputs must be labeled `pipeline-only`, must not be shipped as art, and must not be used to claim the skill can generate the requested character.

## Subagents

If the user explicitly asks for subagents or parallel agents, split work by action or direction:

- Worker A: base sprite and identity notes
- Workers B/C/D: independent direction strips with disjoint output paths
- QA worker: validation/contact-sheet review and weak-row list

Workers should edit only their assigned files and must not overwrite other workers' outputs. The main agent integrates rows, runs validation, and regenerates weak directions only.

## Direction Lock

Prompt and reject directions using these rules:

- `south`: front-facing, face/body toward camera
- `north`: back-facing, back of head/body visible
- `east`: side-facing screen-right
- `west`: side-facing screen-left
- diagonals visibly split neighboring directions
- reject rows where every frame drifts screen-right
- reject rows where feet move but torso/head direction stays unchanged

When directions are wrong, regenerate only the weak direction with explicit wording such as "back-facing north, no front face visible" or "side-facing left, walking west."

## Generation Rules

Use `$imagegen` for visual generation. Do not hand-draw missing animation frames with local code. Scripts may crop, assemble, quantize, snap, validate, and preview already-generated art.

Base sprite prompt:

```text
x pixel-art game sprite, single character, transparent or flat chroma-key background.
Readable silhouette, hard pixel edges, limited palette, no UI, no text, no frame border.
Preserve: .
```

Row strip prompt:

```text
x pixel-art game sprite animation strip.
One horizontal row of exactly  separated frames.
Action: . Direction: .
Flat pure solid chroma-key background , no gradient, no rounded panel, no shadows, no floor, no UI, no text, no frame numbers.
Preserve the canonical character identity exactly.
Hard pixel-art edges, saturated readable colors, clear green/magenta space between frames.
```

Prefer `#00ff00` chroma-key. Use `#ff00ff` if the character or VFX uses green.

Reject and regenerate strips with gradient backgrounds, rounded colored cards, missing frame separation, cropped body/weapon, or any text/labels. Do not try to rescue badly structured strips with equal slicing.

## Walk Quality

Do not make walk by generating a whole walk sheet at once. Generate per direction as separate 6-frame strips.

Use this pose structure:

```text
contact, down, passing, up, contact, passing
```

Lock these animation rules before generation:

- head bob: 1-2 px
- hips shift: 1 px
- opposite arm/leg swing
- cape/hair lag one frame behind torso
- weapon hand stays controlled
- chibi/small sprites need exaggerated motion to read

If the walk looks like near-duplicate standing poses, regenerate that direction with stronger prompts: "large readable step silhouettes, alternating feet, clear contact/down/passing/up poses."

## Jump Quality

For jump, use 6 frames:

```text
crouch, launch, rise, apex, fall, land/recover
```

The body should move vertically inside the cell while staying within margins. Legs must visibly compress on crouch/land. Hair, cape, ears, tail, or clothing should lag slightly. Reject jump rows where the character only changes arm pose while feet stay fixed.

## Attack Quality

For melee attacks, show anticipation, swing/contact, and recovery. Weapon arcs must stay attached to the weapon and inside the cell.

For archer attacks, animate draw, hold/aim, release

…

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [ItamarZand88](https://github.com/ItamarZand88)
- **Source:** [ItamarZand88/awesome-agent-conventions](https://github.com/ItamarZand88/awesome-agent-conventions)
- **License:** MIT

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-itamarzand88-awesome-agent-conventions-game-character-sprites
- Seller: https://agentstack.voostack.com/s/itamarzand88
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.
