evomeme 0.1.9 → 0.1.10-beta.13

package/dist/skills/en-US/game-tile-generator/SKILL.md

@@ -0,0 +1,152 @@
+---
+name: game-tile-generator
+description: Generate, edit and optimize tilemap resources. Must use this skill when generating tilemaps or seamless tiles; also use it to create terrain textures, two-terrain transition tilesets or repair repeating seams on existing tiles. MCP tools produce square terrain tiles, 4x4 transition atlases or repaired PNGs; explains outputs, use cases, tiles, tiling, atlases and seam elimination.
+---
+
+# Tilemap Resource Generation, Editing and Optimization
+
+Always use this skill when generating tilemaps or seamless tiles. Determine whether the task needs a repeating texture, a two-terrain transition tileset, or seam repair on an existing tile. For tilemap creation, this skill covers terrain image generation and optimization; implement map placement, collision and autotile rules in the target engine after obtaining the assets.
+
+
+Use [Scrolling Map Resource Generation and Editing](../game-scroll-generator/SKILL.md) for horizontal scrolling backgrounds, midground/foreground layers and left/right seam repair. Its `evomeme_eliminate_scroll_background_seam` is separate from square tile seam repair.
+
+## Choose the tool
+
+| Tool | Operation and deliverables | When to use |
+| --- | --- | --- |
+| `evomeme_generate_seamless_tile` | Generate one square terrain texture from a prompt and optional references. Optionally run a second AI generation to repair seams, retaining both the base and repaired images. | Repeat one grass, stone, sand, wall or similar texture in both horizontal and vertical directions. |
+| `evomeme_generate_tile_transition_atlas` | Use two different terrain images, four directional edge generations and one atlas boundary completion to compose one fixed 4x4 PNG containing 16 tiles. | Prepare straight boundaries and corners between two existing terrains, such as grass and dirt or sand and stone. |
+| `evomeme_eliminate_tile_seams` | Cyclically offset an existing square tile, complete its seams with one AI generation, composite the repair and restore the offset. Preserve the source and save/upload one new PNG at the same resolution. | Improve visible horizontal or vertical joins on an existing terrain texture without generating another base tile. |
+
+All three tools share the canvas task and image pipelines, wait for completion, save images under workspace `assets/`, and return text metadata. Use [Game Image Generation and Processing](../game-asset-image-generator/SKILL.md) for illustrations, characters, icons and complete scene backgrounds.
+
+## Terms and deliverable boundaries
+
+- **Tile / terrain block**: one image unit in a map grid, not necessarily a building brick. Tiles here are square, for example 128x128 pixels. Display scaling can change their on-screen size; pixel resolution does not determine physical game units.
+- **Seamless / tiling**: copied images should meet with continuous texture, color and shapes. A single repeating tile must join at both left/right and top/bottom edges. Transition tiles must be selected with compatible terrain patterns on their shared edges; arbitrary pairs are not interchangeable.
+- **Seam elimination**: cyclically offset the base image by half its width and height, moving the original outer seams to the center. Mark a central cross for AI repair, copy only that region back, then reverse the offset. A cyclic offset wraps pixels across the opposite edge instead of discarding them. This is an extra generation, not background removal, edge blur or resizing.
+- **Tileset / atlas**: a tileset is a reusable collection of tile images; an atlas packs those units into one large image. This tool packs 16 cells into one PNG. `tile_size=128` means each cell is 128x128 and the sheet is 512x512, not 16 separate files.
+- **Terrain 0 / terrain 1**: `reference_ids[0]` and `reference_ids[1]`, respectively, such as grass and dirt. Swapping the order swaps terrain assignments in the fixed template. These numbers do not encode elevation, layer depth or priority.
+- **Transition**: the boundary where the two terrains meet within a tile. Straight and rounded shapes come from the built-in template. The prompt guides material, color and style at those boundaries, not the number or arrangement of cells.
+- **Edge protocol**: a shared strip of pixels specifying the terrain pattern along a tile edge. `00` and `11` contain one terrain; `01` and `10` contain both terrains in opposite orders. Four patterns in each of two orientations make eight protocols. Four mixed protocols use AI; four pure protocols come directly from the source textures. These are internal stitching data, not network protocols or eight additional deliverable images.
+- **Mask / inpainting / boundary completion**: a mask identifies pixels allowed to change. Atlas references mark repair regions in opaque magenta `#FF00FF`; a separate local geometry mask controls which generated pixels are copied back. The fifth generation fills internal terrain boundaries while protecting the existing edge protocols. It does not remove every magenta pixel from the original textures. Single-tile seam elimination instead uses a transparent cross as its repair region.
+- **Tilemap / autotile**: a tilemap records which tile occupies each grid position, reusing a small set of images to build a scene. Autotiling chooses tiles according to neighboring terrain. These three MCP tools produce images, not map JSON, collision data, navigation data or engine autotile rules.
+
+## Workspace and references
+
+Pass an explicit absolute workspace root as `workspace_dir`, for example `D:/my-game`. Omitting it uses the MCP process working directory. References must be readable images inside that workspace's `assets/`; IDs are workspace-relative paths such as `assets/terrain/grass.png`, not absolute paths, URLs or Base64.
+
+Locate actual attachment files or external local images before copying them into `assets/`, using a fresh name if needed to avoid overwriting existing assets. Download accessible image URLs first. If the actual file is unavailable, explain which reference is missing instead of inventing an ID. Reuse generated `asset_id` values directly. A tile without references can be generated immediately.
+
+An atlas requires **exactly two different terrain images**. Prefer square, already repeatable textures with matching view, lighting, scale and style. Inputs are resized to squares, so non-square images can stretch. Character images, text and large scene subjects generally make poor terrain textures. Obtain the second terrain if only one is available; do not duplicate the same ID. When the user wants two terrains from scratch, generate each with the single-tile tool and pass the resulting IDs in the intended order.
+
+## Single-tile MCP
+
+| Parameter | Required | Meaning |
+| --- | --- | --- |
+| `prompt` | Yes | Nonblank terrain material, palette, texture scale, top-down view and style. The shared pipeline adds tiling instructions. |
+| `model` | No | Default `asset-pro`; also `asset-max` or `asset-lite`. |
+| `size` | No | Requested size, only `1024x1024` or `2048x2048`; default 1024. Lite requires explicitly selecting `2048x2048`. |
+| `reference_ids` | No | Default `[]`. Up to 10 references for Pro, or 14 for Max/Lite in this workflow. |
+| `seam_elimination_enabled` | No | Default `false`. Adds one AI generation and the offset, repair and restoration steps described above. |
+| `workspace_dir` | No | Absolute workspace root; specify it explicitly when calling. |
+
+```json
+{
+  "prompt": "Top-down forest grass, fine dark green blades with scattered moss, soft even lighting, no large rocks or text, hand-painted game style",
+  "model": "asset-pro",
+  "size": "1024x1024",
+  "seam_elimination_enabled": true,
+  "workspace_dir": "D:/my-game"
+}
+```
+
+Without seam elimination: one AI generation and one saved base image. `base` and the final image refer to the same file. The base retains the provider's image format; use `mime_type` rather than assuming PNG.
+
+With seam elimination: normally two AI generations and two saved images, the base and a repaired PNG. Temporary repair references are not deliverables. The final PNG is uploaded; top-level `asset_url` / `tos_url` identify the **composited image after restoring the offset**. `outputs` lists the base first and repaired image second; top-level `asset_id` / `local_path` identify the repaired image.
+
+This tool does not accept `background` or `transparent_background`, or perform cutout. The default pipeline relies on the tiling prompt; seam elimination adds repair. Inspect the actual joins regardless: task success does not certify visual quality.
+
+## Tile texture seam elimination MCP
+
+Use `evomeme_eliminate_tile_seams` when the user already has a tile and wants to repair its repeating seams. Do not regenerate a base through `evomeme_generate_seamless_tile` for this request. A newly generated tile can be passed directly using its returned `asset_id`.
+
+| Parameter | Required | Meaning |
+| --- | --- | --- |
+| `id` | Yes | Workspace image ID of one existing square tile, e.g. `assets/terrain/grass.png`. Prepare files as described above. |
+| `model` | No | Default `asset-pro`. Pro/Max support 1024x1024 and 2048x2048; Lite requires 2048x2048. |
+| `prompt` | No | Texture continuity, material, color and style requirements. Shared prompts specify seam repair and locked regions. |
+| `workspace_dir` | No | Absolute workspace root; specify it explicitly. |
+
+```json
+{
+  "id": "assets/terrain/grass.png",
+  "model": "asset-pro",
+  "prompt": "Preserve the grass blade scale, dark green palette and hand-painted finish; make all repeating edges continuous",
+  "workspace_dir": "D:/my-game"
+}
+```
+
+The tool reads source dimensions and currently accepts only **1024x1024 or 2048x2048**. Do not pass `size`, `reference_ids`, `seam_elimination_enabled` or background options. Non-square images, other dimensions, and Lite with 1024x1024 are rejected. The tool does not stretch or enlarge the source to bypass these constraints.
+
+Pipeline: cyclic half-image offset → prepare and upload a central transparent-cross reference → one AI completion → composite only the repair region → restore the offset → save and upload the new PNG. Keep the original source; deliver one repaired PNG at the same resolution. Temporary references and raw model completion images are not deliverables. `local_path` and `asset_url` / `tos_url` identify the final composited image after offset restoration.
+
+Beyond common fields, results include `source_id` (the original tile ID), `model`, `size`, `width`, `height`, `job_id`, and `transform` with offsets, repair-strip width and `offset_restored=true`. `outputs` contains only the new PNG, not the source. Use the repaired `asset_id` for subsequent atlas generation.
+
+This repairs the **outer repeating edges of one tile**, not every internal cell boundary of a 4x4 atlas or the horizontal loop of a scrolling background. Use transition-atlas generation for a full two-terrain tileset. Standalone repair shares the same pipeline as optional repair during tile generation; do not repeat it after an already repaired tile passes visual inspection.
+
+## Transition-atlas MCP
+
+| Parameter | Required | Meaning |
+| --- | --- | --- |
+| `reference_ids` | Yes | Exactly two different workspace image IDs, in `[terrain0, terrain1]` order. |
+| `tile_size` | No | Integer cell side from 8 to 2048 pixels, default 128. Atlas width and height are each four times this value. |
+| `model` | No | Default `asset-pro`. Pro/Max support every tile size; Lite only supports 1025–2048 in the current pipeline. |
+| `prompt` | No | Boundary material, blending and style. Missing or blank text uses the internal default meaning “tile 1 gradually changes into tile 2.” |
+| `workspace_dir` | No | Absolute workspace root; specify it explicitly when calling. |
+
+```json
+{
+  "reference_ids": ["assets/terrain/grass.png", "assets/terrain/dirt.png"],
+  "tile_size": 128,
+  "model": "asset-pro",
+  "prompt": "Grass becomes sparse along the dirt boundary; preserve the same top-down view, lighting and hand-painted style",
+  "workspace_dir": "D:/my-game"
+}
+```
+
+The normal pipeline uses five AI generations: generate four directional mixed protocols concurrently → extract and reuse eight edge protocols → compose the fixed template locally → complete internal boundaries in a fifth generation → composite and save the PNG. Five generations do not mean five deliverables. Protocol and completion images are temporary and cleaned up on success or failure. The only final deliverable is one `assets/tile-transition-atlas-…png`. It is not automatically split or uploaded; use `evomeme_upload_game_asset` if a final remote URL is needed. Internal reference images are uploaded during generation.
+
+AI working resolutions differ from the output resolution. Protocol generation uses 1024x1024 when `tile_size ≤ 1024`, otherwise 2048x2048. Atlas completion uses 1024x1024 when the final atlas side is at most 1024, otherwise 2048x2048, then scales the generated pixels back to the target image. Lite cannot generate at 1024x1024, so this shared pipeline only permits Lite with `tile_size > 1024`, not the default 128. Normally retain default Pro; do not enlarge the user's requested tile size just to bypass a model constraint.
+
+The atlas has four rows and four columns with zero margin and spacing. Row-major indices, reading left to right and top to bottom, are:
+
+| | Column 1 | Column 2 | Column 3 | Column 4 |
+| --- | --- | --- | --- | --- |
+| Row 1 | 0 | 1 | 2 | 3 |
+| Row 2 | 4 | 5 | 6 | 7 |
+| Row 3 | 8 | 9 | 10 | 11 |
+| Row 4 | 12 | 13 | 14 | 15 |
+
+These are atlas indices, not engine autotile bitmask values. Read `tile_size × tile_size` regions and configure engine rules against their actual terrain edges. Do not assume the layout matches a particular engine's autotile convention.
+
+## Results, inspection and failures
+
+Successful text metadata includes `status: SUCCEEDED`, `task_id`, `operation_id`, final `asset_id`, `local_path`, `mime_type`, and an `outputs` array serialized as JSON text. `task_id` identifies the entire workflow, `operation_id` the local final-image step, and `job_id`, when present, a remote AI request. `outputs` lists saved deliverables with their names, types and applicable dimensions and URLs. MCP does not embed image bytes or Base64.
+
+Single-tile results also include `base` and `seam_elimination_enabled`. When enabled, `transform` contains `offset_x` / `offset_y` (cyclic offsets), `mask_width` (repair strip width), `feather` (blend feather width, currently 0), and `offset_restored` (whether the offset was reversed). Do not mistake `base` for the repaired final result.
+
+Atlas results include `tile_size`, `width`, `height`, `columns=4`, `rows=4`, and:
+
+| Field | Meaning |
+| --- | --- |
+| `working_tile_size` | AI working side for directional protocols, 1024 or 2048. |
+| `atlas_generation_size` | AI working side for atlas boundary completion, 1024 or 2048. |
+| `protocol_mask_width` | Total shared edge strip width at the target tile size, covering both sides of a seam. |
+| `generated_protocol_count=4` / `protocol_count=8` | AI mixed-protocol count / total including pure-terrain protocols. |
+| `ai_generation_count=5` | Normal generation stage count, not deliverable count or retry count. |
+| `boundary_completion=true` | Internal boundary completion ran; not a visual approval flag. |
+
+Inspect real files. Repeat a single tile at least 2x2 to check both axes and four-corner joins. Check an atlas's 4x4 layout, pixel dimensions, terrain order and joins between compatible edges. Atlas processing rejects transparent, partially transparent or pure magenta pixels left in repair regions, but cannot automatically identify every dark patch, texture mismatch or style issue.
+
+On `isError: true`, read the specific error and retain the inputs. If tile generation's second stage fails, the completed base remains saved; locate it through task records or the canvas, confirm the original task state, and use its ID with standalone seam elimination. Check existing task status after an interrupted query before resubmitting; another atlas call may repeat all five generations. Inspect repaired tiles visually: task success does not certify seamless appearance.

package/dist/skills/en-US/game-tile-generator/agents/openai.yaml

@@ -0,0 +1,7 @@
+interface:
+  display_name: "Tilemap Resource Generation and Editing"
+  short_description: "Create and optimize tiles, transition atlases and seamless joins"
+  default_prompt: "Use $game-tile-generator to create, edit or optimize tilemap resources with seamless tiles, transition atlases or seam repair on existing tiles."
+
+policy:
+  allow_implicit_invocation: true

package/dist/skills/en-US/game-ui/SKILL.md

@@ -0,0 +1,177 @@
+---
+name: game-ui
+description: Design restrained, clear, and genre-aware HUDs, menus, dialogs, touch regions, safe areas, and UI motion for games, and directly call the image-generation tools in the current environment to deliver UI concept art for different interfaces and their design rationale. Use when a game needs to determine or adjust UI style, information hierarchy, interface layout, interaction feedback, mobile adaptation, or UI concept art for states such as start, gameplay, pause, settings, win/loss, results, and selection. For evomeme platform games, MUST also read and follow evomeme-ui.
+---
+
+# Game UI Design
+
+## Goal
+
+Complete UI design based on gameplay, art direction, and target devices, and generate concept art for different interfaces that can express the final game's effect. Concept art should simultaneously reflect information hierarchy, operational intent, screen composition, and a unified visual language.
+
+## evomeme Platform Prerequisite
+
+If the game is intended to run, launch, or be published on evomeme, MUST read and follow [`evomeme-ui`](../evomeme-ui/SKILL.md) before UI design, concept-art generation, or responsive implementation. Use the WebView container already allocated by the host as the frame. Do not design around the phone's full screen or a fixed aspect ratio, and do not subtract App bars or phone safe areas again.
+
+For evomeme games, `evomeme-ui` governs dimension sources, safe-area handling, and responsive acceptance checks. Mobile safe-area advice in this skill and its general checklists MUST NOT cause duplicate deductions. For other platforms, follow their actual host constraints.
+
+## Core Design Principles
+
+1. **Less is more**: Make every UI element serve the player's current judgment, action, or understanding of feedback.
+2. **Keep necessary information**: Prioritize survival state, current objective, progress, and immediate feedback before arranging secondary information.
+3. **Game screen first**: Preserve a clear playable area for the player, threats, objectives, pickups, and key performance moments.
+4. **Game interface, not generic panels**: Use meters, icons, reticles, resource slots, status bars, cooldown rings, and in-world markers to express game information.
+5. **Unified visual language**: Let typography, icons, shapes, materials, colors, and motion continue the game's subject matter and art style.
+6. **Full-viewport game stage**: Let the game stage itself adapt to the viewport according to the target aspect ratio; extra desktop space serves as passive background while keeping the game area complete.
+
+## UI Design Workflow
+
+### 1. Establish Design Context
+
+Read the game design document, gameplay notes, existing interfaces, runtime screenshots, concept art, art settings, and references provided by the developer. Confirm:
+
+- The core gameplay and the decisions the player needs to make in each state;
+- Target devices, landscape/portrait orientation, aspect ratio, and safe areas;
+- Whether the game will run or be published on evomeme; if so, MUST first complete the `evomeme-ui` prerequisite reading above and use its game container test sizes;
+- Keyboard, mouse, touch, or native input methods;
+- Game art style, subject matter, atmosphere, and existing visual assets;
+- The game states that need design and the main action in each state.
+
+### 2. Determine UI Style
+
+Determine the UI style based on game art, genre, core gameplay, and user requirements. Clarify the following visual language and hand it to the developer for confirmation:
+
+- Primary colors, status colors, and neutral colors;
+- Typography direction and information font-size hierarchy;
+- Shapes of buttons, panels, status bars, and dialogs;
+- Icon silhouettes, materials, strokes, shadows, and decoration density;
+- Feedback methods for clicks, value changes, rewards, and danger states.
+
+When the direction has not yet been determined, propose a small number of clearly different candidate styles and explain each style's relationship to the game subject matter and gameplay.
+
+### 3. Determine The Interfaces To Design
+
+Identify the interfaces that need concept art according to the complete game flow, for example:
+
+- Start and main menu;
+- Core gameplay HUD;
+- Pause, resume, and settings;
+- Failure, retry, victory, and results;
+- Character, level, equipment, or ability selection;
+- Loading, asset error, and other necessary states;
+- Mobile touch operation layer.
+
+States with the same layout can share one design; states with obvious changes in layout, information hierarchy, or main action generate separate concept art.
+
+### 4. Design UI Layout
+
+First list the UI elements in the interface, then organize them by HUD, menus and dialogs, and operation UI. Determine the position, size, hierarchy, and appearance state of each element according to the player's goal.
+
+#### HUD
+
+- Concentrate HUD at the top of the screen, the upper sides, or near relevant world objects;
+- Keep persistent HUD height within 8% of screen height as much as possible;
+- Persistent HUD prioritizes showing no more than 3 key values that affect the current decision;
+- Use stable-width containers for dynamic values such as score, time, health, and ammo;
+- Use status bars for continuous values that must be read quickly;
+- Use fixed colors for danger, reward, shield, buff, objective, and disabled states;
+- Place brief warnings, combo, and event feedback where players can notice them easily without blocking action.
+
+#### Menus And Dialogs
+
+- Make start, resume, retry, next level, or confirm the primary action of the current interface;
+- Put settings, exit, restart, and level selection in a secondary hierarchy;
+- Use centered panels, bottom drawers, or top notices to express different importance levels;
+- Keep a clear front/back relationship between overlays and the game scene;
+- Give dialogs a clear trigger source, contained content, and return path.
+
+#### Operation UI
+
+- Choose click, swipe, drag, joystick, or action buttons according to the core gameplay;
+- Place movement controls in the lower-left thumb area and primary actions in the lower-right thumb area;
+- Make primary touch regions usually at least 44 CSS px, and leave spacing between adjacent actions;
+- Keep HUD, operation controls, safe areas, and the core gameplay path clearly separated;
+- Use pressed states, direction feedback, and cooldown presentation to communicate whether an operation took effect.
+
+### 5. Simplify UI Elements
+
+Confirm one by one the player need corresponding to each UI element. Put data that is meaningful only during results or reward stages into the corresponding interface; use icons, interaction affordances, and immediate feedback to express intuitive actions; keep teaching and explanation focused on what the player currently needs to understand.
+
+When the game can complete the core experience through direct interaction inside the scene, the gameplay screen can use no persistent UI, with corresponding states designed for pause, results, and necessary feedback.
+
+### 6. Design UI Motion
+
+Make motion respond to clear player actions or game state changes:
+
+- Button click: scale to 90-95% and then spring back, about 160-220ms, using easing with rebound feel;
+- HUD value changes: use number bounce, status-bar change, or color feedback of about 120-200ms;
+- Results and rewards: give the final result or main action a one-time emphasis;
+- Menus and dialogs: use brief fade-in, movement, or scaling to establish hierarchy;
+- Danger and high-intensity feedback: combine shape, color, motion, sound, or text to communicate state.
+
+In static concept art, express motion intent through initial position, movement direction, afterimages, lighting effects, or state contrast.
+
+### 7. Adapt For 2D And 3D Games
+
+- For 2D games, make the UI and Canvas game screen form a clear hierarchy, and make pixel density, strokes, and icon style consistent with the scene;
+- For 3D games, keep flat HUDs, menus, and overlays clear. When characters, vehicles, weapons, or trophies need to be shown, a 3D preview can be used as the interface focus;
+- In-scene labels, objective markers, and interaction prompts coordinate with camera composition, depth of field, and world space.
+
+### 8. Text Interaction Technical Requirements
+
+DOM text used for in-game display should not be selectable by the mouse cursor, and text selection or copy menus should not appear on mobile long-press. Implement this with `user-select: none`, `-webkit-user-select: none`, and `-webkit-touch-callout: none`; use `user-select: text` on inputs, textareas, and editable elements to preserve normal text selection capability.
+
+### 9. Generate UI Concept Art
+
+Before generating UI concept art or any other image, first tell the user the images, quantity, and visual direction proposed for this round, and obtain the user's explicit consent before calling the image-generation tool. Reconfirm when the generation scope changes.
+
+Directly call the image-generation tools available in the current environment to generate concept art for each selected interface and show it to the developer. When generating:
+
+- Use the real aspect ratio and game perspective of the target device;
+- Let the image directly present the combined effect of game scene and UI;
+- Reuse existing screenshots, concept art, art settings, and confirmed interfaces as visual references;
+- Show the relationships among HUD anchors, menu hierarchy, button positions, touch regions, and safe areas;
+- Keep typography direction, icon language, component shape, and color roles unified across different interfaces;
+- Use text and values close to actual content length to establish credible layout relationships.
+
+Adjust concept art based on developer feedback, and use confirmed images as visual references for later interfaces.
+
+After each round of UI concept art is generated and shown, the current flow must stop immediately and wait for user feedback. Later adjustments, the next round of images, or concept art for other interfaces all start only after receiving explicit feedback or confirmation from the user.
+
+### 10. Check Concept Art
+
+Check each concept image for game feel, HUD readability, information hierarchy, screen occlusion, text fit, safe areas, and touch regions. Confirm that stable space remains after dynamic values change, and ensure the same visual rules run through all interfaces.
+
+## Common Quality Issues
+
+- HUD presents as a generic dashboard or statistics cards;
+- Too many panel layers, with decoration area exceeding effective information;
+- UI blocks the player, threats, objectives, pickups, or next action;
+- Dynamic values change width and push other elements;
+- Text, icons, or touch regions are too small in the target aspect ratio;
+- Different interfaces use conflicting colors, materials, and component shapes;
+- A portrait game shrinks the actual game stage into a phone shell or picture-in-picture form.
+
+## Output
+
+Directly deliver UI concept art for different interfaces. Label each image with the interface name, and explain that interface's design goal and design rationale.
+
+```markdown
+# Game UI Concept Art
+
+## <Interface Name>
+
+<Directly show the generated concept art>
+
+- **Design Goal**: <what the player needs to understand or complete in this interface>
+- **Design Rationale**: <information hierarchy, visual focus, composition, operation regions, and art expression method>
+```
+
+## Reference Routing
+
+- When designing or adapting UI for evomeme platform games, MUST first read and follow [`evomeme-ui`](../evomeme-ui/SKILL.md).
+- When designing HUDs, menus, overlays, touch controls, and responsive layouts, read [`references/ui-patterns.md`](references/ui-patterns.md).
+- When checking overall game feel and interface quality, read [`references/checklists/game-ui-quality.md`](references/checklists/game-ui-quality.md).
+- When checking HUD information hierarchy and dynamic readability, read [`references/checklists/hud-readability.md`](references/checklists/hud-readability.md).
+- When checking target aspect ratio, text boundaries, and layout stability, read [`references/checklists/responsive-ui-fit.md`](references/checklists/responsive-ui-fit.md).
+- When checking touch regions and safe areas, read [`references/checklists/mobile-input.md`](references/checklists/mobile-input.md).

package/dist/skills/en-US/game-ui/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Game UI"
+  short_description: "Design the information hierarchy, layout, and interaction of each game interface, and generate concept art after confirmation"
+  default_prompt: "Please use $game-ui to design the main interfaces for my game, first confirm the design plan with me, and stop to wait for my feedback after each round of interface concept art generation."

package/dist/skills/en-US/game-ui-generator/SKILL.md

@@ -0,0 +1,82 @@
+---
+name: game-ui-generator
+description: Generate reusable game UI image kits with evomeme_generate_ui_components, optionally remove background color and separate component PNGs. Use for button, panel, progress-bar, slider and slot skins, or configuring three-slice, nine-slice, tiling, filling and state changes on generated assets. Explains runtime assembly and component-specific generation prompts. Use game-ui for overall interface layouts and concept art.
+---
+
+# Game UI Asset Kit Generation and Use
+
+Use this skill to generate reusable game UI images. Decide how each image changes width, height, fill and state before generating its artwork. Use [Game UI Design](../game-ui/SKILL.md) for layouts, hierarchy and concept art. This skill supplies component art; an interface screenshot is not an interactive component.
+
+## What the Tool Actually Does
+
+`evomeme_generate_ui_components` calls the same existing `executeUiComponents` task function as the canvas and reuses existing image functions: one AI component-sheet generation → local color key unless native transparency was requested → optional separation of foreground subjects into PNGs. It retains the generated sheet, optional transparent sheet and separated images under workspace `assets/`. The MCP does not call other MCPs.
+
+Maintain three-slice, nine-slice and part-separation recommendations only in this skill and put relevant guidance into the user `prompt`. Do not modify image functions or built-in prompts for these recommendations. The tool retains its fixed 22-category list and has no `components` parameter; the user prompt does not replace that list. For exactly one button or a focused batch, use `evomeme_generate_game_image` through the [general image skill](../game-asset-image-generator/SKILL.md), still following this skill’s construction guidance. That general tool does not automatically color-key or split images.
+
+**Automatic object splitting is not three-slice or nine-slice configuration.** Object splitting separates buttons and frames from a sheet. Three/nine-slice configuration specifies resizable regions within one component image. The tool does not measure these margins or generate widget code, interaction logic, semantic filenames or engine themes.
+
+## Terms That Affect Asset Construction
+
+- **Skin / asset sheet**: A skin is artwork such as a button background or border; a sheet contains several skins and has no interaction logic. One requested entry can include multiple states or parts, so entry count does not equal file count.
+- **Three-slice**: Divide a horizontal asset into left cap, center and right cap. Preserve decorative ends and change only the center width, suitable for fixed-height buttons of varying length. Vertical controls can use top/center/bottom. Regions can be sampled from one image without saving three physical files.
+- **Nine-slice / nine-patch**: Four margins define nine regions, not equal thirds. Preserve corners, extend horizontal edges along X and vertical edges along Y, and resize the center in both directions. Useful for panels and multiline fields. [Phaser documentation](https://docs.phaser.io/phaser/concepts/gameobjects/nine-slice)
+- **Stretch / tile**: Stretch resizes a region and suits plain fills or smooth gradients. Tiling repeats a pattern while preserving its texture scale; repeat boundaries must join. Crop the final partial repeat or use the engine's whole-tile fitting mode. Preserve end-cap proportions. [Godot stretching modes](https://docs.godotengine.org/en/stable/classes/class_styleboxtexture.html)
+- **Slice margins / content padding**: Slice margins protect source borders from deformation. Content padding positions text and icons inside them. They may differ and must be measured from the actual output; numbers requested in a prompt are not verified slice metadata.
+- **Fill / mask**: Show only the portion of a fill texture corresponding to a value, such as 40% health. A mask restricts visibility. Do not compress the entire health-bar frame to represent a percentage. Render changing text, values, selection and cooldown effects separately.
+- **State variants**: Normal, hover, pressed, focus and disabled appearances should retain dimensions and alignment. Swap images, tint or animate according to state. Touch has no persistent hover; keyboard/controller focus is distinct from pressing. [Unity transitions](https://docs.unity3d.com/Packages/com.unity.ugui@2.0/manual/script-SelectableTransition.html)
+
+## Buttons: Fixed Ends, Adaptable Center
+
+Generate an intact button background with no slice guides, not three scattered pieces. After inspection, place two vertical cuts beyond the rounded ends and ornaments: `left cap | center | right cap`. Overlay text and icons as independent UI elements so they do not stretch with the background.
+
+For example, a measured 240×64 button needs 24-pixel caps on each side, leaving a 192-pixel source center. At 360×64, keep both caps 24 pixels wide and allocate 312 pixels to the center. Stretch into that region, or repeat the center or a verified smaller texture unit and clip the excess. Do not stretch the whole image or divide it into three equal widths.
+
+Minimum width must accommodate caps, text and content padding, with positive center width. Use nine-slice when height changes or text wraps. Fine ornamentation may not repeat seamlessly; a tiling prompt alone does not verify continuity.
+
+Read [Component Construction and Prompt Catalog](references/component-patterns.md) for each asset type. Read [Slicing and Engine Integration](references/runtime-integration.md) when implementing Phaser, Unity, Godot or DOM controls. These are common engine-supported techniques; choose according to shape and renderer.
+
+## MCP Parameters and Reference Preparation
+
+| Parameter | Meaning |
+| --- | --- |
+| `prompt` | Optional global theme, style, materials, palette, lighting and structural constraints. |
+| `model` | Default `asset-max`; also `asset-pro` or `asset-lite`. Native transparency in this workflow requires Max. |
+| `size` | Whole-sheet preset, default `1664x2496`, not each button's dimensions. Must fit the model; Lite does not support `1024x1024`. |
+| `reference_ids` | Workspace style-reference IDs, default `[]`; up to 10 for Pro, 14 for Max/Lite in this workflow. |
+| `transparent_background` | Default `false`: generate solid background then automatically color-key. `true` requests Max native transparency and skips color key. |
+| `background_color` | Default `#ff00ff`, accepts `#RGB` or `#RRGGBB`. Used for solid background/keying; avoid subject colors. Not used as the background with native transparency. |
+| `auto_split` | Default `true`: separate detected objects without equal-size padding. False returns the entire sheet without changing the fixed generation list. |
+| `workspace_dir` | Absolute workspace root; specify it explicitly. Omission uses the MCP working directory. |
+
+Copy attachments or external local references under the selected workspace's `assets/` without overwriting assets. Download an accessible URL first when necessary. Verify files before passing relative IDs such as `assets/ui/style.png`. Do not pass original absolute paths, URLs or Base64; reuse returned `asset_id` values.
+
+Color key uses fixed strength 80, Oklab perceptual color distance, whole-image processing and soft edges, with despill disabled. Despill reduces residual key-color tint at subject edges. Similar subject colors may be removed; consider Max native transparency for translucent glass, glows and shadows, and inspect actual alpha. This workflow has no independent color-key disable or strength parameter.
+
+```json
+{
+  "workspace_dir": "D:/my-game",
+  "model": "asset-max",
+  "size": "1664x2496",
+  "transparent_background": true,
+  "auto_split": true,
+  "prompt": "Hand-painted fantasy wooden game UI, consistent warm brown wood and fine gold borders, front orthographic view, wide gaps, no text, numbers or slice guides. Intact button backgrounds with matching state silhouettes and end caps, extensible centers without unique motifs; panel corners remain decorated and centers blank; separate progress-bar tracks, full-length fills and frames."
+}
+```
+
+Automatic splitting requires at least two independent subjects. Holes, detached ornaments or touching assets can cause incorrect splits or merges; image numbering does not establish component identity. For a detailed small batch, use the general image tool with explicit parts and a shared style reference. Do not promise an exact subset through the fixed UI kit tool.
+
+## Results and Handoff
+
+Success returns text metadata, not image bytes or Base64. `operation_id` identifies a step and the generation-stage `job_id` identifies the remote generation. The existing task service manages task records; do not promise a separate `task_id` result field.
+
+- `images`: Final files to use. With splitting, independent PNGs; otherwise one processed sheet. Top-level `asset_id` / `local_path` refer to its first entry, not a composition of all components.
+- `generated`: Original sheet; `color_key`: Sheet after keying when applicable. Use `color_key`, otherwise `generated`, for the sheet before splitting.
+- File entries contain `id` / `asset_id`, `local_path`, `mime_type` and applicable step/remote job IDs. Keyed and split files are PNG. Locally processed files do not inherit source cloud URLs and are not automatically uploaded; upload their final `local_path` when needed.
+- `auto_split`, `background_color`, `transparent_background` and `color_key_strength` describe configuration. One call performs one AI generation; local keying and cropping add no AI requests.
+- Existing results have no `sheet`, `outputs`, `split`, `component_count` or `ai_generation_count` fields. Use `images.length` for file count, not semantic category count. Crop boxes are stored in step records and are not three/nine-slice margins.
+
+Inspect and name each component, recording its image ID, purpose, state, source dimensions, slice margins, stretch/tile mode, content padding and alignment origin. Create engine configuration from those measured values when required; this tool does not produce it. Do not treat requested proportions or shadow boundaries as exact measured slice data.
+
+Check short, medium and long widths; also different heights for nine-slice, 0%/intermediate/100% for bars, and stable alignment during state swaps. Correct different crops or canvas sizes before sharing slice settings. Use integer scaling and appropriate filtering for pixel art. Preserve state alignment and border space during atlas packing, and inspect texture bleed. See the integration reference for details.
+
+Read specific errors on failure. A failed split retains completed generated/keyed sheets; locate them in task records or the canvas before continuing, instead of paying to regenerate existing art. Native transparency and resizable construction are generation constraints that still require visual inspection.

package/dist/skills/en-US/game-ui-generator/agents/openai.yaml

@@ -0,0 +1,7 @@
+interface:
+  display_name: "Game UI Asset Kit Generation and Use"
+  short_description: "Generate UI skins with slicing and runtime assembly guidance"
+  default_prompt: "Use $game-ui-generator to generate game UI images and explain their slicing, stretching or tiling, state changes and runtime assembly."
+
+policy:
+  allow_implicit_invocation: true

package/dist/skills/en-US/game-ui-generator/references/component-patterns.md

@@ -0,0 +1,65 @@
+# UI component construction and generation prompts
+
+This catalog explains what to generate and how to use it. The first 22 categories match the fixed list; detailed constructions are recommendations, not guarantees of every part. Put construction and style requirements in the user `prompt`, not in image functions or built-in prompts. There is no `components` parameter and the fixed list cannot be replaced. Use `evomeme_generate_game_image` for exact parts or additional categories, with prompts guided by this skill and subsequent processing as needed.
+
+Three-slice, nine-slice, fill and state transitions are engine capabilities. The component assemblies below are art and implementation recommendations based on those capabilities, not a mandatory industry specification. See [runtime integration](runtime-integration.md) for engine differences and official sources. These prompts are editable examples; inspect and measure the generated results.
+
+## Shared prompt template
+
+Example `prompt`:
+
+> Create reusable game UI skin assets in [art style], using [materials] and [primary and accent colors], with consistent lighting, outlines and corner radii, in a front orthographic view. Show every independent part completely, with wide gaps and no overlaps or connected parts. Keep button end-cap and panel-corner decorations intact; make middle sections and centers suitable for resizing. Specify the repetition direction for repeating textures. Keep state variants identical in outer silhouette, size, lighting and alignment. No text, numbers, watermarks, labels, cutting guides, explanatory arrows or interface screenshots; leave dynamic icons and values to runtime. Follow the requested background mode.
+
+“Completely” means an intact button or panel that will be sliced by the engine, not nine loose pieces drawn by AI. For assembled controls such as progress bars and sliders, explicitly request separate parts. Do not depend on precise atlas coordinates: this tool crops detected subjects, and file numbers or positions do not establish semantic identity.
+
+Do not request both a solid magenta and a transparent background in the same global prompt. Use `transparent_background` and `background_color` to choose the mode. If artwork resembles the key color, choose another background color or Max native transparency.
+
+## The default 22 component categories
+
+Each description can be included in the user `prompt`. The kit tool still appends its fixed list; the general image tool suits exact small batches. Requested dimensions and proportions are targets, not exact output guarantees.
+
+| Component | Independent parts and runtime use | Example generation description |
+| --- | --- | --- |
+| 1. Window panel | Nine-slice an intact background; preserve corners, extend edges along their axes, and place runtime content in the center. Overlay unique emblems separately. | One intact window panel background, compact corner decorations, consistent border thickness, a clean center suitable for resizing in both directions, no text or icons, no unique center motif or nine-slice guides. |
+| 2. Title bar | Use three-slice at a fixed height and dynamic title text. Keep emblems and collapse/close controls separate. | An intact horizontal title bar and a separate decorative emblem; fixed ends, an extensible center, blank title area, and an emblem disconnected from the bar. |
+| 3. Standard button | Three-slice for fixed height; nine-slice if height also changes. Swap normal/hover/pressed/disabled skins; keep text separate and the pressed silhouette stable. | Normal, hover, pressed and disabled states of the same intact horizontal button background; identical end-cap positions and silhouette, no unique middle decoration, a center suitable for horizontal stretching, state changes through brightness and inner shadows, no text. |
+| 4. Tab | Separate three-slice or nine-slice tab skins from the content panel; swap the selected skin without stretching labels. | Unselected and selected backgrounds for the same tab shape, identical dimensions and corners; selection changes edge emphasis and color only, blank extensible center, no attached full page. |
+| 5. Text input | Three-slice or nine-slice for a single line; nine-slice for multiple lines. Render caret, content, placeholder and selection highlight in code. | Normal, focused and disabled intact input backgrounds, consistent borders and inner shadows, blank resizable center, no text, caret or selection region. |
+| 6. Dropdown | Separate the resizable field, arrow icon, nine-slice popup background and row states; code opens the list and lays out labels. | A dropdown field background, separate down arrow, popup menu background, and normal/selected row skins, spaced apart; horizontally extensible field, nine-slice-ready menu, no menu text. |
+| 7. Radio button | Fixed-aspect outer ring and selection dot, or aligned full unselected/selected images. Enforce group exclusivity in code; do not stretch circles along one axis. | Unselected and selected circular radio controls with identical dimensions, ring shape and position; a clearly centered selection dot, separated assets, no labels. |
+| 8. Toggle | Three-slice track and fixed-size knob; move the knob and change track color at runtime. Whole-image swapping also works but does not provide knob motion. | Off and on toggle tracks plus one separate circular knob; intact horizontally extensible tracks, no knob drawn on the tracks, consistent lighting across all parts. |
+| 9. Horizontal slider | Separate track, optional full-length fill and knob. Three-slice the track, keep the knob fixed, and map values to usable travel so it stays within the ends. | A horizontal empty slider track, full-length fill strip and separate knob, three disconnected parts, intact track ends, uniform extensible middle, no numbers or labeled tick marks. |
+| 10. Vertical scrollbar | Separate top/middle/bottom track and variable-length thumb; thumb length represents the visible fraction and its position represents scroll progress. | An intact vertical scroll track and a separate vertical thumb, each with complete top/bottom caps and a vertically extensible middle, no fixed emblems, arrows or text, suitable for varying both lengths. |
+| 11. Health bar | Separate empty trough, full health fill and frame. Crop/mask only the fill; keep the frame stable. A second fill can show delayed damage. | A horizontal health bar's empty trough, complete full-health fill and frame with a transparent center, three independent parts; fill fits the trough, fixed frame-end decorations, no health numbers or partial depletion. |
+| 12. General progress bar | Separate background, full fill and frame; use horizontal/vertical crop or fill properties. Repeat units for segmented bars instead of elongating individual cells. | An empty horizontal loading trough, full-length fill and separate border, no percentages or text, smooth continuous fill, intact trough ends and a horizontally extensible middle. |
+| 13. Skill hotbar | Optional resizable background plus repeated individual slots, with count and layout controlled in code. Do not stretch a baked row of slots. | A horizontally extensible hotbar background and one separate empty skill-slot frame, fixed square slot proportions, no embedded slot grid, skill icons, shortcut keys or numbers on the background. |
+| 14. Skill icon slot | Separate frame, icon, selection overlay and lock icon; use runtime masks and text for cooldown. Do not bake a current cooldown angle into each icon. | Matching empty normal and selected skill-slot frames, a separate lock icon and a complete cooldown overlay for runtime clipping; transparent slot centers, disconnected parts, no skill artwork, countdown or fixed missing sector. |
+| 15. Item slot | Separate slot frame and item icon; display selection/lock overlays independently and render quantities as text. Preserve decorated square-frame proportions. | Normal and selected empty item-slot frames plus a separate locked overlay, identical dimensions and silhouettes, transparent centers, no items, quantities or rarity text. |
+| 16. Portrait frame | Layer portrait, clipping mask and decorative frame. Clip the portrait to the interior and preserve the frame's aspect ratio. | One intact circular portrait frame with a transparent center, clear inner/outer contours and space around the outside; no character, text, portrait content or detached fragments. |
+| 17. Currency/resource display | Three-slice or nine-slice background plus a fixed icon and dynamic number. Keep the icon out of the extensible middle. | One horizontally extensible resource-count background and one separate coin icon, blank middle, no numbers or text, icon and background placed apart. |
+| 18. Dialogue box | Nine-slice body with separate tail, portrait, name and text. Reposition the tail to point at the speaker; do not stretch it with the body. | An intact dialogue-bubble body and one separate short tail; nine-slice-ready body, matching tail material and border, disconnected parts, no character, speaker name or dialogue text. |
+| 19. Character nameplate | Three-slice background adapts to names; keep badges/faction icons independent and lay out names and titles as text. | An intact horizontal character-nameplate background and a separate faction badge, compact end caps, clean extensible center, blank name area, no badge attached to the middle. |
+| 20. Dialogue option button | Three-slice for one line, nine-slice for multiple lines; handle selected skin, text, ordinal and quest icon separately. | Normal, focused and disabled dialogue-option backgrounds, suitable for nine-slice and multiline text, blank interiors, matching corner shapes and silhouettes, no option text or ordinals. |
+| 21. Confirmation modal | Assemble reusable nine-slice panel, title, buttons and separate close icon in code; draw the screen dimmer separately. | An intact modal panel background, primary and secondary button backgrounds with matching outlines, and a separate close icon, all placed apart; no assembled modal screenshot, title, body text or screen dimmer. |
+| 22. Notification banner | Three-slice or nine-slice background plus a fixed type icon and dynamic text. Size to content and animate entrance/exit in code. | A horizontally extensible notification-banner background and a separate notification icon, intact end decorations, blank middle, no text, attached icon or motion trail. |
+
+Sliders and scrollbars control the track and moving parts independently; scrollbar thumbs also resize to represent visible content. These constructions correspond to runtime parts in [Unity Slider](https://docs.unity3d.com/Packages/com.unity.ugui@2.0/manual/script-Slider.html) and [Scrollbar](https://docs.unity3d.com/Packages/com.unity.ugui@2.0/manual/script-Scrollbar.html).
+
+## Optional additional components (outside the default 22)
+
+| Component | Runtime use | Example generation description |
+| --- | --- | --- |
+| Checkbox | Fixed-size box plus checked/indeterminate marks, with independent toggle logic rather than radio-group behavior. | A fixed-size empty checkbox frame, separate checkmark and separate short dash, with consistent outlines and centered alignment, no labels. |
+| Tooltip | Nine-slice body plus separate tail; code changes direction, position and text layout near screen edges. | A compact tooltip background and four separate short tails pointing up, down, left and right; nine-slice-ready body, matching materials, no text. |
+| Circular progress/cooldown | Separate complete base ring, complete fill ring and center icon; control a sector mask in code rather than generating fixed 25%/50% screenshots. | An empty progress base ring and a complete continuous fill ring, matching dimensions, center and thickness, transparent centers, no missing sectors, percentages or numbers. |
+| Divider/decorative ribbon | Fixed ends with a stretched middle or repeated motif; the same construction works vertically. | An intact horizontal decorative divider, fixed left/right caps, a middle pattern suitable for seamless horizontal repetition, consistent texture scale, no text or center emblem. |
+| List row/tree node | Nine-slice row backgrounds plus independent disclosure/status icons; code controls indentation and text. | Normal, hover and selected list-row backgrounds plus a separate disclosure arrow, matching dimensions, nine-slice-ready blank centers, no data text. |
+
+Generate complete fill images for both rings and straight bars, then select the visible range at runtime. For example, [Godot TextureProgressBar](https://docs.godotengine.org/en/stable/classes/class_textureprogressbar.html) provides background, progress and overlay textures with multiple fill directions.
+
+## Batching and handoff
+
+1. Use the UI kit tool for the base collection; use the general image tool for an exact family such as four button states or three health-bar parts, following this skill’s prompts. The kit tool’s `auto_split=false` only disables splitting.
+2. Put shared style and part requirements in `prompt`. Reference an approved sheet in later batches for consistency. The fixed list is a starting point, not a guarantee of an entire project’s complete UI system in one request.
+3. Inspect connected parts, splitting and state dimensions. Normalize state canvases and alignment before measuring slice margins; retain originals for recropping.
+4. Deliver the images together with measured usage instructions: component identity, part relationships, slice margins, resize axes, repetition mode, state mappings, fill direction and content padding. Never treat example numbers as measurements of generated images.

package/dist/skills/en-US/game-ui-generator/references/runtime-integration.md

@@ -0,0 +1,45 @@
+# Slicing and engine integration
+
+This page explains how to use generated images. Measure configuration after inspecting the actual images; generation does not produce it automatically. Keep construction guidance and prompts in the skill without changing image functions. MCP and canvas continue calling the same existing task function.
+
+## Determine slices from the source
+
+Separate components first, then measure each component's left, right, top and bottom margins. Sheet spacing is not border thickness. Do not divide into equal thirds or nine equal cells. Margins must fully contain corners, caps, outlines and decorations that need to retain their shape.
+
+| Region | Runtime behavior |
+| --- | --- |
+| Horizontal three-slice ends | Preserve dimensions; use consistent overall scaling when changing the entire control's visual scale. |
+| Horizontal three-slice middle | Stretch to target width minus both caps, or repeat texture within that region and clip the remainder. |
+| Nine-slice corners | Preserve shape and dimensions. |
+| Nine-slice top/bottom and left/right edges | Extend horizontally and vertically respectively. |
+| Nine-slice center | Adapt to target width and height, or omit the center when only a frame is needed. |
+
+For a measured 240×64 button with 24-pixel side margins at target width 360, the middle is `360−24−24=312` wide. These numbers are examples, not measurements of generated art. Minimum dimensions must also fit text and content padding; content padding controls layout separately from slice margins.
+
+Stretch smooth backgrounds; tile only patterns whose continuity has been checked. Unique symbols or substantial lighting changes usually do not repeat well. Use nine-slice when height changes instead of vertically stretching a fixed-height three-slice button.
+
+## Engine mappings
+
+| Environment | Common integration and limitations |
+| --- | --- |
+| Phaser | `NineSlice` supports three-slice and nine-slice; horizontal three-slice uses left/right margins with zero top/bottom margins. Resize through `setSize`. Stretch support does not imply arbitrary center tiling; use fixed caps and a clipped `TileSprite` when repetition is needed, and check renderer support.[Official guide](https://docs.phaser.io/phaser/concepts/gameobjects/nine-slice) |
+| Unity uGUI | Configure Sprite borders; use `Image.Type.Sliced` for stretching or `Tiled` for repetition, resizing through RectTransform. Use a separate `Image` with `Filled`, or a mask, for progress. One Image cannot simultaneously have both Sliced and Filled types.[Image types](https://docs.unity3d.com/Packages/com.unity.ugui@2.0/api/UnityEngine.UI.Image.Type.html) |
+| Godot | Use `StyleBoxTexture` in control themes or `NinePatchRect` for direct sliced display. Texture margins specify slices; content margins govern child layout. Choose stretching, tiling or tile-fit as needed.[StyleBoxTexture](https://docs.godotengine.org/en/stable/classes/class_styleboxtexture.html), [NinePatchRect](https://docs.godotengine.org/en/stable/classes/class_ninepatchrect.html) |
+| HTML/CSS | `border-image-slice` divides the source and `border-image-width` sets displayed borders; add `fill` to draw the center. `border-image-repeat` provides `stretch`, `repeat` and `round`; `space` leaves gaps and is unsuitable for continuous borders.[Slicing](https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Properties/border-image-slice), [repetition](https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Properties/border-image-repeat) |
+
+These mappings are supported by official documentation. Confirm API and renderer capabilities against the project's version; engines do not share identical configuration.
+
+## Drive assembled controls
+
+- **Progress/health**: Keep trough and frame dimensions stable; update only the visible fraction of a full-length fill image. Clamp the fraction to 0–1 and render text separately. Use a sector mask over a complete source ring for radial cooldown.[Godot TextureProgressBar](https://docs.godotengine.org/en/stable/classes/class_textureprogressbar.html)
+- **Slider**: Adapt track length to layout while preserving knob size. Subtract end padding and knob occupancy from usable travel, then map values to positions within it.[Unity Slider](https://docs.unity3d.com/Packages/com.unity.ugui@2.0/manual/script-Slider.html)
+- **Scrollbar**: Size the thumb according to visible content divided by total content, with an operable minimum length; move it within the remaining travel.[Unity Scrollbar](https://docs.unity3d.com/Packages/com.unity.ugui@2.0/manual/script-Scrollbar.html)
+- **Button states**: Swap equally sized, aligned skins or use tint/animation. Handle keyboard focus, disabled and pressed states separately. Define hit areas in controls; transparent artwork does not create them automatically.[Unity transitions](https://docs.unity3d.com/Packages/com.unity.ugui@2.0/manual/script-SelectableTransition.html)
+
+## Handoff and inspection
+
+Record each image's path, role, state, source dimensions, slice margins, content padding, stretch/tile mode and alignment relative to other parts. A specification such as “240×64 button, left/right 24, top/bottom 0, horizontal three-slice stretch” must come from measurements, not prompts or examples.
+
+Automatic splitting does not pad to equal dimensions. Normalize state canvases and alignment before sharing slice settings. When packing atlases, preserve trimming offsets, margins and separation, and check neighboring texture bleed; slice settings cannot continue referring to pre-crop coordinates. Check integer scaling and filtering for pixel art before treating blurred scaling as an art defect.
+
+Inspect short, medium and long widths and multiple heights; bars at 0%, intermediate and 100%; state transitions for jumps; and text with long strings and different languages. Frames, portraits, icons, tails, knobs and numeric labels should each follow the catalog's resizing rules.