Spine Animation AI: a Claude skill that turns part PNGs into a rigged Spine skeleton

The part of Spine production this automates, and the part it does not

Rigging a 2D character in Spine starts with a chore that has nothing to do with animation: placing every separated limb, torso and head sprite at the right coordinates, in the right draw order, before a single bone is keyed. Get the offsets wrong and the character looks assembled from spare parts. The repository targets exactly that step, plus the first animation pass. Its README describes the skill as covering auto-positioning from reference images with SIFT and RANSAC, skeleton JSON construction with bone hierarchy and draw order, generation of idle, walk, run, attack, wave and jump clips, and HTML5 previews through the official Spine Web Player. It also claims a correction path for existing skeletons. The intended user is a solo or small-team game developer who has art but no rigger, and who is willing to paste a skill file into a Claude Project and iterate in chat. It is not aimed at studios with an established Spine pipeline and a dedicated animator, because the output is a starting layout, not a finished performance.

SIFT, RANSAC and the four-script data flow

The mechanism is a chain of files rather than a single program. position_parts.py takes a reference image of the assembled character plus a directory of part PNGs and writes layout.json, optionally emitting debug images into a debug directory. That layout is the contract between stages: build_spine_json.py consumes it via a config flag and writes skeleton.json. make_atlas.py packs the same parts directory into an atlas and a PNG. generate_spine_player.py then takes the skeleton, the atlas metadata and the atlas image and produces a self-contained preview.html. The positioning step is the interesting one: the README states it uses SIFT feature matching with RANSAC to place parts against the reference. That is a classical computer-vision approach, not a learned model, which means it depends on the reference image and the part sprites sharing visual texture. A flat-shaded limb with little internal detail gives SIFT few keypoints to match, and RANSAC will still return a consensus from whatever survives. The debug output directory exists precisely because this step is the one most likely to need human inspection. The adjustment format reinforces that reading: each entry carries original_offset, a user_offset delta with dx, dy and drot, and the resulting final_offset, so a correction is a diff rather than an overwrite.

Three ways to run it, and the one that needs no Claude at all

The README offers three install paths. Option A is a Claude Project: create a project on claude.ai, open Project Knowledge, add content, and paste the full contents of SKILL.md. The README explains the reason this works, stating that SKILL.md is auto-generated with all four Python scripts embedded inline, so Claude extracts and runs them without cloning the repository. Option B is for environments with mounted skill directories: clone the repository to /mnt/skills/user/spine-animation and the skill is discovered on the next session start. Option C is the manual pipeline, which is the only path that does not require Claude. It begins with an optional split step: scripts/split_character.py takes a single character image, calls Google Gemini to generate a deconstructed sprite atlas, and segments it into transparent PNGs through OpenCV connected-components analysis. That step needs a GEMINI_API_KEY environment variable and pip install google-generativeai. The remaining commands are position_parts.py with reference, parts, output and debug flags, then build_spine_json.py with config and output, then make_atlas.py with parts, output and name, then generate_spine_player.py with skeleton, atlas, atlas-image and output. The README states the resulting preview.html opens in any browser with no server. Note that the manual path and the Claude path are not equivalent in effort: the manual path asks you to drive four scripts and inspect debug images yourself, while the skill path delegates that loop to a model.

Reskin Studio and the Gemini dependency it introduces

The newest component, Reskin Studio, is documented as taking a rigged Spine character, a one-sentence description such as emerald and silver royal robes, and repainting the character with Gemini before slicing the result back into per-slot textures and applying it to the live rig. The README claims no redraw and no re-rig, and points to a reskin-app directory. Two things stand out. First, the same README contains an HTML comment marking the reskin demo GIF as a TODO, so the demo asset referenced in the page is not confirmed to exist. Second, the feature moves a second part of the workflow, texture generation, onto a hosted third-party model. That is a meaningful change in posture for a tool whose other stages run locally in Python. Anyone evaluating this for a commercial project should treat the Gemini dependency as the deciding constraint, not a footnote: it determines what you can process, what leaves your machine, and whether the free key tier is adequate for your asset volume.

What the sombrero example does and does not prove

The repository ships one worked example. The README describes examples/sombrero/ as containing sombrero.json (a full skeleton with an idle animation), sombrero.atlas, sombrero.png (a packed atlas spritesheet of 10 parts), and skeleton.json as a skeleton-only variant. It states the character has 10 body parts, 16 bones, and a 2-second idle loop comprising a hip breathing bob, torso sway, gentle head rotation and hat follow-through. That is a real, inspectable artifact and it is the best evidence in the repository that the pipeline produces something loadable. It is also a single data point. One character, one animation, front-facing, with a modest part count. Nothing in the supplied material describes how the pipeline behaves on a quadruped, a character with overlapping cloth layers, or a rig where draw order changes during the animation. The README's animation list includes walk, run, attack, wave and jump, but the example demonstrates idle only. Treat the other clip types as documented capabilities rather than demonstrated ones.

Where the pipeline breaks down

The clearest failure mode is at the front of the chain. SIFT matching against a reference image assumes the reference and the parts are visually consistent. If your reference is a three-quarter view, a painted illustration, or a render with shadows baked in, the keypoint matches will be weaker and the resulting layout.json will place parts incorrectly. The debug directory is the intended escape hatch, and correcting the output means either editing layout.json by hand or going through the adjustment format, which is designed for offsets and rotation but not, on the evidence here, for bone hierarchy changes. The second limitation is the animation layer. The README frames clip generation around the 12 principles of animation, which describes the intent of the generated motion, not a guarantee of quality. Generated walk and run cycles commonly need foot contact timing and weight shift reworked by hand. Third, the licence is listed as NOASSERTION by the repository metadata while the README badge points to PolyForm Noncommercial 1.0. Those two signals disagree, and PolyForm NC restricts commercial use. That is a fact about the files, not legal advice; read LICENSE yourself. Finally, no releases were retrieved, so there is no versioned artifact to depend on.

How it differs from DragonBones and hand-rigging in Spine

The obvious alternative is doing the same work inside Spine itself, using its own auto-trace or manual mesh and bone placement. The difference in approach is where the intelligence sits. Spine's tooling assumes you are looking at the rig and dragging handles; the feedback loop is visual and immediate. This project assumes you can express the placement problem as a computation over two images, and its feedback loop is a JSON file plus a debug render. That is faster when the reference and parts are clean, and slower when they are not, because you debug coordinates instead of dragging a bone. DragonBones is the other comparison point: it is a free, open source 2D skeletal animation editor with its own runtime and its own format, so adopting it means leaving the Spine ecosystem rather than automating part of it. This skill's value is that it stays inside Spine 4.2 and the official Web Player, so the output loads in tools your team may already own. If your team is not already committed to Spine, that advantage disappears and a full editor with an interactive rigging UI is the more direct route.

Maintenance cost, licence posture and what to pin

The last push recorded for the default branch is 2026-08-26, and no releases were retrieved, so there is no changelog to read and no tag to depend on. The maintenance surface has two halves. The Python half is small and self-contained: four scripts plus the split step, with dependencies on OpenCV and google-generativeai. The skill half is generated, since SKILL.md is described as auto-generated with the scripts embedded. That generation step is the coupling to watch. If you edit a script, the embedded copy in SKILL.md is stale until regenerated, and the Claude Project path will run the old code. Anyone forking this should decide which artifact is the source of truth and enforce it. On licensing, the README badge says PolyForm Noncommercial 1.0 while the repository metadata reports NOASSERTION; those cannot both be the operative answer, and the LICENSE file is the only thing that settles it. If you intend commercial use, resolve that before writing any integration code.

Editorial conclusion

Adopt it if you already work in Spine 4.2, have separated body-part PNGs, and want a first-pass layout plus a reviewable offset diff rather than a finished rig. Do not adopt it if you cannot send assets to Gemini, if you need to ship the pipeline inside a closed product (read the PolyForm Noncommercial 1.0 text in LICENSE first), or if you expect the generated idle and walk clips to be broadcast-ready without an animator. Verify three things before committing: which Spine version the emitted skeleton.json actually loads into, how position_parts.py behaves on a character whose reference image is not a flat front view, and whether the adjustments block round-trips through your own review process. The repository ships no release tags, so pin a commit hash rather than tracking main.

Official sources

1. GenielabsOpenSource/spine-animation-ai on GitHub
2. Issues
3. Project website
4. README