Hatch Pet

Hatch Pet

Overview

Create a Codex-compatible v2 animated pet from a concept, brand cue, company/prospect name, one or more reference images, or any combination of those inputs. Every newly hatched pet is an 8x11 atlas with the 9 standard animation rows plus 16 clockwise look directions and is packaged with spriteVersionNumber: 2. The intermediate 8x9 atlas exists only to assemble and review rows 0-8; never package it as a new pet.

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.

Existing Inputs And Upgrades

Treat character art, generated images, standard or v2 atlases, contact sheets, and built-in pet art as first-class grounding inputs.

• Preserve user-provided art as a generation reference; do not assume it already has final cell geometry.
• For an existing valid 8x9 atlas, use it as the rows 0-8 intermediate after deterministic and visual validation, then generate rows 9-10 and package the result as v2.
• For an existing 8x11 atlas, preserve approved standard rows. If a look cell fails, correct the complete containing 8-frame row before deterministic reassembly. Never package a newly generated one-off repair cell beside cells from another generation.
• For a built-in pet, extract and use its atlas or neutral/idle cell as the canonical identity reference.
• Include every image that defines head shape, face, palette, markings, material, flame/ears/hair, props, or look mechanics in look-direction generation.
• When a renderer or source provides a dedicated neutral/front frame, pass it through --neutral-cell; otherwise use the approved idle/default frame. The 16 directional cells never treat 000 as neutral.

Desktop Idle Smoothness

When a user explicitly reports long frozen idle holds, slideshow-like breathing, choppy blinking, or requests higher-frequency desktop idle motion, finish and approve the normal static v2 atlas first, then read references/desktop-smooth-idle.md. Use its opt-in animated WebP runtime wrapper for the visual idle cadence. By default the wrapper re-times the six approved idle poses. When the user explicitly requests an expressive idle, give it a reviewed phase manifest that may add approved mouth-opening, tiny wave, ear twitch, or similarly bounded idle poses generated through $imagegen; the wrapper itself never creates a visual pose or replaces a required visual job.

When the user explicitly asks for roughly 20 frames per action, smoother non-idle task animation, or a 12-15 motion library, also read references/desktop-smooth-state.md. Codex v2 still exposes exactly nine native state triggers; do not claim that an atlas or playback patch creates additional desktop events. Build 12-15 named visual clips inside those nine states, normally using 16-24 synchronized image-time phases per state. Every visually distinct custom phase must come from an approved complete $imagegen pose group or an approved static-atlas cell. Repeated source cells may preserve timing but do not count as new visual frames. All configured states share one animated-WebP time clock, so every phase list must be a valid periodic loop from any entry point and use the same global duration timeline.

When the user instead reports that working, waiting, review, failure, jumping, waving, or directional-running animations stop too soon and explicitly wants more repeats without slower motion, use the separate opt-in desktop playback patch documented in the same reference. The patch must preserve every row's original frame durations and loop the selected non-idle row only while the desktop state remains active. It must verify ASAR integrity before and after, create a restorable backup, and never delay a real state transition. Treat application updates as invalidating the patch until --check confirms it again.

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:

${CODEX_HOME:-$HOME/.codex}/skills/.system/imagegen/SKILL.md

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 $imagegen shared prompt schema.

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.

Runtime Dependencies

Before running any bundled script, call load_workspace_dependencies. Set PYTHON and NODE to the exact Python and Node.js executable paths returned by that tool. Use "$PYTHON" for Python commands and "$NODE" for the optional desktop playback patch. The bundled Python runtime includes Pillow, which these scripts require. Do not use a bare system python; if workspace dependencies are unavailable, stop and report that the bundled runtime is required.

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
• cover identity/category, audience/use context, visual system, personality/tone, product/domain motifs, mascot translation cues, avoidances, and evidence/confidence
• 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: 
User context: 
Output file: 

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=
- brand_brief=
- avatar_seed=
- avoid=
- brand_sources=

Return exactly:
brand_discovery_file=
brand_name=
brand_brief=
avatar_seed=
avoid=
brand_sources=

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.

Generation Contract

Visual Job Graph

Expect up to 13 visual jobs: 1 base pet, 9 standard row strips, 1 required four-cardinal anchor strip, and 2 required coherent look-direction row strips. The standard states are 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.

Look Direction Sequence

After validating rows 0–8, write qa/look-mechanics.md, then generate and approve one four-pose cardinal strip in this fixed order: 000 up, 090 screen-right, 180 down, and 270 screen-left. Generate row 9 as one coherent eight-pose family from those approved cardinal pose families, interpolating the intermediate directions as even 22.5-degree steps. Deterministically register its eight ordered pose groups, then run final-cell edge, semantic, and continuity QA immediately. Only after row 9 passes, generate row 10 as one coherent eight-pose family, using the approved cardinals for direction meaning and completed row 9 for identity, scale, registration, and boundary continuity. Run the same QA immediately after row 10. Row 9 contains 000, 022.5, 045, 067.5, 090, 112.5, 135, and 157.5; row 10 contains 180, 202.5, 225, 247.5, 270, 292.5, 315, and 337.5. 000 means up, not neutral/front. Never ask $imagegen to generate or repair a complete 8×11 atlas.

Visual Provenance And Grounding

After selecting a visual output, the parent agent copies that exact image into the job's decoded/ path, runs its required incremental checks, and only then 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 and chroma-cleanup invariants. Its final edge-local spill-suppression step selects every translucent silhouette-boundary pixel plus opaque boundary pixels whose chroma points toward the known key, then extends clean interior RGB outward through that band in linear light. It preserves alpha exactly, clears hidden RGB under fully transparent pixels, and reports the algorithm and parameters used. The cleanup report plus atlas validator are authoritative for chroma contamination. Once the final report has ok: true and atlas validation passes, do not regenerate imagery or add another chroma-cleanup pass.

Fully transparent pixels are allowed outside the sprite silhouette, in unused cells, and in intentional negative-space openings that are part of the pet's design, such as loops or holes in a ribbon body. Reject any generated or repaired cell with accidental 100%-transparent holes inside a filled body, including horizontal bands, seam rows, scanline-like gaps, sliced-tile boundaries, or "see-through" interior stripes. Inspect suspect cells on a high-contrast background or alpha mask before accepting them; ordinary atlas validation is not enough when the hole is inside the silhouette.

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:

• wave marks, motion arcs, speed lines, action streaks, afterimages, blur, or smears
• detached stars, loose sparkles, floating punc

…

Source & license

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

• Author: srwang0506
• Source: srwang0506/HatchPet-CapybaraLulu
• License: Apache-2.0

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