pixellab-pip — скилл для Claude Code: установка и генерация графики

---
name: pixellab-pip
description: Use when PixelLab (Pixel Lab) or Pip skill context is present for setup/auth (PIXELLAB_SECRET, bearer token), MCP/API routing, asset generation, endpoint choice, SDK integration, sprites, sprite sheets, characters, portrait characters, objects, tiles, tilesets, tilemaps, maps, Godot/Unity map export, icons/UI/fonts, backgrounds, palettes, image edits, animation/VFX, talking portraits, vocal animations, talking GIFs, lip sync, skeleton/template/preset animation, looping/seamless or multi-shot cinematics, project art styles, animation inspection/repair, blueprints/recipes and `*.blueprint.json` replay, Workbench, Aseprite/Pixelorama, Game Builder, docs/troubleshooting or generations/cost/credit budgets. Covers MCP, public REST v2, website/editor assistance and explicit legacy v1 integration. Also use for explicit skill setup, update, uninstall, auto, panel and bark (completion sound) commands. Do not trigger for Python pip/package management or generic image/pixel-art requests without PixelLab intent.
license: MIT
metadata:
  requires_api_key: "false"
  api_key_env: PIXELLAB_SECRET
  api_key_note: "Optional. Guidance, setup, routing, and docs need no key. Live PixelLab generation needs a bearer token, configured in the MCP client or as PIXELLAB_SECRET for REST v2 fallback; the skill uses it only as an auth header and never reads, prints, or stores its value."
permissions: # local helpers read/write outputs and config; fetch.py uses only documented PixelLab download/file hosts
  - env
  - shell
  - file_read
  - file_write
  - network
---

# PixelLab Pip

Classify the request, choose the supported PixelLab surface, then act. Answer questions directly when the request is a question.

## Workflow

1. Classify intent; values combine, such as `animate + cost_sensitive`:
   `question | setup | update | uninstall | bark | auto | panel | create asset | edit/transform | animate | pixelart_workbench | prompt_enhancement | cost_sensitive | integrate/code | check balance/status | troubleshoot docs/API | website/editor assistance | game_builder | aseprite_integration | blueprint/recipe`.
   A standalone command word after an explicit skill invocation, such as `/pixellab-pip setup` or `@pixellab-pip bark off`, is that intent: for setup read `references/setup.md`, for update read `references/update.md`, for uninstall read `references/uninstall.md`, for bark read `references/bark.md`, for auto read `references/auto.md`, for panel read `references/panel.md`.
2. Classify the target:
   `general_image | skill_icon | item_icon | background | character | portrait_character | font | object | effect_vfx | ui | whole_map | map_image | map_object | top_down_tileset | sidescroller_tileset | multi_shape_tileset | path_tiles | building_kit | isometric_tile | tile_variants | animation | existing_image`.
   Fitted visual additions to an existing character image, such as hair, facial features, wearables, accessories, or held gear, are `existing_image` paperdoll edits, not standalone `object` requests, unless the user explicitly wants a separate unattached prop.
3. Choose the surface with Surface Rules, then the route with the Intent Router. When the user explicitly asks for Aseprite handling, read `references/aseprite-cli.md`; PixelLab MCP/REST generates, documented Aseprite CLI/Lua handles local workspace, import/export, packaging, and launch only.
4. Use MCP only if PixelLab MCP tools are visible as callable tools, bare or prefixed such as `mcp__pixellab__create_character` (match by suffix). If the user explicitly asked for MCP, do not silently fall back; report that MCP is unavailable and offer setup or an approved REST v2 fallback. Otherwise, when MCP is unavailable, use the matching documented REST v2 endpoint. If both are unavailable or fail, explain why before any non-PixelLab fallback.
5. Before repeated paid prompt-only retries, inspect the chosen tool or endpoint schema for generation controls such as guidance, adherence/strength, reference images, palette images, or style options, and use the ones that target the failure mode. Before the first paid call to any endpoint that consumes a supplied input image, inspect its schema and embed the source image in the correct field — never send such a request without its input image. Refresh official docs only when a needed tool, endpoint, field, auth, SDK, pricing, or model/mode fact is missing or unclear (see Current Docs Refresh).
6. Before already-routed generation, check only the selected project root for `pixellab-pip-style.json`; when present read `references/project-style.md` for the effective style, temporary overrides and legacy restrictions. No profile means ordinary one-off work without forced setup. For consistency-sensitive work, summarize the user's identity, style, palette, view, and reference anchors. Ask up to three blocking questions before a credit-spending call.
7. Prepare natural-language parameters per Text Preparation. For non-English or mixed-language requests, read `references/localization.md`.
8. For animation, preserve the user's requested frame count; otherwise use the endpoint or template default. Read `references/animation.md` for generated-versus-returned counts and input-echo verification before quoting or validating a count. Exception: preset/template character animations take no `frame_count`; pick a matching template id such as `walking-8-frames` (catalog in `references/preset-skeleton-template-animation.md`) or fall back to v3 custom mode. Preserve PixelLab's returned frame order; no ping-pong, reversed, duplicated, or trimmed outputs unless the user asks for that playback style.
9. If the user says cheap, budget, low-cost, fewer credits, or similar, read `references/cost-routing.md` before choosing a paid route, and ask before each extra paid attempt unless the run's approved retry allowance in `references/auto.md` → Bounded plans and resuming covers it.
10. Before live generation, confirm the PixelLab bearer token is configured without asking the user to paste it into chat (see Auth And Execution).
11. `seed`: omit by default; PixelLab randomizes it. Send it in three cases only — the user gave a seed (send verbatim), a candidate batch whose blueprint sets distinct seeds (send them as written), or two or more calls share near-identical wording and should attempt to hold the same composition (seed-lock, not a guarantee): generate one random positive integer (`0` means random, so never 0) and send that same value on every call in the set. Never ask the user for a seed.
12. Act or answer. Once the job's live generation(s) have returned image(s) — after the last one in a chain — do three follow-ups before the final report, even if the user did not ask: the completion sound (`references/bark.md`), the manifest (`references/usage-reporting.md`), and the `*.blueprint.json` (`references/blueprint.md`). Then send one final report. Ask a short clarification only for known collisions. Before that report, send only a blocker, a question you need answered, the approval or auto-on card, or a needed resume clarification — never progress, status, findings, or intentions; those belong in the final report. For a pending job, keep polling its getter in-turn until its status is `completed` or `failed` — a still-running job is never a reason to end the turn (`references/job-lifecycle.md`). If the turn is being cut off before it finishes, continue with a bounded background wait instead of stopping. Hand the job back to the user only when you can do neither — no way to keep polling and no way to background a wait — then report the job or asset ID and the getter that resumes the check, and say credits were spent. Exception — chunk reveal: when an approved run produces several separately-completing image jobs (a multi-shot cinematic chain, an all-directions animation, an approved multi-asset batch), post each job's saved output — path and inline preview link — as that job completes, and fold the last job into the final report rather than revealing it twice. This covers distinct sequential jobs only, not the multiple images a single job returns at once (8-direction character, animation frames, rotations, tileset tiles, review candidates), which go straight to the final report.

## Asset Integrity

- Every pixel of requested art must originate from PixelLab or the user. Local tools may read, download, assemble, package, import/export, preview, verify, mask, pad, crop, resize, and format-convert those pixels. Locally authored generation controls such as masks, palette swatches/`color_image`, reference guides, and shape templates are allowed as inputs; report them as inputs. Do not draw, repaint, or synthesize requested content locally unless the user explicitly approves a labeled non-PixelLab fallback.
- Reviewable static candidates: when a static image-style MCP tool or REST endpoint returns multiple alternatives, read `references/reviewable-candidates.md` before selecting, saving, or continuing from one.
- Do not bake a colored, checkerboard, white, black, green-screen, or matte background into transparent frames, final GIFs, spritesheets, previews, or report images unless the user explicitly asks for it. A checkerboard is allowed only as a clearly labeled inspection aid kept separate from final deliverables.
- Do not post-process PixelLab output into a claimed final asset without explicit approval. Local crop/split/format work that preserves original pixels is allowed when reported honestly; resizing, reassembling, compositing, or repairing failed outputs locally must not be called final without approval. Exception: when a request used `no_background: true` but the output kept a background, read `references/background-removal.md` and attempt safe removal when verification shows the background is removable without changing the art.
- Save downloaded generations, derived previews, manifests, and packages in a named per-generation subfolder under the `pixellab-pip-generations/` folder at the user's project/workspace root — not loose in its root, and never resolved against a background or detached process's working directory, which may default to the home folder — unless the user names another location. A returned base64 image may be raw RGBA rather than PNG; confirm a saved image decodes to a valid PNG, and when a response exposes more than one image field, save the PNG-encoded one. Produce only the requested output formats or the route's minimal standard artifacts. When a job returns multiple separate images, always compile one standard preview alongside the individual files: a spritesheet for a collection of distinct sprites, or a looping preview GIF when the images are frames of a single animation (read `references/local-asset-assembly.md` for spritesheet grids and GIF settings). No APNG or extra preview/viewer formats unless asked.
- After a generation returns image(s), write a `<name>.blueprint.json` beside the outputs per `references/blueprint.md` — canonical portable `_pixellab` connection metadata, the exact route bodies, structured `TASK` steps for material work performed outside PixelLab calls, and a `_comment_prompt` holding the user's original prompt as they intended it. Remove host-added wrappers such as connector Markdown, app URIs, hidden local paths, or tool-call serialization; keep the visible command text, such as `/pixellab-pip`. When the generation used one or more user-supplied input images (any role — source, reference, style, mask, init, frame, and the like), copy each into the folder by copying the file, not by reading and re-writing it.
- After every live generation flow, write a manifest beside the outputs using `references/usage-reporting.md`; keep its private audit/resume data out of the shareable blueprint.

## Destructive Remote Actions

Deleting, clearing, or overwriting existing remote PixelLab assets — characters, objects, tiles, tilesets, fonts, UI, portraits, effects, maps and the objects placed on them, their states, animations, or tags — in a way that discards or replaces content already stored remotely is irreversible and requires explicit user permission before it happens: either an instruction that names the deletion or overwrite, or the user's approval of a destructive change you propose. Creating a new asset, state, or animation is additive, not destructive, and is not gated here. Never delete or overwrite unilaterally as an inferred fix, cleanup, reset, sync, migration, or troubleshooting step, and never because a local list, cache, or app view looks empty, stale, or out of sync — the remote is the source of truth, so investigate read-only first (`list_*`/`get_*`, REST `GET`) and report what you find instead of destroying it. Proposing a destructive change is fine; carrying it out before the user approves is not. Before a confirmed destructive op, list exactly what will be removed or replaced (names/IDs and count); bulk or clear-all requires the user to confirm that scope. This covers the `delete_*` MCP tools, MCP `save_to_asset` when its target already exists, `remove_map_object`, terrain-erasing `edit_map` and tile-erasing `place_map_tiles` ops (preview them with `dry_run: true` first), REST `/vfx` calls with `effect_id` (saved over in place), and REST delete/replace endpoints.

For character file synchronization, compare the returned `updated_at` value or URL `?t=` stamp with the local copy and download only changed assets; do not use a stale cached image as evidence that the remote needs replacement.

## Surface Rules

| Surface | Use for | Avoid |
|---|---|---|
| Hosted MCP | Managed PixelLab assets with IDs, polling, downloads, list/get/delete helpers, Creator gallery browse/save-back (`list_images`, `save_to_asset`), animated VFX (`vfx_workbench`), talking-portrait/lip-sync tools, and map/project/sandbox/agent helpers, including `get_upload_url` for local-image uploads, `create_ui_asset`, `create_font`, or `create_portrait_character` when visible; also raw-image primitives `create_image_pixflux`/`create_image_pixen`/`create_image_pro`/`get_image`, `edit_image`, `edit_image_pixen`, `inpaint_image`, `animate_image`, `animate_image_pixminimax`, `animate_with_skeleton_v3`, `create_normal_map`, `transfer_outfit`, `image_to_pixelart`, `image_to_pixelart_pro_flash`, and the cleanup tools `unzoom_image`/`correct_pixelart`/`reduce_colors` when visible — these need no managed asset. PixelArt Workbench uses its own command workflow; read `references/pixelart-workbench.md` for supported inputs. Pro Flash image-to-pixel-art conversion is available alongside image, character, object, edit, and inpaint tools; read `references/pro-flash.md`. | REST-only controls such as multi-image style reference (`generate-with-style-v2`), freeform UI (`generate-ui-v2`), image-to-text, stateless lip sync, the older Pro image-to-pixel-art route, or packed spritesheet/ZIP export; resize and remove-background (no MCP tool); or any MCP call when PixelLab MCP tools are not visible. |
| REST v2 | Scripts, batch jobs, server integrations, exact endpoint control, and REST-only capabilities such as multi-image style reference, freeform UI, base-tier edit/inpaint controls, one-pose skeleton estimation, legacy three-frame skeleton animation, image-to-text, and route-specific enhancement fields that the visible MCP tool lacks (see the Intent Router for exact routes) — plus any of the MCP-covered work below when MCP tools are not visible. | Guessing SDK methods without checking the installed SDK or current docs. |
| Website / Map Workshop / Game Builder | Human product surfaces, the Creator queue, Game Builder (Tier 1+), full-map manual work, Godot/Unity map export, rich libraries, visible browser assistance. | Programmatic use of copied browser session tokens or undocumented internal endpoints used by first-party surfaces. |
| Aseprite plugin | In-editor workflows when the user is actively working inside Aseprite. | Treating private first-party extension endpoints as public REST/MCP contracts. |
| Aseprite CLI | Explicit Aseprite handling after PixelLab produced files: `.aseprite` workspaces, importing frames as layers/frames/tags, palette work, export/open via documented CLI/Lua. | Mouse/OCR UI automation or hidden control of the PixelLab Aseprite extension. |
| Pixelorama / website editor | The PixelLab website editor is Pixelorama-powered; assist it only as visible browser automation after explicit permission, and ask again before login/session actions, spending credits, generations, downloads, edits, or deletes. | Hidden automation, undocumented endpoint calls, or any destructive action without a second confirmation. |
| REST v1 | Existing legacy code and old SDK compatibility. | New work unless the user explicitly needs v1. |

Hosted MCP tool names are not REST endpoints; do not curl MCP tool names as `/v2/...` paths.

## Intent Router

For any atlas or spritesheet request with known or requested cell dimensions, also read `references/local-asset-assembly.md` for the required grid inspection preview.

| User intent | Default route | REST v2 route for code/exact control |
|---|---|---|
| Explicit Pro Flash image, character, object, edit, inpaint, or image-to-pixel-art conversion; Pro Flash comparison | Read `references/pro-flash.md` for the separate tools, native-size and input rules, operation-specific costs, provisional cost checks, and verification. Do not silently replace a tested default with this unbenchmarked family. | `create-image-pro-flash`, `create-character-pro-flash`, `create-object-pro-flash`, `edit-image-pro-flash`, `inpaint-image-pro-flash`, `image-to-pixelart-pro-flash`; `GET /pro-flash/capabilities` and `/pro-flash/cost`. |
| PixelLab experimental Create VFX page | Use the visible website page `https://www.pixellab.ai/create-vfx` only when the user specifically requests that page. MCP `vfx_workbench` is a separate agent-authored workbench; REST `POST /vfx` is documented as the page's own effects artist. | `POST /vfx`; read `references/vfx-workbench.md`. |
| Managed/multidirection character, player, NPC, enemy, creature (default for general character requests) | MCP `create_character` with `mode="v3"` by default, then `create_character_state`, `animate_character`, `get_character`, `update_character_tags`, list/delete helpers. Read `references/preset-skeleton-template-animation.md` when body plan or reference images matter. A character group's `name` is shared; when the user names a new state, pass `state_name`, otherwise PixelLab derives it from the edit description. For a follow-up animation on a multi-direction character, animate `south` first; ask before animating all directions. `outline` and outline wording in `description` are both ignored on v3 and Pro character generation; say so instead of spending credits tuning it. Neither the schema nor an echoed `get_character` value is evidence otherwise — only changed art is. Pixen/v3/new may underweight user instructions for shape, pose, or view. Offer Character Pro when it fits the request after disclosing its higher cost and different style; use it only if the user chooses it. `get_character` returns a download link, not a full ZIP bundle — use REST `GET /characters/{id}/zip` for the packaged archive, or `GET /characters/{id}/spritesheet` (object twin `GET /objects/{id}/spritesheet`) for one packed sheet plus a layout JSON. PixelLab sets the cell size, so a user-specified cell size still needs local assembly. | `create-character-v3`, `create-character-with-4-directions`, `create-character-with-8-directions`, `create-character-pro`, state/animation/tags/ZIP/list/get/delete endpoints. |
| Explicit single still character sprite | Use the general-image row and read `references/characters.md` for candidate/identity checks. Use Pro Flash only when selected under `references/pro-flash.md`, not as an automatic upgrade. | The selected general-image route. |
| Text-only quadruped character | Default to v3: ask for a south-facing reference and use `mode="v3"` with the matching template; v3 without a reference is humanoid-only. If the user requires text-only, explain that v3 does not support text-only quadrupeds and offer Pro Flash (`create_character_pro_flash` with the matching `template_id`; read `references/pro-flash.md`) or Pro only as opt-ins after disclosing their cost. Read `references/preset-skeleton-template-animation.md` for templates. | Default to `create-character-v3` with a matching quadruped `template_id` and reference. Offer `create-character-pro-flash` or `create-character-pro` only if the user explicitly chooses text-only after the cost is clear. |
| Supplied character reference image to managed character | Use MCP `create_character(mode="v3")` with a finished south-facing sprite; supply `direction_images` for other views to preserve them. For loose concept art that should seed a Pro character's look without preserving pose or canvas, use `concept_image_url` or `concept_image_base64` only after the user chooses Pro. Read `references/image-input-roles.md` and `references/preset-skeleton-template-animation.md` for role and direction rules. | REST `create-character-v3` also supports matching quadruped `template_id` values; REST `create-character-pro` supports `method="create_from_concept"`; use the live schema for exact fields. |
| Portrait-to-character or character-to-portrait | MCP `create_portrait_character` + `get_portrait_character` when visible. | `portrait-character-pro` (Pro image conversion). Supplied-image roles: `references/image-input-roles.md`. |
| Talking portrait, mouth/viseme sprites, talking GIF, or lip-sync timing plan | Read `references/vocal-animation.md`. Use the MCP `set_character_portrait`, `create_vocal_animation` + `get_vocal_animation`, `create_talking_gif`, and `get_lip_sync` tools when visible. | `POST /characters/{character_id}/portrait`, `POST` + dedicated `GET /vocal-animation/{job_id}`, `POST /talking-gif`, and `POST /lip-sync`; REST is required for stateless lip sync. |
| Pixel/bitmap font, font atlas | MCP `create_font` + `get_font` when visible. | `generate-font-pro` (Pro). |
| Skill/ability/spell/action-bar/hotbar icon, inventory item/equipment/loot/pickup icon, emoji, or icon sheet | Read `references/icon.md` before choosing an endpoint or generating. | The reference covers route choice, background defaults, sheet sizing, prompt wording, and verification. |
| Standalone object, prop, pickup, weapon, furniture (not an icon) | MCP `create_1_direction_object`, `create_8_direction_object`, object state/animation/tags/review tools. Pass MCP `name` when the user names a new object; it defaults to the description. An object's name is shared across directions and states; for a named new state pass `state_name`, otherwise PixelLab derives it from the edit description. Object creation is Pro Tools; generation cost follows the announced 10/15/25 size bands (see `references/cost-routing.md`). | `create-1-direction-object`, `create-8-direction-object`, object state/animation/tags/list/get/delete endpoints. The REST create schemas have no `name` field; if the stored name matters and MCP is unavailable, tell the user before creation. |
| Tileset or terrain transition with no stated type or projection; square top-down, Wang, or autotile tileset | Read `references/tileset.md`, then MCP `create_topdown_tileset`; this is the default when no tileset type, projection, or route is specified. | `create-tileset`, `tilesets`. |
| Explicit hex, isometric, or oblique connectable terrain transition; or explicit `create_tiles_pro`/`create-tiles-pro` tileset mode | Read `references/tileset.md`, then MCP `create_tiles_pro` with `tile_feature="tileset"`. | `create-tiles-pro` with `tile_feature: "tileset"`, then `tiles-pro/{tile_id}`. |
| Sidescroller/platformer tileset | Read `references/tileset.md`, then MCP `create_sidescroller_tileset`. | `create-tileset-sidescroller`. |
| Isometric tile/block/floor | MCP `create_isometric_tile`; map thickness wording to `tile_shape` (`thin tile`, `thick tile`, `block` — same values as REST, default `block`). | `create-isometric-tile` with `isometric_tile_shape` (`thin tile`, `thick tile`, `block`). |
| Multiple independent tile variants (hex, octagon, square, or isometric) | MCP `create_tiles_pro` with no `tile_feature`. | `create-tiles-pro`, `tiles-pro/{tile_id}`. |
| Connectable path/road tile set | MCP `create_path_tiles`; shares `get_tiles_pro`/`list_tiles_pro`/`delete_tiles_pro` with `create_tiles_pro` — no dedicated getter. | `create-tiles-pro` with `tile_feature: "roads"`. |
| Building kit (floor, connectable walls, doorways, pillar, stairs) | Read `references/tileset.md`, then MCP `create_building_kit`; shares `get_tiles_pro`/`list_tiles_pro`/`delete_tiles_pro` with `create_tiles_pro` — no dedicated getter. | `create-tiles-pro` with `tile_feature: "building"` and `building_*` fields. |
| Hard-projection top-down/south-facing building sprite | Read `references/style-reference.md`; use MCP `create_image_pro` or REST `generate-with-style-v2`; apply the reference's verification. | Do not route a single sprite to `create_building_kit`. |
| General image, sprite, standalone asset that is not an icon or emoji | MCP `create_image_pixflux`/`create_image_pixen`/`create_image_pro` + `get_image` when MCP-first — same model choice as REST, minus multi-image style reference (REST-only). For explicit Create Image Pro, `create_image_pro`/`generate-image-v2`, exact grids/sheets, or below-32px cells, read `references/create-image-pro.md` first. For full-body Pixen characters, read `references/pixen-character-prompt.md`. Model character: PixFlux = lower detail, loose/painterly (frames whole subjects); Pixen = high detail, tight framing; Pixen and Pro crop larger subjects; Pro for style/variety or closer adherence to the user's description. Pixen/v3/new has isometric bias and may underweight user instructions such as `view`/`direction`; prefer Pro for static south-facing when higher cost and different character style is acceptable. Pixen `no_background: true` allows up to 65,536 px of canvas area (e.g. 256×256 or 512×128); a larger canvas is refused with it on. | `create-image-pixen`, `generate-image-v2`, `create-image-pixflux`, `generate-with-style-v2`. |
| Exact hex palette or color cap on a generated asset or animation | Read `references/create-image-pro.md` (Exact Palette Control) before choosing the route: many MCP (`palette`) and REST (`target_palette`) routes accept it, with surface and mode limits. | The selected route's `target_palette`; see the reference. |
| Generate a normal map for a sprite or animation | Read `references/image-input-roles.md`; use MCP `create_normal_map` + `get_image` when visible, otherwise REST `POST /normal-map`. The 0.4.130 announcement also lists Creator availability, but does not document its UI flow. | `/normal-map` accepts a PNG sprite or an equal-frame horizontal strip; choose `convention="directx"` for Unreal, otherwise the default is OpenGL. |
| Browse/search the Creator gallery, inspect or edit a gallery reference, or save generated/edited pixel art back into a character, object, animation direction, or gallery | MCP `list_images` for gallery metadata; pass its `gallery:<id>` reference to `get_image` to download or to `pixelart_workbench` for inspection/editing; use `save_to_asset` for save-back when visible; read `references/mcp-platform-tools.md` for target and destructive-save rules. | No public REST v2 equivalent is documented. |
| Pixel-level repair or recipe drawing; inspect, measure, lint, compare, or animate source parts | For explicit pixel operations, read `references/pixelart-workbench.md` and use MCP `pixelart_workbench`. Keep open-ended image creation on the normal image-generation routes. | MCP-only `pixelart_workbench`; no public REST equivalent. |
| PixelLab image description or visual Q&A | Use REST `POST /image-to-text` when the user wants PixelLab's read of an image: the default is a generic 1–3 sentence generation description; an optional prompt requests a custom visual answer. For improving existing text for a known generation route, use its matching enhancer instead; do not chain image-to-text before enhancement by default. Answer ordinary image questions directly when possible. | REST-only; returns text, not an image. |
| Background, scene, backdrop | MCP `create_image_pixflux`/`create_image_pixen` (`no_background: false`) when MCP-first, else REST v2. Route by whether a subject is present: subject-less backdrop (empty landscape/sky/room, no figure) → PixFlux; full scene with a subject in an environment → Pixen. Do not use Pro `generate-image-v2`/`create_image_pro` here — its 10–25-generation size tiers are unnecessary for backdrops or scenes. | `create-image-pixflux-background` (same schema as `create-image-pixflux`, so `create_image_pixflux` covers it too); verify current size/field support before exact code. |
| UI, HUD, button, panel, health bar, menu | MCP `create_ui_asset` + `get_ui_asset` when MCP-first — it has both `pieces` (rounded_rect/circle/polygon) and `elements` (button, icon_button, toolbar, tab, panel, window, health_bar, avatar, triangle/pentagon/hexagon/octagon); mind its aspect-gated size caps (square ≤512×512, 16:9 ≤688×384, 9:16 ≤384×688, 4:3 ≤600×448, 3:4 ≤448×600). Use REST v2 `create-ui-asset` (Pro) when MCP is unavailable. `generate-ui-v2` (REST-only, no MCP tool) for loose/raw UI images, especially with a `concept_image`. | Do not route shape-piece/layout requests to `generate-ui-v2`. |
| Image edit, inpaint, mask, convert, resize, remove background | For supplied images read `references/image-input-roles.md`. MCP `edit_image` and `inpaint_image` are Pro routes with size-tiered costs (see `references/cost-routing.md`); prefer their URL inputs and use inline base64 only when needed. MCP `edit_image_pixen` is the cheap text-instruction edit (1 generatio...