pixelkiln 0.82.0 → 0.83.0

package/docs/AGENTS.md

@@ -59,8 +59,10 @@ state transitions, and output placement.
 ## Providers, PixelLab MCP, and PixelKiln
 
 The [official PixelLab MCP server](https://github.com/pixellab-code/pixellab-mcp)
-gives an agent direct PixelLab creation tools. It is complementary to PixelKiln,
-not a replacement:
+gives an agent direct PixelLab creation tools, plus `pixelart_workbench` for
+linting, scoring, shading, and repairing art that already exists (MCP-only;
+see [Set up PixelLab](./PIXELLAB.md)). It is complementary to PixelKiln, not a
+replacement:
 
 | Layer | Responsibility |
 |---|---|

package/docs/CHARACTERS.md

@@ -181,9 +181,10 @@ biped on `mannequin`, or one of the quadruped templates. A character that
 is neither (a round robot, a slime) gets a walk from text on the v3
 engine instead; a template on it either fails upstream (`custom`
 template) or redraws the character as the biped it expected. PixelLab's
-"Skeleton V3" model update markedly improved template-loop reliability;
-where earlier guidance favored a custom v3 loop over trusting a template,
-a named template is now the reasonable default for a body it fits.
+"Skeleton V3" update is the separate `skeleton-v3` mode described below, not
+a change to plain `template` loops: the tutorial that announced it says the
+original templates were not recommended for quality, and recommends the new
+model for the same template names.
 
 An animation is one loop of one character (`animation.of`, a base or a
 state) in one `direction`. With a `template` (PixelLab's `walk`,

package/docs/PIXELLAB.md

@@ -146,7 +146,15 @@ comparing notes with someone using a different one:
   is a deliberately partial surface: "the API provides everything that the
   MCP doesn't." Good for ad hoc, conversational generation; it has no concept
   of a project's state, a budget, or what has already been paid for.
-  Complements PixelKiln rather than competing with it.
+  Complements PixelKiln rather than competing with it. It also carries
+  `pixelart_workbench`, a free-for-subscribers command line for art you
+  already have: `lint`, `score`, `inspect`, and `compare` report defects, and
+  `shade`, `selout`, and `repair` return an improved copy under a new id.
+  PixelLab's endpoint list has no matching REST call, so PixelKiln cannot
+  drive it, and its subjects are account ids or image references, never file
+  paths. Use it for a quick check or touch-up in conversation, then download
+  the result and declare it as an asset's `source` to bring it under the
+  manifest.
 - **PixelLab's editor plugins for Aseprite and Pixelorama**, which bring
   PixelLab's create/edit/inpaint/animate/interpolate/reduce-colors tools into
   an existing pixel-art editor's own canvas and layers. Good for a human

package/docs/REVISIONS.md

@@ -58,13 +58,18 @@ input to the provider workflow, not a cross-model quality guarantee.
 
 **From the gallery** (`pixelkiln gallery --edit`): open a completed or
 committed asset's drawer and use "+ New revision" under "Revisions from this
-asset" to create an `image-to-image` child of it — an edit instruction, an
-optional strength, and a new asset id are all it asks for. The button only
+asset" to create a child of it. On a PixelLab sprite the mode picker offers
+`image-to-image`, `animate`, `animate-pixminimax`, `reduce-colors`, and
+`correct-pixelart`; on a PixelLab frame set (or a character's directions) it
+offers `edit-animation`, `reduce-colors`, and `correct-pixelart`, which take
+the whole set. Other providers get `image-to-image`. The form asks only for
+the new asset id, the instruction or motion, and the mode's own options
+(strength, frames, fps, colours, dithering). The button only
 appears once the parent has usable pixels (committed `source`, a current
 downloaded generation, or a current approved quality output); the plan still
 reports `blocked` with the real reason if that turns out wrong once the asset
-exists. `inpaint` needs a mask upload the gallery does not offer yet, so it
-still has to be added by hand.
+exists. `inpaint` needs a mask upload and `interpolate` an ending keyframe, and
+the gallery offers neither, so those still have to be added by hand.
 
 "+ Skeleton animation", beside it on a single PixelLab sprite, creates an
 `animate-skeleton` child instead. The poses come from a keypoints file already

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "pixelkiln",
-  "version": "0.82.0",
+  "version": "0.83.0",
   "description": "Manifest-driven pixel-art generation, review, recovery, and packaging with deterministic provenance.",
   "type": "module",
   "sideEffects": false,

package/skills/pixelkiln/references/pixellab.md

@@ -332,14 +332,17 @@ held-item character, skip the template and write a custom v3 loop with an
 explicit prompt naming the held item and the motion (e.g. "knight holding a
 sword, walking loop") instead of expecting the template to carry it.
 
-PixelLab's own tutorials describe a recent quality jump for named templates
-("Skeleton V3"): the same idle/walking/running/full-sprint-style templates
-existed before, but PixelLab did not recommend relying on them because
-result quality was inconsistent; with the updated model backing them, it now
-does — "the movement is much more usable... much more stable." Prefer a
-named template over a custom v3 loop by default for a body it fits, rather
-than defaulting to a custom loop out of habit; the held-item caveat above is
-the one case that still argues for skipping the template.
+PixelLab's own tutorials announce "Skeleton V3" as the quality jump for named
+templates, and that is the `skeleton-v3` mode above, not a change to plain
+`template`: the tutorial says the original templates were not recommended
+for quality, and the new model is — "the movement is much more usable...
+much more stable." For a body the skeleton fits, prefer `skeleton-v3` over
+both a plain template and a custom v3 loop when the account is Tier 1+ and
+2 to 4 generations a direction is acceptable; plain `template` stays the
+1-generation option at its earlier quality. The held-item caveat above was
+written about plain templates, and whether `skeleton-v3` shares it is
+unmeasured. PixelLab has announced a further Skeleton V3 revision, so recheck
+`animate_character`'s tool schema before assuming today's behaviour.
 
 A pose-only `state` edit (a walk mid-step, a hurt pose) can turn the
 character sideways or away from the camera by default, even on a prompt that

package/skills/pixelkiln/references/revisions.md

@@ -81,16 +81,19 @@ Read this reference when an asset declares `revision`.
   changed input must stop the run before provider work begins.
 - In candidate review, compare the source beside every output. Reject
   silhouette or layout drift before post-processing.
-- `pixelkiln gallery --edit` can create an `image-to-image` revision directly
-  from a parent's drawer ("+ New revision" under "Revisions from this
-  asset"), once the parent has usable pixels. On a single PixelLab sprite,
-  "+ Skeleton animation" creates an `animate-skeleton` revision: poses from a
-  project file, pasted JSON, or "Estimate poses" (one confirmed, un-budgeted
-  PixelLab call), edited in a drag-to-edit pose editor over the sprite,
-  written into the project on save. "Edit poses" on an existing
-  `animate-skeleton` record reopens the editor on its keypoints file. It does not offer `inpaint` (needs a mask upload), `outpaint`,
-  `reduce-colors`, `correct-pixelart`, `animate`, `animate-pixminimax`,
-  `interpolate`, or `edit-animation` yet, so add those by hand.
+- `pixelkiln gallery --edit` can create a revision directly from a parent's
+  drawer ("+ New revision" under "Revisions from this asset"), once the parent
+  has usable pixels: on a PixelLab sprite `image-to-image`, `animate`,
+  `animate-pixminimax`, `reduce-colors`, or `correct-pixelart`; on a PixelLab
+  frame set (or a character's directions) `edit-animation`, `reduce-colors`,
+  or `correct-pixelart`; on other providers `image-to-image`. On a single
+  PixelLab sprite, "+ Skeleton animation" creates an `animate-skeleton`
+  revision: poses from a project file, pasted JSON, or "Estimate poses" (one
+  confirmed, un-budgeted PixelLab call), edited in a drag-to-edit pose editor
+  over the sprite, written into the project on save. "Edit poses" on an
+  existing `animate-skeleton` record reopens the editor on its keypoints file.
+  It does not offer `inpaint` (needs a mask upload), `outpaint`, or
+  `interpolate` (needs an ending keyframe), so add those by hand.
 - Before an outside image becomes a `styleImages` or `reference` path,
   suggest `pixelkiln unzoom --from <file>`: upscaled pixel art (every art
   pixel a block of screen pixels) degrades every reference-taking PixelLab