Create, repair, validate, visually QA, and package Codex-compatible animated pets and pet spritesheets from character art, generated images, company or prospect brand cues, or visual references. Use when a user wants a lightweight-worker Codex pet workflow, a non-pixel custom pet style, a prospect or company mascot pet, or a full 8x9 animated pet atlas with transparent unused cells, QA contact sheets, and pet.json packaging. This skill composes the installed $imagegen system skill for visual generation and uses bundled scripts for deterministic spritesheet assembly.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Um comando direto ignora o prompt de revisão. Verifique a origem antes de executá-lo.
Instruções da origem · Visualização somente leitura
name
hatch-pet
description
Create, repair, validate, visually QA, and package Codex-compatible animated pets and pet spritesheets from character art, generated images, company or prospect brand cues, or visual references. Use when a user wants a lightweight-worker Codex pet workflow, a non-pixel custom pet style, a prospect or company mascot pet, or a full 8x9 animated pet atlas with transparent unused cells, QA contact sheets, and pet.json packaging. This skill composes the installed $imagegen system skill for visual generation and uses bundled scripts for deterministic spritesheet assembly.
Hatch Pet
Overview
Create a Codex-compatible animated pet from a concept, brand cue, company/prospect name, one or more reference images, or any combination of those inputs. This workflow keeps the deterministic hatch-pet pipeline for atlas geometry, validation, visual QA, and packaging, while using concise state-specific prompts and allowing any pet-safe visual style.
User-facing inputs are optional. If the user omits a pet name, infer one from the concept, brand, company, or reference filenames; if that is not possible, choose a short friendly name. If the user omits a description, infer one from the concept or references. If the user omits reference images, generate the base pet from text first, then use that base as the canonical reference for every animation row.
Generation Delegation
Use $imagegen for all normal visual generation.
Before generating base art, row strips, or repair rows, load and follow the installed image generation skill:
Do not call the Image API, image CLI, or any other image-generation path directly. Let $imagegen choose its own built-in-first path and fallback rules. If $imagegen says a fallback requires confirmation, ask the user before continuing.
When invoking $imagegen, pass the generated pet prompt as the authoritative visual spec. Pet prompts should stay concise, state-specific, sprite-production oriented, and grounded in the listed input images. Keep longer policy and QA rules in this skill and the deterministic review scripts rather than expanding them into every image prompt. Do not wrap prompts in the generic shared prompt schema.
$imagegen
Use this skill's scripts for deterministic image work only: preparing layout guides and prompts, mirroring approved running-left, extracting frames, validating rows, composing the final atlas, and creating contact-sheet plus motion-preview QA media. Parent-owned shell/jq steps handle manifest updates, packaging, and cleanup.
Storage Controls
The built-in $imagegen path stores generated PNG bytes in the rollout that invokes it, even when it also writes a file under ${CODEX_HOME:-$HOME/.codex}/generated_images. Deleting files later reduces filesystem use, but it does not shrink an already-written rollout. Keep image generation isolated and bounded:
Use one lightweight generation worker per visual job. Do not batch multiple base/row jobs into the same worker.
Workers must return only selected_source=... and qa_note=...; they must not include Markdown image previews, base64, or extra visual attachments in their final response.
The parent must not open every generated PNG visually. Use worker QA for each job and inspect only the final contact sheet.
After copying the selected generated output into decoded/, remove the selected original from ${CODEX_HOME:-$HOME/.codex}/generated_images when it lives there, then remove its now-empty generation directory if possible.
For storage-sensitive full runs, ask the user whether to use the $imagegen CLI fallback when available. That path requires local API credentials and explicit user confirmation, but it can avoid built-in image payloads being embedded in rollout events.
Brand Discovery
If the user provides a brand, company, product, or prospect name rather than a concrete avatar description or reference image, run a lightweight discovery subagent before preparing the pet run. The discovery worker must use web search and prefer official sources such as the brand site, product pages, docs, about pages, press pages, or brand pages. Use reputable secondary sources only when official pages are too thin. Keep the search narrow: enough to extract visual and personality cues, not a market-research brief.
Skip discovery when the user already provides a concrete mascot/avatar description or reference images, unless the user explicitly asks for brand research.
Discovery worker responsibilities:
search the web for 2-4 relevant sources, preferring official pages
write an adaptive markdown brief rather than a rigid field dump
mark mascot guidance that is inferred from sources as inference
avoid copying logos, readable marks, UI screenshots, slogans, or text
end with a compact Generation handoff section containing only brand_name, brand_brief, avatar_seed, avoid, and brand_sources
do not generate images, prepare run folders, or edit unrelated files
Use this discovery worker prompt:
Research a brand for hatch-pet mascot creation.
Brand/product/prospect: <brand name>
User context: <short user request>
Output file: <absolute path to brand-discovery.md>
Use web search. Prefer official brand, product, docs, about, press, or brand pages. Use reputable secondary sources only if official sources are too thin. Write an adaptive markdown brief to the output file. Headings may flex by brand, but the brief must cover:
- identity/category: canonical name, product type, what it does
- audience/use context: who it serves and where it appears
- visual system: palette, shapes, line quality, materials, typography feel, iconography, patterns
- personality/tone: emotional traits, energy, formality, playfulness
- product/domain motifs: objects, workflows, verbs, metaphors, environments
- mascot translation cues: candidate forms, signature traits, props, what must read at pet size
- avoidances: logos/text, trademark-sensitive elements, misleading cues, competitor confusion, poor mascot fits
- evidence/confidence: source URLs plus notes where evidence is weak or inferred
Do not copy logos, readable marks, UI screenshots, slogans, or text. Clearly label mascot guidance that is inferred rather than directly sourced.
End the brief with a `Generation handoff` section containing exactly:
- brand_name=<canonical brand/product name>
- brand_brief=<one sentence, max 45 words, covering palette/tone/domain motifs/personality>
- avatar_seed=<short mascot-safe visual idea, no logo copying>
- avoid=<short comma-separated list>
- brand_sources=<comma-separated source URLs>
Return exactly:
brand_discovery_file=<absolute output file path>
brand_name=<canonical brand/product name>
brand_brief=<same compact sentence from Generation handoff>
avatar_seed=<same short seed from Generation handoff>
avoid=<same short avoid list from Generation handoff>
brand_sources=<same comma-separated URLs from Generation handoff>
The parent should save the markdown brief before preparing the run, then pass it to prepare_pet_run.py as --brand-discovery-file together with --brand-name, --brand-brief, repeated --brand-source, and a concise --pet-notes value based on avatar_seed when the user did not provide a better avatar description. Keep the full brief for review; only the compact handoff fields should shape prompts. If web search is unavailable and the user gave only a bare brand name, ask for brand cues before generating.
For a normal pet run, expect up to 10 visual generation jobs: 1 base pet plus 9 row-strip jobs. The Codex app contract currently uses all 9 states: idle, running-right, running-left, waving, jumping, failed, waiting, running, and review. The only deterministic visual derivation is running-left, which may be produced by mirroring running-right only after running-right has been generated, visually inspected, and explicitly approved as safe to mirror. If mirroring is not appropriate, generate running-left as a normal grounded $imagegen row.
After selecting a visual output, the parent agent copies that exact image into the job's decoded/ path and marks the job complete in imagegen-jobs.json. Do not write helper scripts that populate row outputs. The deterministic Python scripts may only process already-generated visual outputs.
Only the base job may be prompt-only. Every row-strip job generated through $imagegen must use the input images listed in imagegen-jobs.json, including the canonical base reference created after the selected base output is copied. Treat any row generation without attached grounding images as invalid.
Pet-Safe Styles
Default style is auto: infer the pet's style from the user's prompt and references, then preserve that style across every row. If the user names a style, honor it. Supported style presets include pixel, plush, clay, sticker, flat-vector, 3d-toy, painterly, brand-inspired, and auto.
Any style is acceptable when it remains pet-safe:
compact whole-body silhouette readable inside a 192x208 cell
consistent face, proportions, material, palette, and props across all rows
clean removable chroma-key background
details large enough to read at pet size
no text, labels, UI, or readable logos unless the user explicitly provides approved reference art and asks for them
Non-pixel styles are first-class. Plush, clay, sticker, vector, 3D toy, painterly mascot, ink, and brand-inspired looks should be accepted when they satisfy the atlas and readability constraints.
Transparency And Effects
Pet rows are processed into transparent 192x208 cells, so every generated pixel must either belong to the pet sprite or be cleanly removable chroma-key background. Prefer pose, expression, and silhouette changes over decorative effects.
The deterministic raster pipeline owns the transparency invariant: pixels that become fully transparent are normalized so they do not retain hidden RGB residue, and atlas validation should fail if exported files violate that invariant. Do not paper over colored halos or transparent-pixel residue by accepting visually inconsistent outputs.
Allowed effects must satisfy all of these conditions:
The effect is state-relevant and helps explain the animation.
The effect is physically attached to, touching, or overlapping the pet silhouette, not floating nearby.
The effect is inside the same frame slot as the pet and does not create a separate sprite component.
The effect is opaque, hard-edged enough for clean extraction, and uses non-chroma-key colors.
The effect is small enough to remain readable at 192x208 without clutter.
Avoid these by default because they usually break transparent-background cleanup or component extraction:
text, labels, frame numbers, visible grids, guide marks, speech bubbles, thought bubbles, UI panels, code snippets, checkerboard transparency, white backgrounds, black backgrounds, or scenery
chroma-key-adjacent colors in the pet, prop, effects, highlights, or shadows
stray pixels, disconnected outline bits, speckle/noise, cropped body parts, overlapping poses, or any pose that crosses into a neighboring frame slot
State-specific guidance:
idle: keep this calm and low-distraction. Use only subtle breathing, a tiny blink, a slight head or body bob, a very small material sway, or another quiet persona-preserving motion. The loop must still contain visible micro-variation; do not accept six effectively identical copies. Do not show waving, walking, running, jumping, talking, working, reviewing, emotional reactions, large gestures, item interactions, or new props.
waving: show the wave through paw, hand, wing, or limb pose only. Do not draw wave marks, motion arcs, lines, sparkles, symbols, or floating effects around the gesture.
jumping: show vertical motion through body position only. Do not draw shadows, dust, landing marks, impact bursts, bounce pads, or floor cues.
failed: tears, attached smoke puffs, or attached stars are allowed if they obey the allowed-effects rules; do not use red X marks, floating symbols, detached smoke, detached stars, or separate tear droplets.
waiting: show that Codex needs approval, help, or user input through an expectant asking pose. Keep it distinct from ordinary idle and review.
running: show active task work, processing, thinking, scanning, typing, or focused effort. Do not show literal foot-running, jogging, sprinting, treadmill motion, raised knees, long steps, pumping arms, directional travel, speed lines, dust clouds, floor shadows, motion trails, or detached motion effects.
review: show focus through lean, blink, eyes, head tilt, or paw/hand position. Do not add magnifying glasses, papers, code, UI, punctuation, symbols, or other new props unless they already exist in the base pet identity.
running-right and running-left: show directional drag movement through body, limb, and prop movement only. running-right must face and travel right; running-left must face and travel left. Their cadence must visibly alternate across the loop rather than repeating one nearly static stride. Do not draw speed lines, dust clouds, floor shadows, motion trails, or detached motion effects.
Visible Progress Plan
For every pet run, keep a visible checklist so the user can see where the work is up to. Create the checklist before starting, keep one step active at a time, and update it as each step finishes.
Use this checklist for a normal pet run, replacing <Pet> with the pet's name or your pet:
Getting <Pet> ready.
Imagining <Pet>'s main look.
Picturing <Pet>'s poses.
Hatching <Pet>.
What each step means:
Getting <Pet> ready. Choose or confirm the pet name, description, source images, style preset, style notes, and working folder. For bare brand/product/company requests, first run the brand discovery worker and capture the compact brand brief, source URLs, and avatar seed.
Imagining <Pet>'s main look. Generate the pet's main reference image. This becomes the visual source of truth.
Picturing <Pet>'s poses. Generate pose rows through lightweight workers, starting with idle and running-right to confirm identity and gait. Only mirror running-left if running-right clearly works when flipped.
Hatching <Pet>. Turn the approved poses into final pet files, review the contact sheet, previews, and validation results, fix any broken parts, save pet.json and spritesheet.webp, then report the output paths.
Only mark a step complete when the real file, image, or decision exists. If this is a repair run, start from the first relevant step instead of restarting the whole checklist.
Default Workflow
Prepare a pet run folder and imagegen job manifest:
All arguments above are optional except any flags needed to express user constraints. For text-only requests, pass the concept through --pet-notes and omit --reference; prepare_pet_run.py will infer a name, description, chroma key, and output directory as needed.
For brand-only requests, run the discovery worker first, save the markdown brief, then pass the brief path through --brand-discovery-file, avatar_seed through --pet-notes, brand_name through --brand-name, brand_brief through --brand-brief, and each source URL through repeated --brand-source.
Inspect imagegen-jobs.json for the next ready $imagegen jobs. A job is ready when its status is not complete and every id in depends_on is already complete. Prefer reading the manifest directly with jq or the editor instead of adding helper scripts for status display:
Generate visual jobs with lightweight workers by default:
Generate and copy base first, using a lightweight base worker.
Generate and copy idle and running-right next as the identity and gait check, using one lightweight worker per row.
Inspect running-right; mirror running-left only when visual identity, prop placement, markings, lighting, and direction semantics remain correct.
Generate running-left normally with a lightweight worker when mirroring would change meaning or identity.
Generate the remaining rows with lightweight workers, using every input image listed for each job.
For each ready visual job, invoke $imagegen with the prompt file listed in imagegen-jobs.json, every listed input image with its role label, and the default built-in image_gen path unless $imagegen itself routes otherwise. The parent agent must keep its own image handling minimal: do not open every generated base or row in the parent rollout. Workers return only the selected source path and a one-sentence QA note; the parent records the selected source path in the manifest.
prepare_pet_run.py creates 9 row-specific layout guide images under references/layout-guides/, one per animation state. Row jobs attach the matching guide as a layout-only input so the model can follow the correct frame count, spacing, centering, and safe padding. Treat these guides as invisible construction references: the generated row strip must not include visible boxes, borders, center marks, labels, guide colors, or the guide background.
When generating row strips, keep the identity lock in the row prompt authoritative. Preserve the same style, face, markings, palette, materials, prop design, body proportions, and silhouette from the canonical base. Row jobs attach the layout guide and canonical base by default; the decoded base is kept in the run folder for deterministic processing rather than sent as a redundant generation input.
If $imagegen returns a transport-level Bad Request for a row, retry that same row once with its generated retry_prompt_file. The retry prompt preserves the row id, frame count, chroma key, canonical-base identity, and state action. Keep the canonical base attached. If the retry still fails, stop and report the failing row and prompt paths instead of switching to any other generation path.
After selecting a generated output for a job, copy it into the decoded output path and mark the job complete. For base, also create the canonical identity reference:
That script mirrors each generated frame slot in place so the leftward row preserves the rightward row's temporal order. Do not replace it with a whole-strip mirror that reverses animation timing.
When all jobs are complete, run the image-processing scripts directly:
If the preview GIFs show size popping or baseline jumps caused by per-frame fit-to-cell extraction, and the original row strip itself had stable scale and placement, rerun frame extraction with the explicit row-stability mode and then re-run inspection, atlas composition, validation, contact sheet generation, and previews:
Use stable-slots as a deliberate QA-driven correction, not the default. It should reduce extraction-induced motion pops without hiding clipped wide poses or bad source strips.
After deterministic image processing, inspect qa/contact-sheet.png and qa/previews/*.gif with a lightweight visual QA worker before accepting the pet. Deterministic validation is necessary but not sufficient. Block acceptance if any row changes species/body type, face, markings, palette, material, prop design, style, prop side unexpectedly, or overall silhouette. Motion previews must also reject unintended size popping, reversed or stagnant directional cadence, wrong facing direction, and idle loops that are technically different but visually inert.
After model visual QA accepts the contact sheet, remove intermediate run artifacts:
Keep pet_request.json, final/spritesheet.webp, final/validation.json, qa/contact-sheet.png, qa/previews/, qa/review.json, and qa/run-summary.json. Remove generated prompt files, layout guides, decoded row strips, extracted frames, final/spritesheet.png, and the imagegen job manifest. Skip cleanup when the user wants debug artifacts or the run still needs repair.
Lightweight Visual Workers
Use lightweight subagents for image-heavy work by default. This bounds each $imagegen rollout to one selected image, keeps contact-sheet vision payloads out of the parent thread, and reduces cost while preserving the full 9-state app contract.
Subagent Delegation
Unless explicitly forbidden by the user, use subagents for this run. If the user has not allowed the use of subagents, or the intent on subagent use is vague, then ask the user for permission to spawn subagents for parallel lanes of work.
Parent responsibilities:
run the brand discovery worker before preparation when the user provides a bare brand/product/company/prospect name
prepare the run and inspect imagegen-jobs.json
assign the base job, row jobs, and final contact-sheet QA to lightweight workers
copy selected worker outputs into their decoded paths and mark jobs complete in imagegen-jobs.json
create references/canonical-base.png from the selected base output
run the approved running-left mirror derivation when appropriate
run deterministic image processing, packaging, repair regeneration, and cleanup
Base worker responsibilities:
handle only the base job
read prompts/base-pet.md and use any listed reference images
use $imagegen only
honor any compact brand inspiration line in the prompt as broad visual/personality guidance, without copying logos, readable marks, UI screenshots, slogans, or text
return only selected_source=/absolute/path/to/selected-output.png and qa_note=<one sentence>
Row worker responsibilities:
handle exactly one row job
read the row prompt and use all listed input images
use $imagegen only; do not draw, edit, tile, or synthesize sprites locally
perform a quick visual sanity check for frame count, identity, chroma background, spacing, clipping, and detached effects
enforce the row prompt's transparency and effects rules, including no detached effects, no wave marks for waving, no speed lines or dust for directional running rows, no literal foot-running for the non-directional running row, and only attached opaque sprite-like tears/smoke/stars when allowed by the state prompt
return only selected_source=/absolute/path/to/selected-output.png and qa_note=<one sentence>
Final visual QA worker responsibilities:
inspect qa/contact-sheet.png plus the row GIFs under qa/previews/, with qa/review.json and final/validation.json as text context when useful
verify all 9 rows match the Codex app state contract and the same pet identity
return a compact result: visual_qa=pass or visual_qa=fail, plus row-specific repair notes when failing
do not edit files, queue repairs, package, or clean up
Model choice for workers:
Prefer a smaller capable model for brand discovery, since it returns a compact research brief rather than doing orchestration.
Prefer a smaller capable model for visual workers, such as gpt-5.4-mini with medium reasoning, when model override is available.
Use the parent/default model only for orchestration or when a smaller worker model is unavailable.
Keep at most two generation workers active at once unless the user explicitly asks for higher parallelism. Run final visual QA as a single worker after deterministic image processing. Close workers after their result has been consumed.
Use this base worker prompt:
Generate the hatch-pet base image.
Run dir: <absolute run dir>
Job id: base
Prompt file: <absolute base prompt file>
Input images:
- <absolute path> — <role>
Use $imagegen only. Read the base prompt and attach every listed input image. If the prompt contains brand inspiration, use it only as broad mascot-safe guidance; do not copy logos, readable marks, UI screenshots, slogans, or text. Before returning, visually check that the result is one centered full-body pet on a flat chroma background, with no text, scenery, shadows, or detached effects.
Do not edit manifests, copy into decoded, mark jobs complete, generate rows, run image-processing scripts, repair, package, or open unrelated files.
Do not include Markdown image previews, base64, or extra attachments in the final response.
Return exactly:
selected_source=/absolute/path/to/selected-output.png
qa_note=<one sentence>
Use this row worker prompt:
Generate one hatch-pet row.
Run dir: <absolute run dir>
Row id: <row-id>
Prompt file: <absolute prompt file>
Retry prompt file: <absolute retry prompt file>
Input images:
- <absolute path> — <role>
- <absolute path> — <role>
Use $imagegen only. Read the row prompt and attach every listed input image. If imagegen returns Bad Request, retry once with the retry prompt and the same input images.
Before returning, visually check: exact frame count, same pet identity as canonical base, flat chroma background, complete separated unclipped poses, and no detached effects or guide marks. The prompt's transparency and effects rules are mandatory: no detached effects, no wave marks for `waving`, no speed lines or dust for directional running rows, no literal foot-running for the non-directional `running` row, and only attached opaque sprite-like tears/smoke/stars when allowed by the state prompt.
Do not edit manifests, copy into decoded, mark jobs complete, mirror rows, run image-processing scripts, repair, package, or open unrelated files.
Do not include Markdown image previews, base64, or extra attachments in the final response.
Return exactly:
selected_source=/absolute/path/to/selected-output.png
qa_note=<one sentence>
Use this final visual QA worker prompt:
Visually QA one finalized hatch-pet contact sheet.
Run dir: <absolute run dir>
Contact sheet: <absolute run dir>/qa/contact-sheet.png
Preview dir: <absolute run dir>/qa/previews
Review JSON: <absolute run dir>/qa/review.json
Validation JSON: <absolute run dir>/final/validation.json
Inspect the contact sheet and the preview GIFs visually. Confirm the same pet identity, style, palette, silhouette, face, proportions, and props across all rows:
0 idle, 1 running-right, 2 running-left, 3 waving, 4 jumping, 5 failed, 6 waiting, 7 running, 8 review.
Fail rows with identity drift, missing/blank frames, copied guide marks, white/nontransparent backgrounds, cropped bodies, slot overlap, detached effects, shadows/glows/smears/dust, chroma-key artifacts, motion that does not match the row state, unintended size popping, wrong facing direction, reversed or non-alternating gait, or idle loops that are effectively static.
Do not edit files, queue repairs, package, clean up, or inspect unrelated files.
Return exactly:
visual_qa=pass|fail
qa_note=<one sentence summary>
repair_rows=<comma-separated row ids, or none>
repair_notes=<short row-specific notes, or none>
Repair Workflow
If frame inspection or final visual QA fails, read qa/review.json, regenerate the smallest failing scope, copy the replacement row into the same decoded output path, and keep that job marked complete with the new source_path and completed_at. Repair the failed row, not the whole sheet.
For identity repairs, use the canonical base image, original references, contact sheet, and exact row failure note as grounding context. Give the row worker the existing row prompt plus a compact repair note from qa/review.json; preserve the canonical pet identity and chosen style.
For extraction-induced motion popping, do not regenerate imagery first. If the source strip already preserves row-level scale and baseline, rerun the deterministic pipeline with --method stable-slots, inspect with --allow-stable-slots, then re-check the preview GIFs. Regenerate the row only when the original strip itself is clipped, unstable, or semantically wrong.
Rules
Keep $imagegen as the primary generation layer.
For brand/product/company/prospect requests without a concrete avatar description or reference image, run brand discovery before base generation and pass only the compact brief into the run.
Use $imagegen as the only visual generation layer. Do not invoke image APIs, image CLIs, local raster generators, or one-off generation scripts from this skill.
Keep reference images attached/visible for $imagegen whenever the chosen path supports references.
Attach the row's references/layout-guides/<state>.png image to every row-strip job as a layout-only guide, and do not accept outputs that copy guide pixels.
Use lightweight visual workers for base generation, row-strip visual generation, and final contact-sheet QA by default; the parent owns manifest updates, deterministic image scripts, packaging, and cleanup.
Generate every normal visual job with $imagegen: base plus all row strips that are not explicitly approved running-left mirror derivations.
Treat only the base job as eligible for prompt-only generation; every row job must attach its listed grounding images.
Generate running-right before deciding whether running-left can be mirrored.
When running-left is mirrored, preserve frame order and timing semantics; derive it through the deterministic script instead of mirroring an entire strip wholesale.
Do not derive or reuse waiting, running, failed, review, jumping, or waving from another state; each has distinct app semantics and must be generated as its own row.
Never substitute locally drawn, tiled, transformed, or code-generated row strips for missing $imagegen outputs.
Only mark a visual job complete after its selected output has been copied into the decoded output path.
Do not rely on generated images for exact atlas geometry; use this skill's deterministic image scripts.
Use the chroma key stored in pet_request.json; do not force a fixed green screen.
Keep the pet's silhouette, face, materials, palette, style, and props consistent across all rows.
Treat visual identity or style drift as a blocker even when qa/review.json and final/validation.json have no errors.
Treat a contact sheet that shows cropped references, repeated tiles, white cell backgrounds, or non-sprite fragments as failed.
Treat preview GIFs that show extraction-induced size popping, reversed directional timing, wrong facing direction, or inert idle loops as failed.
Treat qa/review.json errors as blockers. Warnings require visual review.
Acceptance Criteria
Final atlas is PNG or WebP, 1536x1872, transparent-capable, and based on 192x208 cells.
Used cells are non-empty and unused cells are fully transparent.
Atlas follows the row/frame counts in references/animation-rows.md.
Contact sheet and per-row motion previews have been produced and inspected by a lightweight visual QA worker.
qa/review.json has no errors.
Row-by-row review confirms the animation cycles are complete enough for the Codex app.
Motion previews do not show unintended size popping, reversed directional cadence, or wrong row semantics.
Non-pixel styles are accepted when readable at pet size and consistent across rows.
${CODEX_HOME:-$HOME/.codex}/pets/<pet-name>/pet.json and ${CODEX_HOME:-$HOME/.codex}/pets/<pet-name>/spritesheet.webp are staged together for custom pets.
