evomeme 0.1.9 → 0.1.10

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

@@ -0,0 +1,121 @@
+---
+name: game-art
+description: "Determine and produce game art in phases: in the first phase, confirm the overall style and deliver game prototype concept art and an element design set; in the second phase, deliver a brief asset requirements list based on the design document and design sheets; in the third phase, deliver a technical art requirements list for rendering, lighting, animation, materials, effects, performance presentation, and similar needs for a 2D or 3D game; in the fourth phase, call available tools item by item according to the developer's selections to generate game assets. Use when game art direction needs to be determined, concept art or design sheets need to be made, assets need to be inventoried, technical art requirements need to be planned, or final game assets need to be generated."
+---
+
+# Game Art
+
+## Goal
+
+Deliver game art outputs in phases: first determine the visual direction, then organize asset requirements and technical art requirements, and finally generate final assets according to the developer's selections.
+
+## Establish Context
+
+Read the game concept, game design document, existing art materials, and reference images provided by the developer. Understand the gameplay, worldview, target platform, aspect ratio, camera perspective, main interfaces, game elements, and the actual use of assets in the game.
+
+Use already confirmed information as the design basis, and confirm key choices that will affect the overall visual direction with the developer.
+
+## Image Generation Confirmation
+
+Before generating game prototype concept art, element design sheets, final assets, or any other images, first explain to the user the images to be generated in this round, the quantity, and the visual direction, and call the image generation tool only after obtaining the user's explicit consent. Reconfirm when the generation scope changes.
+
+After each round of game prototype concept art or element design sheets is generated and shown, the current process must stop immediately and wait for user feedback. Subsequent adjustments, the next round of images, and generation of the asset requirements list, technical art requirements list, or final assets all begin only after explicit user feedback or confirmation is received.
+
+### Parallel Generation Principles
+
+After obtaining the user's explicit consent for the generation scope in this round, use asynchronous MCP calls as much as possible to generate the same batch of mutually independent image assets in parallel; do not wait for one image to finish before starting the next one. First fix the asset ID, prompt, reference image, and output requirements for each call, then start the tasks simultaneously, and after results return, archive and display them by asset ID to shorten the waiting time for the whole batch of assets.
+
+Execute serially only when there is a real dependency, such as when a later item must reference the generation result of an earlier item, cutout must wait for the original image, or the next round must first obtain the user's feedback on the current result. Parallelization must not bypass the image generation confirmation requirements in this section, and must not confuse the correspondence between assets and returned results.
+
+## Phase 1: Art Style and Concept Design
+
+### 1. Determine the Overall Art Style
+
+Determine the game's overall visual direction together with the developer, including:
+
+- art style and subject matter;
+- color, lighting, and visual atmosphere;
+- shapes, linework, materials, and detail density;
+- proportion relationships between characters and environments;
+- camera perspective, perspective method, and composition;
+- a unified visual language across different interfaces and game elements.
+
+When the visual direction still has multiple possibilities, organize a small number of candidate directions with clear differences, explain each one's visual characteristics, and let the developer choose.
+
+### 2. Generate Game Prototype Concept Art
+
+Select game interfaces that can represent the main experience and visual changes, such as the start screen, core gameplay screen, key scenes, pause screen, or results screen. After obtaining the user's explicit consent, call the image generation tools available in the current environment to generate game prototype concept art for different interfaces and show it to the developer.
+
+Concept art presents an overall image close to the finished game, and is used to determine the relationships among composition, color, lighting, scene, characters, UI, and atmosphere. Adjust the concept art according to developer feedback until the overall art direction is confirmed.
+
+### 3. Generate Game Element Design Sheets
+
+Based on the design document and confirmed concept art, identify the characters, enemies, props, buildings, vehicles, mechanisms, environmental objects, and other game elements in the game. After obtaining the user's explicit consent, call the available image generation tools to generate three-view design sheets showing the front, side, and back of each element.
+
+Design sheets use a clear, unified presentation background and accurately show the element's silhouette, proportions, structure, colors, materials, and key details. Elements with different forms, equipment, or growth stages should show their corresponding variants separately.
+
+In subsequent design sheets, continue referencing the confirmed concept art and design sheets so different elements maintain the same art style. Use images confirmed by the developer as visual references when generating final assets.
+
+This phase delivers the confirmed game prototype concept art, game element design set, and overall art direction.
+
+## Phase 2: Asset Requirements List
+
+Before generating final assets, list all identifiable asset requirements based on the game design document, prototype concept art, and element design sheets. The asset list should cover the visual content actually used by the game, and expand concrete types according to gameplay, for example:
+
+- game background images;
+- independently movable multilayer parallax background images;
+- game maps;
+- tiles used by tile maps;
+- static game element images such as characters, objects, props, and environmental decorations;
+- sequence-frame animations for dynamic elements such as characters, enemies, and mechanisms;
+- effects, icons, and other visual assets needed by gameplay;
+- static 3D models;
+- dynamic 3D models with skeletons and animations.
+
+For dynamic elements, separately list idle, movement, attack, hit, death, or other motion states actually needed by gameplay. Each state is an independent asset item.
+
+The asset list keeps only the information needed to identify assets. Assign a stable ID to each asset, and write its type and name; add action state, direction, or variant only when needed to distinguish assets.
+
+```markdown
+# Game Asset List
+
+- [ ] ART001 [<type>] <asset name>
+- [ ] ART002 [<type>] <asset name> (<action state, direction, or variant>)
+```
+
+This phase delivers the asset list and has the developer confirm which assets need to be generated.
+
+## Phase 3: Technical Art Requirements List
+
+Based on the target engine, technology stack, runtime platform, visual target, and the already confirmed concept art and design sheets, organize the technical art requirements needed for a 2D or 3D game to achieve the target art effects.
+
+The requirements list is determined according to the game's actual presentation and may include:
+
+- sequence frames, skeletal animation, UI transitions, and feedback animations;
+- layers, masks, blend modes, cameras, and parallax presentation;
+- render pipeline, color space, resolution, pixel density, and anti-aliasing;
+- realtime lighting, baked lighting, shadows, ambient light, reflections, and fog effects;
+- material system, shaders, surface presentation, and special material effects;
+- tone mapping, bloom, depth of field, ambient occlusion, and other post-processing effects;
+- particles, trails, decals, and other realtime visual effects;
+- model polygon count, texture size, texture channels, compression, LOD, and lightmaps;
+- frame rate, video memory, batches, and visual quality tiers on the target platform.
+
+The technical art list keeps only ID, type, requirement name, and target effect. Key engine, platform, or performance constraints are added only when they affect the implementation method.
+
+Output the requirements list in the following format:
+
+```markdown
+# Technical Art Requirements List
+
+- TA001 [<animation / rendering / lighting / material / post-processing / effects / performance>] <requirement name>: <target effect>
+- TA002 [<type>] <requirement name>: <target effect> (<necessary constraints>)
+```
+
+Assign stable IDs to technical art requirements. This phase delivers the technical art requirements list and has the developer confirm it.
+
+## Phase 4: Generate Assets Item by Item
+
+According to the items selected by the developer from the asset list, after obtaining the user's explicit consent, call the generation or image editing tools suitable in the current environment to generate assets. For the same batch of mutually independent items, prefer asynchronous MCP parallel calls; items with reference image, cutout, or confirmation dependencies should be executed in dependency order. During generation, reference the confirmed concept art, element design sheets, and related technical art requirements, and determine aspect ratio, size, transparent background, perspective, layering method, and frame layout according to the asset's use in the game.
+
+After each asset is completed, directly show the generated result, mark the corresponding asset ID, and continue adjusting or generating the next item according to developer feedback. Completed assets are marked with `[x]` in the asset list.

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

@@ -0,0 +1,8 @@
+interface:
+  display_name: "Game Art"
+  short_description: "Determine the game art style in phases, organize asset and technical art requirements, and generate final assets"
+  default_prompt: "Please use $game-art to help me determine the overall art direction for the game, first confirm the image generation plan with me, and stop after each round of concept art or design sheet generation to wait for my feedback."
+
+policy:
+  allow_implicit_invocation: true
+

package/dist/skills/en-US/game-asset-align/SKILL.md

@@ -0,0 +1,45 @@
+---
+name: game-asset-align
+description: Maintain 3D canonical asset alignment among Three.js, Godot, and Blender. Whenever Tripo/generated model intake, orientation/scale/pivot repair, visual and semantic checks, cross-engine import inconsistencies, asset repair status, or ongoing acceptance are involved, this skill must be used first.
+---
+
+# Game Asset Align
+
+## Ownership
+
+This skill owns the scene export contract and the asset alignment and repair lifecycle. `godot-3d-game` and `threejs-3d-game` consume the package confirmed for the current target; Blender provides the modeling source scene, and the exporter is responsible for generating verifiable snapshots.
+
+Only Three.js, Godot 4, and Blender within the current plugin scope are supported. Do not add Unity or Unreal branches.
+
+## Required workflow
+
+1. Save a complete Blender scene as `.blend` first, then call `evomeme_scene_export_blender` to automatically generate a source snapshot, GLB, camera reference images, and scene contract; see [Blender scene modeling and export](references/blender-scene-pipeline.md) for the flow. Existing standalone GLB/GLTF files are ingested with `evomeme_asset_package_create`.
+2. **After Blender modeling or modification, the Stage board must be opened first, and the next engine-import step is allowed only after the user confirms the current version.** Call `evomeme_asset_review` to check format and dependencies, then call `evomeme_stage_open({workspace_dir, asset_id, target})`. `target` is `three_js` or `godot`. View Blender and the target engine's native image from the same camera position, and check space, structure, materials, and lighting.
+3. When geometry needs to be changed, call `evomeme_asset_repair_blender`. Repair invalidates old recipes, so the package must return to the board for acceptance again.
+4. Only after the user clicks **"Confirm current version, allow import"** in Stage may export/sync/handoff be called. Tool returns indicating that the board has launched, the model loaded successfully, the format check passed, or `alignment.ready=true` cannot replace confirmation. Do not click on the user's behalf, fabricate view/confirmation records, bypass the gate with `verified_by=spec/user_board`, or manually copy assets into the engine. While waiting for confirmation, work that does not depend on import may continue.
+5. Only one alignment root node is allowed in the engine; adding rotation, scale, or position compensation again in gameplay, animation, or entity scripts is prohibited.
+
+`asset.json` v1 can be read, but cannot enter the engine directly. After being saved again, it is upgraded to v2 repair status.
+
+Both export and sync forcibly check confirmation for the current Stage version; Godot sync also requires the corresponding confirmation from the Godot native preview, and a Three.js image cannot replace it. After modifying the model, contract, textures, Godot profile, materials, lighting, or display implementation, Stage must be reopened, viewed, and confirmed; old handoff packages retain their original version. For Godot configuration and preview flow, see [Godot basic visual alignment](../godot-3d-game/references/appearance-alignment.md).
+
+## Routing references
+
+- For current single-scene comparison and historical compatibility interface notes: read [lightweight-review.md](references/lightweight-review.md).
+- For image-reference modeling, complete Blender scene export, and procedural material baking: read [blender-scene-pipeline.md](references/blender-scene-pipeline.md).
+- When v2 fields, status derivation, or version invalidation need to be understood: read [alignment-contract.md](references/alignment-contract.md).
+- When deciding whether to change metadata, wrapper, or Blender geometry: read [repair-policy.md](references/repair-policy.md).
+- When judging "looks consistent" or saving acceptance evidence: read [visual-review.md](references/visual-review.md).
+- When comparing what Three.js, Godot, and Blender can do: read [engine-capabilities.md](references/engine-capabilities.md).
+- When creating, replacing, or migrating canonical packages: read [canonical-package.md](references/canonical-package.md).
+- When choosing MCP tools, parameters, or handling gate errors: read [tool-contract.md](references/tool-contract.md).
+
+## Completion gates
+
+- `asset.json` is `evomeme.canonical_asset.v2`.
+- The current target engine has been shown in Stage, and the user confirmation record is for the current revision; only actual confirmation by the original task user allows import to continue.
+- `alignment.overall_status` is `aligned`, and `alignment.ready` is `true`.
+- The recipe binds the current `model.glb` SHA-256 and current intent revision, and includes translation, quaternion, and scale.
+- The four items spatial, structural, semantic, and render are all `aligned` or explicitly justified `waived`.
+- The current single viewport must not describe a loaded display as the visual contract fully passed. If the task separately requires export, continue verifying source, intent, recipe, and the unique wrapper, without compensating Transform in gameplay code.
+- Visual conclusions come from target-engine screenshots or clearly labeled board approximations; do not pass off Blender/Three.js screenshots as Godot results.

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

@@ -0,0 +1,8 @@
+interface:
+  display_name: "Game Asset Align"
+  short_description: "Maintain auditable alignment state for generated models across Three.js, Godot, and Blender"
+  default_prompt: "Please use $game-asset-align to inspect this 3D asset package, repair cross-engine orientation, scale, and visual-semantic deviations, and provide a sustainably maintainable acceptance state."
+
+policy:
+  allow_implicit_invocation: true
+

package/dist/skills/en-US/game-asset-align/references/alignment-contract.md

@@ -0,0 +1,61 @@
+# Alignment contract v2
+
+## Source of truth
+
+`asset.json` keeps the v1 flat fields for UI compatibility, but `alignment` is authoritative for engine readiness.
+
+```json
+{
+  "schema": "evomeme.canonical_asset.v2",
+  "forward_axis": "+z",
+  "up_axis": "+y",
+  "pivot": "ground_center",
+  "scale_hint_metres": 1.8,
+  "alignment": {
+    "schema": "evomeme.asset_alignment.v1",
+    "source": { "model_file": "model.glb", "sha256": "…", "bytes": 123 },
+    "recipe": {
+      "source_revision": "…",
+      "intent_revision": "…",
+      "translation_metres": [0, 0, 0],
+      "rotation_quaternion_xyzw": [0, 1, 0, 0],
+      "scale_xyz": [1, 1, 1],
+      "algorithm_version": "evomeme.stage.v2"
+    },
+    "conditions": {
+      "spatial": { "status": "aligned" },
+      "structural": { "status": "aligned" },
+      "semantic": { "status": "aligned" },
+      "render": { "status": "aligned" }
+    },
+    "overall_status": "aligned",
+    "ready": true,
+    "revisions": {
+      "source": "…",
+      "intent": "…",
+      "recipe": "…",
+      "alignment_key": "…"
+    }
+  }
+}
+```
+
+## Four conditions
+
+- `spatial`: position, pivot, grounding, facing, up-axis and size are correct.
+- `structural`: hierarchy, mesh parts, skeleton, sockets and animation bindings remain usable.
+- `semantic`: the object identity and functional details match the request.
+- `render`: materials, visibility, normals, texture assignment and target-engine presentation are acceptable.
+
+Allowed states are `aligned`, `needs_review`, `misaligned`, `stale`, and `waived`. A required aspect is ready only when `aligned` or explicitly `waived` with evidence.
+
+## Revision invariant
+
+An accepted recipe must reference the current source SHA-256 and current intent revision. `alignment_key` binds source + intent + recipe. A model replacement, Blender geometry edit, or intent field change invalidates the prior key. Never copy an old key into a new package.
+
+`ready` and `overall_status` are derived values. Export/sync recomputes the invariant and compares the current model bytes; editing `ready: true` by hand cannot bypass the gate.
+
+## v1 migration
+
+v1 flat fields are parsed for inspection, then represented as `needs_review` with no accepted recipe. Open the Stage, inspect the actual model, and save to produce v2. Do not bulk-mark legacy assets ready without visual evidence.
+

package/dist/skills/en-US/game-asset-align/references/blender-scene-pipeline.md

@@ -0,0 +1,45 @@
+# Blender Source Scene -> Stage -> Engine
+
+## Starting from Images
+
+First read the image, and clarify the subject, proportions, materials, key light, and reference camera position. Model the back side and occluded areas not shown in a single image according to reasonable assumptions, and explain them on delivery. Prefer completing modeling through the currently available Blender MCP; this plugin provides export and acceptance flows, and does not bundle external Blender MCP installation or image-to-3D-model services. When there is no Blender MCP, if local Blender is available, Python modeling may be used; report a concrete blocker only when paths are missing or cannot be executed.
+
+First build the space and camera, output low-cost references for iteration, then refine the model, materials, and lighting. After saving `.blend`, perform the following export. The source scene uses metric units, unit scale=1, and preserves the scene origin; the exporter performs the Blender Z-up to glTF Y-up conversion. Do not rotate the whole world again. Cycles/Eevee and perspective cameras are supported; non-unit camera scale and lens shift will error and must be handled first. External linked libraries and sequences/caches that cannot be packaged should be localized in Blender before export.
+
+## Unified Export Entry
+
+```json
+{
+  "workspace_dir": "<absolute path to current workspace>",
+  "asset_id": "courtyard",
+  "source_blend_path": "<absolute path to the saved scene.blend>",
+  "camera_names": ["Reference", "MaterialDetail"],
+  "quality": "preview",
+  "width": 960,
+  "bake_materials": true,
+  "texture_size": 1024,
+  "godot_project_dir": "<absolute path to existing Godot project>"
+}
+```
+
+Pass the above parameters to `evomeme_scene_export_blender`. Camera names and the Godot project path may be omitted; when there is no camera, a reference camera position is created automatically and overview is completed. At most 6 specified perspective cameras are allowed. `width` is 320-1920; `texture_size` is 256/512/1024/2048. When no target project is specified, Godot defaults to Compatibility; `godot_renderer` may specify mobile/forward_plus/gl_compatibility; preview and sync projects must be consistent.
+
+The exporter reads the saved source file in an isolated Blender process, disables automatic script execution, saves a self-contained source snapshot, and generates the GLB, per-camera Blender native reference images, source feature manifest, and two target profiles. The original file is not modified; unsaved changes in active Blender will not enter the export. Failure does not replace the current package. Use replace_existing:true to update the same scene; the old package is kept in the returned backup_dir, and the new version must be confirmed again.
+
+preview uses fast sampling; final preserves the source scene sampling settings. Free-view native preview is still in fast mode and disables depth of field, and cannot be used to prove that the final offline render is fully identical.
+
+## Baking and Source Contract
+
+bake_materials:true is optional, and only processes supported procedural surfaces directly connected to Principled BSDF; it generates base color, roughness, metallic, and tangent normal maps by object, and creates UVs when necessary. The source `.blend` keeps the original nodes; the exported model uses the baked version. Complex closures, mixed shaders, volumes, and indirect light are not automatically converted by this baking path. Keep the skipped reasons in the report, and do not describe partial object baking as completion of the entire material set.
+
+`scene.contract.json.source_features` uses evomeme.source_scene_features.v1, recording node IDs, object/material associations, procedural nodes, unconverted nodes, baked channels/objects, volumes, world environment, and source render settings. IDs preferably reuse evomeme_node_id; when it is not set, they are derived from asset and object names. If stable IDs across renaming are needed, this property should be set in the source scene.
+
+Standard PBR and lighting facts share one source contract. `runtime/three.profile.json` and `runtime/godot.profile.json` store engine overrides; re-export preserves existing overrides that match the schema, while uncovered lighting is derived from the new source facts. After modifying a profile, update the byte counts and SHA-256 values in contract.files.
+
+Baked materials create an independent runtime material for each object; their exact names are recorded in source_features.materials[].runtime_materials. Use that material_name when setting engine material overrides. The unbaked version uses the actual material names inside the GLB.
+
+## Review and Delivery
+
+Call `evomeme_stage_open` to select three_js/godot. The board displays mapped, baked, approximated, not yet implemented, and pending-verification items one by one, provides related camera positions, and offers "record repair request." Repair requests are written into the feedback record and require the agent to read and continue modifying; the button does not complete the repair by itself.
+
+After the user views and confirms the current target-engine version, then call the corresponding sync. Three.js games use the generated loadReviewedScene and runtime.render, sharing the display implementation with Stage; Godot uses load_scene and the same native display adapter. After import is complete, re-verify in the actual project. visual_equivalence=not_evaluated in the confirmation record means cross-renderer pixel equivalence was not computed; it does not erase already recorded approximations or missing items.

package/dist/skills/en-US/game-asset-align/references/canonical-package.md

@@ -0,0 +1,26 @@
+# Canonical package
+
+## Required layout
+
+```text
+assets/canonical/<asset_id>/
+  model.glb
+  asset.json
+  preview/
+```
+
+`asset_id` is normalized and stable. `model_file` remains package-relative. Do not reference files outside the package.
+
+An optional `scene.contract.json` may define camera, world-coordinate and display-profile supplements. Its file manifest uses relative paths, byte sizes and SHA-256 hashes. Export/sync verifies the whole manifest and rejects traversal, missing files, stale hashes and coordinate conflicts.
+
+For a complete Blender source scene, `evomeme_scene_export_blender` creates this contract, `source/scene.blend`, per-camera references and both engine profiles automatically. See [Blender scene pipeline](blender-scene-pipeline.md). `source_features` makes unsupported/approximate effects visible in Stage; a loaded GLB alone does not demonstrate material or lighting equivalence.
+
+## World-coordinate scenes
+
+For a complete meter-scale map already exported as Y-up, use `up_axis=+y`, `forward_axis=-z`, `pivot=origin`, `scale_hint_metres=null` and zero offsets unless evidence says otherwise. Do not center a whole world or normalize it by height.
+
+## Replacement and history
+
+`replace_existing=true` may reuse the asset ID and descriptive metadata, but new model bytes create a new source revision. Previous recipes and evidence become stale. Keep repair reports/backups inside the package repair area; never treat a backup as the active `model.glb`.
+
+The bounded alignment history explains creation, migration, acceptance and invalidation. It is an audit aid, not a substitute for current revision checks.

package/dist/skills/en-US/game-asset-align/references/engine-capabilities.md

@@ -0,0 +1,14 @@
+# Engine capabilities
+
+| Component | Owns | Must not own |
+|---|---|---|
+| Stage | Three.js live preview, native Godot/Blender preview, bounds/TRS, explicit user confirmation before import | substituting Three.js frames for Godot, agent acceptance on behalf of the user |
+| Blender | topology, normals, origin baking, mesh cleanup, GLB re-export | final engine readiness, hidden per-engine orientation |
+| Godot 4 | GLB import, one runtime wrapper, gameplay integration, target render/physics QA | guessing authored axes, accumulating compensation transforms |
+| Three.js game | one runtime wrapper, web presentation and gameplay QA | a second canonical schema or per-entity hard rotations |
+
+Tripo and other generators are sources, not alignment authorities. Preserve their task/model/version metadata in provenance, but compute readiness from the emitted file and current user intent.
+
+Use GLB as the canonical mesh payload. Blender source files may be retained as provenance or repair artifacts, but engines consume the package, not an arbitrary `.blend` working file.
+
+Unity and Unreal are intentionally outside this plugin plan. Do not add placeholder adapters that appear supported but bypass validation.

package/dist/skills/en-US/game-asset-align/references/lightweight-review.md

@@ -0,0 +1,32 @@
+# Stage Board Confirmation and Engine Import
+
+After Blender modeling or modification, the Stage board must be opened to view the current version, and the user must click "Confirm current version, allow import" before the next import step can proceed. Merely launching the board, passing the format check, saving the technical alignment state, or ready=true cannot release the gate.
+
+## Sequence
+
+1. A complete Blender scene uses evomeme_scene_export_blender to generate a canonical package, source snapshot, contract, and native reference images; an existing GLB can be ingested separately.
+2. evomeme_asset_review checks the model format and file digests.
+3. evomeme_stage_open({workspace_dir, asset_id, target}) opens the single-scene viewport. `target` is three_js or godot.
+4. Compare Blender and target-engine native render from the same camera position and with the same aspect ratio, checking space, structure, materials, and lighting. Godot uses a temporary native preview project and does not write to the final game project in advance.
+   View the mapping, baking, approximation, and missing states under "effect conversion and pending-verification items"; related camera positions can be jumped to, or repair requests can be recorded. The states come from source features and adapter capabilities, not from image similarity scoring.
+5. The user confirms on the page. Tools and agents must not click on the user's behalf, and must not directly construct confirmation files.
+6. Call the corresponding sync tool. Three.js confirmation cannot replace Godot confirmation; export likewise requires the current Stage confirmation.
+
+When modification is needed, return to Blender or update the engine profile, then reload, view, and confirm again. The page keeps a single-scene scope and does not add asset lists, part editing, or gameplay.
+
+## Environment
+
+Blender is configured through EVOMEME_BLENDER / BLENDER_PATH; Godot is configured through EVOMEME_GODOT / GODOT_PATH or godot on PATH. While waiting for native preview, do not pass off an old image as the current view; if it fails, the current image cannot be confirmed.
+
+## Records and Invalidation
+
+.review/stage-view.json records the actual board camera position, target engine, and version. Godot views also bind the native render receipt and profile key.
+.review/confirmation.json records user confirmation, current resource/display implementation summary, complete TRS, camera position, screenshot summary, and technical report.
+
+Changes to the model, asset.json, scene contract, textures, Godot profile, material/lighting configuration, or display module make confirmation stale. export/sync checks the current confirmation and alignment recipe before writing to the target; setting verified_by or directly changing ready cannot bypass it.
+
+## Handoff and Scope
+
+Browser handoff only reproduces the confirmed Three.js image; Godot uses sync_to_godot to output the native loader and display adapter, and does not treat the Three.js handoff image as Godot acceptance.
+
+The Godot basic flow preserves GLB PBR, rebuilds lighting, environment, exposure, and camera, and supports material parameter calibration. Area lights use explicitly marked approximations; Three.js-specific baked shaders/LUTs will not be executed automatically in Godot. After the user confirms asset display, game integration and gameplay still require target-engine re-verification.

package/dist/skills/en-US/game-asset-align/references/repair-policy.md

@@ -0,0 +1,30 @@
+# Repair policy
+
+Choose the shallowest layer that fixes the actual defect while preserving one canonical result.
+
+## Metadata repair
+
+Use the Stage or `evomeme_asset_package_set_orientation` when geometry is sound but authored axes, pivot intent, scale target, semantic label, sockets, or review evidence are wrong. Save a complete wrapper TRS. Do not bake a rotation into gameplay code.
+
+## Wrapper repair
+
+Use the canonical recipe for non-destructive translation, quaternion rotation and scale. The wrapper must be applied exactly once. It is appropriate for grounding, recentering, authored-forward conversion and size normalization.
+
+If `pivot=origin` and `scale_hint_metres=null`, a deterministic identity translation/unit scale recipe is possible. Bounds-dependent pivots or height normalization require a measured recipe from the board or another adapter.
+
+## Blender geometry repair
+
+Use `evomeme_asset_repair_blender` for broken origins that must be baked, detached/duplicate parts, bad normals, unusable topology, destructive transform cleanup, or export defects. It backs up the prior model and writes into the same canonical package.
+
+Any Blender result changes the source revision and invalidates all prior review states. Reopen the Stage and accept a new recipe before export or sync.
+
+## Never repair here
+
+- player/controller yaw offsets;
+- AnimationTree or animation-track compensations;
+- per-scene scale overrides;
+- a second Godot/Three wrapper;
+- a material tweak claimed as canonical without updating review evidence.
+
+These hide drift and cannot be maintained when the asset is regenerated.
+

package/dist/skills/en-US/game-asset-align/references/tool-contract.md

@@ -0,0 +1,39 @@
+# MCP tool contract
+
+## Create and inspect
+
+- `evomeme_scene_export_blender`: saved Blender scene → source snapshot, GLB, cameras/reference PNGs, source-feature contract, Three.js/Godot profiles and derived diagnostics. Read [blender-scene-pipeline.md](blender-scene-pipeline.md) for parameters, baking and replacement behavior. This source export precedes Stage; it is distinct from confirmed package export to an engine.
+- `evomeme_asset_package_create`: copy GLB/GLTF into a canonical package. New packages are normally `needs_review`.
+- `evomeme_asset_package_list`: inspect `alignment_status` and `alignment_ready` before choosing work.
+- `evomeme_asset_package_get`: read full paths, flat compatibility fields and the v2 alignment record.
+- `evomeme_stage_open`: preferred path for bounds-dependent alignment and user visual acceptance.
+- Blender modeling/changes MUST stop at Stage before engine import. Open with `target=three_js` or `target=godot`; the user must view and click the current-version confirmation. An agent must not click on the user's behalf or fabricate a record.
+
+## Accept alignment
+
+`evomeme_asset_package_set_orientation` writes technical alignment only. It cannot replace Stage user confirmation or unlock import. It accepts flat intent fields plus optional:
+
+```json
+{
+  "alignment_recipe": {
+    "translation_metres": [0, 0, 0],
+    "rotation_quaternion_xyzw": [0, 0, 0, 1],
+    "scale_xyz": [1, 1, 1],
+    "algorithm_version": "adapter-name.v1"
+  },
+  "alignment_conditions": {
+    "spatial": { "status": "aligned", "evidence": "front/side board review" }
+  }
+}
+```
+
+For a bounds-dependent pivot or scale, omitting `alignment_recipe` leaves the package non-ready. Use the board instead of inventing translation/scale values.
+
+## Repair and delivery
+
+- `evomeme_asset_repair_blender`: changes the source and invalidates alignment.
+- `evomeme_asset_package_export`: validates source bytes, readiness and current Stage user confirmation.
+- `evomeme_asset_sync_to_three`: exports to `public/assets/canonical/<id>/` and generates `src/evomeme-stage/<id>/canonical_loader.js`; use loadReviewedScene with Three.js 0.170.0 and runtime.render to retain the reviewed appearance pipeline.
+- `evomeme_asset_sync_to_godot`: requires `project.godot` and current native Godot Stage confirmation; exports to `assets/canonical/<id>/`, generating the guarded model loader and shared material/light/environment/camera adapter. Use `load_scene` for a scene and `load_package` for props.
+
+On a gate error, do not retry with edited JSON. Read the reported pending/stale conditions, repair or review the package, then sync again.

package/dist/skills/en-US/game-asset-align/references/visual-review.md

@@ -0,0 +1,26 @@
+# Visual review
+
+## Review sequence
+
+1. Load the exact current `model.glb`; confirm the displayed source revision.
+2. Compare against the user request or versioned reference, not memory.
+3. Inspect front/back/side/top and a gameplay camera view.
+4. Check spatial, structural, semantic and render conditions separately.
+5. Save the measured wrapper TRS and concise evidence.
+6. Verify again in the target engine after sync.
+
+## Practical checks
+
+- Spatial: feet/wheels/base touch the expected plane; forward direction is unambiguous; height and world scale are plausible; maps retain their intended origin.
+- Structural: named parts exist, transforms are not unexpectedly nested, skeleton and sockets remain attached, animations do not jump on frame zero.
+- Semantic: silhouette, part count, handedness, openings, controls, weapon muzzle, seats, doors and other requested affordances are correct.
+- Render: normals face outward, textures resolve, alpha/culling are correct, material response is credible and no parts disappear under the target camera/light setup.
+
+## Evidence quality
+
+Prefer a user-approved board view or target-engine screenshot. Agent visual review is acceptable when the comparison and limitations are recorded. Heuristics alone do not close structural, semantic or render review.
+
+Three.js Stage is a neutral inspection surface, not proof of Godot render parity. Blender Cycles, Three.js and Godot use different shading pipelines. Describe approximations explicitly; do not promise pixel identity unless a target-engine capture was compared.
+
+For `scene.contract.json`, keep reference camera, aspect ratio, near/far and framing fixed during comparison. Do not let auto-frame controls overwrite a contract camera.
+

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

@@ -0,0 +1,104 @@
+---
+name: game-asset-image-generator
+description: Guide the Agent to correctly use the game asset generation and editing tools provided by MCP. For anything involving generation or editing of game concept art and game assets (including images, models, videos, etc.), this skill must be invoked first, and final outputs must be saved according to the standard into the assets/ directory of the current workspace.
+---
+
+# Game Asset Generation
+
+## Workspace Asset Rules
+
+The following rules must be followed:
+
+1. All AI-generated images and videos must be saved to the `assets/` folder at the root of the current workspace. Do not keep only remote URLs; even if the runtime does not directly read local files, the corresponding asset files must still exist in `assets/`.
+2. All assets used by evomeme platform games must have their TOS URLs written into the project configuration (usually `public/config.json`). Game code must read asset URLs through configuration entries, and must not import, read, or concatenate asset paths from `assets/`.
+
+When calling asset tools, always pass the absolute path of the current workspace root to `workspace_dir`, ensuring the tool saves returned files to the correct `assets/` folder.
+
+## Asset Tools
+
+Two asset tools are currently provided:
+
+- `evomeme_generate_game_image`: Generate an image from a text prompt.
+- `evomeme_cutout_game_image`: Create a transparent-background cutout from an existing image.
+
+Both tools submit asynchronous tasks and poll by themselves until the task succeeds or fails. On success, the tool downloads the final TOS image to `<workspace_dir>/assets/` and returns both text metadata and an MCP `image` multimodal content block.
+
+## Parallel Calls
+
+When generating multiple assets, start independent tasks in parallel through asynchronous MCP calls whenever possible; do not wait for one task to finish before calling the next one item by item. Before parallelizing, fix the prompt, parameters, and identifier for each asset; each call must explicitly pass the same correct `workspace_dir`, and after results return, record `job_id`, TOS URL, and local file separately according to the mapping between tasks and assets.
+
+Steps with output dependencies must remain sequential. For example, cutout must wait until the image to process has finished generating, and when a later image must reference an earlier result, a valid URL must be obtained first. Parallelism is only for tasks whose dependencies allow simultaneous execution; polling inside a single MCP tool should not block the start of other independent asset tasks.
+
+## `evomeme_generate_game_image`
+
+Generate a game image from a prompt.
+
+When generating a single static game element that does not need animation or dynamic effects, such as a small stone, standalone cloud, or fixed-pose enemy, use `image_type=asset`, and you must first read and follow the [Static Game Element Prompt Guide](references/static-game-assets.md). If a game concept image or a setting concept image for the current element exists, you must use the concept image as `reference_image_url` according to that guide. That guide does not apply to backgrounds, parallax layers, tilesets, animations, effects, videos, or models.
+
+When generating a complete single-layer background that fills the game screen, use `image_type=background`, and you must first read and follow the [Game Background Prompt Guide](references/background.md). If a game concept image or a setting concept image for the current scene exists, you must use the concept image as `reference_image_url` according to that guide.
+
+### Inputs
+
+| Parameter | Required | Type/Allowed values | Description |
+| --- | --- | --- | --- |
+| `prompt` | Yes | `string` | Image-generation prompt. |
+| `image_type` | No | `asset`, `background`, `parallax background`, `tileset` | Image type; defaults to `background`. `asset`, `parallax background`, and `tileset` are automatically cut out. |
+| `size` | No | `2048x2048`, `1728x2304`, `2304x1728`, `2560x1440`, `1440x2560`, `1664x2496`, `2496x1664`, `3024x1296` | Output size; defaults to `2048x2048`. |
+| `reference_image_url` | No | `string` | Accessible URL of the reference image. |
+| `image_model` | No | `asset-lite`, `asset-pro`, `asset-max` | Image-generation model; defaults to `asset-lite`. |
+| `workspace_dir` | No | `string` | Absolute path of the Agent's current workspace root. To satisfy the asset rules, it must be passed explicitly when calling. |
+
+### Outputs
+
+The successful result's `content` contains:
+
+1. `content[0]`: Text metadata, including:
+   - `job_id`: Asynchronous task ID.
+   - `tos_url`: TOS URL of the final image.
+   - `asset_url`: Same as `tos_url`, for compatibility with existing configuration logic.
+   - `status`: Final state, `SUCCEEDED` on success.
+   - `attempts`: Number of attempts already executed and maximum attempt count.
+   - `size`: Image size confirmed by the server.
+   - `image_type`: Image type confirmed by the server.
+   - `has_transparent_background`: Whether it has a transparent background.
+   - `local_path`: Local absolute path downloaded to the current workspace's `assets/`.
+   - `multimodal_base64`: Description of the content block containing Base64 and the character count.
+   - `mime_type`: Image MIME type.
+2. `content[1]`: MCP multimodal image content block:
+   - `type: "image"`
+   - `data`: Base64 image data without the Data URL prefix.
+   - `mimeType`: Image MIME type.
+
+The local filename uses the final segment of the final TOS URL path and cleans characters not allowed by the operating system. On failure, the result carries `isError: true`, and the text content is the failure or timeout message.
+
+## `evomeme_cutout_game_image`
+
+Process an existing image into a transparent-background image.
+
+### Inputs
+
+| Parameter | Required | Type | Description |
+| --- | --- | --- | --- |
+| `image_url` | Yes | `string` | Accessible URL of the source image to cut out. |
+| `workspace_dir` | No | `string` | Absolute path of the Agent's current workspace root. To satisfy the asset rules, it must be passed explicitly when calling. |
+
+### Outputs
+
+The successful result's `content` contains:
+
+1. `content[0]`: Text metadata, including:
+   - `job_id`: Asynchronous task ID.
+   - `tos_url`: TOS URL of the final cutout result.
+   - `asset_url`: Same as `tos_url`, for compatibility with existing configuration logic.
+   - `status`: Final state, `SUCCEEDED` on success.
+   - `attempts`: Number of attempts already executed and maximum attempt count.
+   - `has_transparent_background`: Transparent-background flag; a successful result is usually `true`.
+   - `local_path`: Local absolute path downloaded to the current workspace's `assets/`.
+   - `multimodal_base64`: Description of the content block containing Base64 and the character count.
+   - `mime_type`: Image MIME type.
+2. `content[1]`: MCP multimodal image content block:
+   - `type: "image"`
+   - `data`: Base64 image data without the Data URL prefix.
+   - `mimeType`: Image MIME type.
+
+The local filename uses the final segment of the final TOS URL path and cleans characters not allowed by the operating system. On failure, the result carries `isError: true`, and the text content is the failure or timeout message.

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

@@ -0,0 +1,7 @@
+interface:
+  display_name: "Game Asset Image Generator"
+  short_description: "Generate and process game image assets, save the results to the workspace, and connect them to the project configuration"
+  default_prompt: "Please use $game-asset-image-generator to generate or process the image assets needed for my game, and correctly connect the files and asset links to the project."
+
+policy:
+  allow_implicit_invocation: true

package/dist/skills/en-US/game-asset-image-generator/references/background.md

@@ -0,0 +1,32 @@
+# Game Background Prompt Guide
+
+A game background is a complete single-layer scene image that fills the game screen, such as a forest, city street, outer-space area, underground cave, or indoor space. Each background is generated only once and used as a separate `background` image.
+
+## Use Concept Art As Reference
+
+If a game concept image or a setting concept image for the current scene exists, the accessible URL of the concept image must be used as `reference_image_url`:
+
+- Prefer the setting concept image for the current scene; if none exists, then use the overall game concept image.
+- Clearly state in the prompt which characteristics need to be inherited, such as worldview, scene structure, color palette, materials, lighting, and art style.
+- Do not copy layout, text, annotations, character presentation, or other irrelevant content from the concept image.
+
+## Prompt
+
+When writing, follow these rules:
+
+- Clearly state the background's purpose in the game, scene location, era, or theme.
+- Clearly state landscape or portrait composition, camera perspective, horizon position, and main spatial direction.
+- Clearly state time, weather, lighting, main color palette, and main materials, and keep them consistent with existing game art specifications.
+- Specify areas that need to remain clear and low-interference according to the gameplay, such as the central movement area, road, platform area, or character activity area.
+- Place high detail and visual focus where they will not block gameplay information, and avoid uniform detail density across the whole image.
+- Keep spatial layering, perspective, light direction, and scale consistent so the background can directly fill the game screen.
+- Require `full-frame composition, edge-to-edge scene, no border`; do not generate a white background, transparent background, picture frame, or display mockup.
+- End with `no characters, no enemies, no pickups, no UI, no text, no watermark, no logo`.
+
+## Prohibited Wording
+
+- Drawing characters, enemies, props, pickups, attack effects, or interactive objects into the background.
+- Drawing HUD, buttons, title, score, tutorial text, Logo, or watermark into the background.
+- Describing only atmosphere without specifying the concrete scene, perspective, composition direction, and gameplay negative space.
+- Requesting standalone elements, transparent background, pure white background, asset collections, setting sheets, or multi-view images.
+- Using an art style, color palette, materials, and lighting that conflict with the game concept image or existing art specifications.