Phaser 4 Spine Generative Reskinning

Global Control Integration

Control Plane Boundaries: Proposals, reviews, and modifications are allowed within the scope of established and task-authorized valid Work Items, and must return to

$phaser4-game-workflow-control

for audit and state migration; only actual A4-A6 operation requests require approval.

Spine reskinning belongs to the resource production domain and must not bypass global control. Modifications are only permitted within established and task-authorized valid Work Items, frozen Implementation Packages, A-level tiers, and Atlas/output paths; every recovery, generation, reconstruction, and verification must submit evidence and update status in accordance with

phaser4-game-workflow-control

, with only actual A4-A6 operation requests requiring approval.

First resolve

<skill-dir>

to the root directory of the Skill where this

SKILL.md

is located; all tool commands below use

node <skill-dir>/scripts/spine_reskin_progress.mjs

and do not depend on the current working directory. The copy installer will install Sharp in this Skill directory and will not modify the dependency manifest of the target game project.

Complete the entire reskinning process in the following order. Do not claim delivery completion if any Cell is unfinished, fails verification, or has an unknown status.

1. Audit Inputs and Establish Candidate Directory

Locate the
```
.atlas
```
, all Page images, and matching Skeleton JSON/Binary; record Phaser 4, Spine runtime version, texture loader, PMA conventions, and runtime entry point.
Run
```
node <skill-dir>/scripts/spine_reskin_progress.mjs init --atlas <source.atlas> --output <candidate>/progress.json
```
. By default, candidates are written to a new directory; overwriting the original Atlas, Page, or Skeleton is prohibited. Add
```
--reference-dir <candidate>/source-cells
```
when source Cell references are needed.
Review the size, format, filter, repeat, pma, scale of each page in the checklist, as well as
```
xy/size/orig/offset/index/rotate
```
or
```
bounds/offsets
```
of each Region. Stop immediately if duplicate IDs, missing pages, out-of-bounds issues, or unparseable fields are found.
List all Cells in the checklist; do not replace the total count with the number of Attachments, first Page, or visible characters. Record the SHA-256 of the source Atlas, all Pages, and matching Skeleton files to ensure old candidates are not misused later.

Detailed rules for multi-Page, trim/offset/UV, padding/extrusion, PMA, and transparent blank pages can be found in references/atlas-rebuild.md.

2. Freeze Global Style and Structure References

Register global character/material/lighting/color/outline references and exclusions in the checklist; pass both the original Cell reference image and the same global reference to each Cell simultaneously.
Original Cells can only be used for references to structure, proportions, transparent outlines, cropping boundaries, and Mesh semantics, or as masks for generation models. Copying original image RGB values, extracting original image pixels, using original Pages as output base maps, or falling back to original textures upon failure is prohibited.
Mark whether each Cell is a rigid body, deformable Mesh, attachment ornament, shadow/highlight, or transparent effect. Do not change Attachment names, Skeleton bindings, Mesh vertex order, or UV semantics.

3. Generate and Persist Cell by Cell

First mark the Cell as

generating

node <skill-dir>/scripts/spine_reskin_progress.mjs mark --manifest <candidate>/progress.json --cell <cell-id> --status generating

Use the currently available image generation capability to generate images for each Cell individually. Pass the original Cell reference image, global style/character reference, and
```
orig
```
/
```
size
```
/
```
rotate
```
constraints from the checklist with each request; maintain consistency in face, material, light direction, color, and transparent edges of the same character across Cells. Do not generate images during Skill initialization.
Ensure the output image complies with the structural contract of the checklist: you can provide the uncropped
```
orig
```
size (the tool will extract it according to
```
offset
```
/
```
size
```
), or directly provide the cropped
```
size
```
in positive orientation; rotated Cells must be provided in positive orientation size, then rotated back to the Atlas orientation by the packer. Retain real transparency; do not fill with a solid color background.
Immediately write the generated image to an immutable candidate path and mark the status:
```
node <skill-dir>/scripts/spine_reskin_progress.mjs mark --manifest <candidate>/progress.json --cell <cell-id> --status generated --image <candidate>/generated/<file>.png
```
. The tool will record the SHA-256, number of attempts, and status history; do not manually modify the JSON. If failed, use
```
--status failed --error <reason>
```
, then re-enter
```
generating
```
from
```
failed
```
after fixing.
Run
```
status
```
after each batch of generation; run
```
read
```
when full field review is needed; run
```
recover
```
when the process is interrupted to safely revert
```
generating/validating/packing
```
statuses back to
```
pending
```
before continuing. Do not pass off old images as new ones.

4. Cell-by-Cell Transparency, Shape, and Mesh Semantics Check

Check visible outlines, transparent edges, anchors, directions, shadow layers, and readability against the original Cell reference; check if the generated image's alpha has unexpected backgrounds, holes, or cropping issues.
For Mesh/9-slice/deformable attachments, confirm that key shapes, transparent areas, and local details still fall within the original
```
orig
```
/
```
offset
```
semantics; do not "fix images" by modifying Atlas coordinates.
Mark the Cell as
```
validating
```
; mark it as
```
failed
```
and record the reason if it fails. Only when all Cells pass can you proceed to
```
packing
```
.

5. Rebuild from Transparent Blank Pages

Use
```
node <skill-dir>/scripts/spine_reskin_progress.mjs pack --manifest <candidate>/progress.json --output-dir <candidate>/atlas
```
. The tool will create fully transparent RGBA blank pages for each original Page, and only place the generated images back according to the original
```
xy/size
```
; it will not read pixels from the source Pages.
Retain the original Region names, Page order, coordinates, trim/orig/offset, rotate, index, filter, repeat, scale, and fields required by the Skeleton. Write back according to the original rotation direction; convert the generated image from straight-alpha to premultiplied-alpha based on the Page's
```
pma
```
.
Set
```
--padding
```
and
```
--extrusion
```
according to project conventions; padding and edge expansion can only come from the current generated image and must fall within the original Region rectangle, without changing UV coordinates. Multi-Page outputs must be generated page by page and maintain corresponding Page references in the new Atlas.
If any Cell is missing an image, has mismatched dimensions, is out of bounds due to rotation/cropping, has unavailable Sharp, or fails to write to disk, keep the candidate incomplete, record
```
failed
```
, and retry after fixing. Do not release partial Pages.

6. Completion Gate and Phaser Runtime Verification

After successful packing, the tool will mark the Cell as
```
completed
```
and record the hash of the candidate Page/Atlas. Run
```
node <skill-dir>/scripts/spine_reskin_progress.mjs verify --manifest <candidate>/progress.json
```
; return a non-zero code if incomplete, hash mismatch, or product missing.
Load the new Atlas and original Skeleton in an isolated Phaser 4 candidate scene, play each animation, Attachment, and Mesh deformation to be tested one by one; check for missing images, misalignment, flipping, PMA black edges, transparent backgrounds, UV breaks, and cross-Page issues. Retain at least the overall preview screenshot/screen recording and console logs.
If runtime verification fails, keep the failed candidate, create a new progress checklist, and regenerate, verify, and pack from the affected Cells; do not modify the already
```
completed
```
checklist or overwrite failed statuses. Do not only modify runtime code or claim "visually similar". Manually compare the SHA-256 of the original Skeleton file and confirm that Skeleton/Attachment/Mesh UV remain unchanged; the
```
verify
```
tool does not automatically check the Skeleton. Delivery is only allowed when all Cells in the new checklist are
```
completed
```
, verification evidence is bound to the current candidate hash, and manual comparison passes.

7. Final Artifacts and Recovery

Deliver the new

.atlas

, all new Page PNGs, progress checklist, generated/reference image index, global references, hash checklist, overall preview, and Phaser runtime verification records. Retain the original Atlas and Pages only for rollback comparison; publicly report the ID, reason, number of retries, and next steps for any failed Cell, do not silently skip it.

Progress status and field constraints can be found in references/progress-state.md.

Tool Commands

Run in the repository root directory:

powershell

node <skill-dir>/scripts/spine_reskin_progress.mjs --help
node --test <skill-dir>/scripts/spine_reskin_progress.test.mjs

If Sharp is missing, Node.js will return a dependency resolution error with a non-zero code; dependencies will be placed in the Skill's own directory when installed via the official copy installer.

phaser4-spine-generative-reskin

NPX Install

Tags

SKILL.md Content (Chinese)