evomeme 0.1.9 → 0.1.10

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

@@ -0,0 +1,38 @@
+# Static Game Element Prompt Guide
+
+A static game element is a single game element that can be directly represented by one standalone image and does not need animation frames or dynamic effects, such as a small stone, standalone cloud, shrub, road sign, or an enemy that only uses a fixed pose. Each static element is generated only once and used as a separate `asset` image.
+
+This guide does not apply to:
+
+- Complete scene backgrounds, parallax background layers, or tilesets.
+- Characters or enemies that need animation frames such as walking, attacking, or taking hits.
+- Dynamic effects such as fire, explosions, or trails.
+- Game concept art, character setting art, UI, videos, or 3D models.
+
+## Use Concept Art As Reference
+
+If a game concept image or a setting concept image for the current element exists, the accessible URL of the concept image must be used as `reference_image_url`:
+
+- Prefer the setting concept image for the current element; if none exists, then use the overall game concept image.
+- Clearly state in the prompt which characteristics need to be inherited, such as element shape, silhouette, color palette, material, and art style.
+- Do not copy layout, text, annotations, multi-view presentation, or other irrelevant elements from the concept image.
+
+## Prompt
+
+When writing, follow these rules:
+
+- One image describes only one static element; collections, multiple variants, or multi-view images must not be requested.
+- Clearly state the element's role in the game, such as obstacle, fixed enemy, or environmental decoration.
+- For directional elements, the single facing direction must be specified; for non-directional elements, specify front view, side view, or top view.
+- For a fixed enemy, describe only one pose that can be used directly.
+- Keep only one to three key identifying features to ensure the silhouette remains clear after scaling down.
+- Require the subject to be centered, fully visible, surrounded by whitespace, and not cropped at the edges.
+- Use `pure white background, no ground, no cast shadow, clean edges` to support automatic cutout.
+- End with `no text, no watermark, no logo, no UI, no extra objects`.
+
+## Prohibited Wording
+
+- `background scene`, `parallax layer`, `tileset`.
+- `character sheet`, `multiple views`, `sprite sheet`, `animation frames`, `turnaround sheet`.
+- Multiple elements, multiple poses, multiple directions, or multiple skins appearing in one image at the same time.
+- Scene narrative, ground, sky, environmental lighting effects, or other content that would interfere with independent cutout.

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

@@ -0,0 +1,82 @@
+---
+name: game-audio
+description: Connect hosted BGM / SFX to Phaser / Three.js runtime configuration. Use when the game needs usable CDN audio URLs, configuration binding, or loader integration, and audio is not being generated locally.
+---
+
+# Game Audio
+
+## Overview
+
+Use this skill for game audio already hosted on a CDN or object storage. Compose loadable HTTPS URLs from object keys according to the conventions in the reference documents, and write them into `public/config.json` or the runtime loader.
+
+**Do not generate new audio**. If the required audio object does not exist in the CDN and the user has not provided a URL, stop and ask the user to confirm the object key or update the reference catalog; do not invent paths.
+
+## When To Use This Skill
+
+- A design document, configuration file, or the user specifies the filename/key of a BGM or SFX track and a loadable URL is needed
+- Filling audio fields such as `bgm_main`, `audio_bgm_gameplay`, `audio_sfx_click`, `backgroundMusic`, `src`, `url`
+- The user explicitly says the audio comes from the company CDN, object storage, or a fixed hosted URL
+- Integrating game feedback sound effects such as click, pickup, collision, shooting, explosion, success/failure sounds
+
+---
+
+## Reading Order
+
+1. After reading this section, choose and **open the corresponding reference document** according to the task type; do not compose URLs without reading the reference
+2. **BGM (looping background music)**: `references/bgm-cdn.md`
+3. **SFX (short triggered sound effects)**: `references/sfx-cdn.md`
+4. When both BGM and SFX are involved, read both references
+
+---
+
+## BGM Routing
+
+- Load the BGM reference document and extract the CDN root, path prefix, and track catalog from it
+- Used for looping background music, with configuration keys such as `bgm_main`, `audio_bgm_gameplay`, `audio_bgm_menu`, `backgroundMusic`
+- When a track is not in the catalog, do not invent a path; ask the user to confirm the object key before configuring it
+
+Recommended skill: `game-audio`; BGM reference `references/bgm-cdn.md`.
+
+## SFX Routing
+
+- Load `references/sfx-cdn.md` and extract the CDN root and filename rules
+- Used for short triggered sound effects, with configuration keys such as `audio_sfx_click`, `audio_sfx_pickup`, `audio_sfx_impact`, `audio_sfx_shoot`, `audio_sfx_explosion`, `audio_sfx_success`, `audio_sfx_fail`
+- High-frequency triggered sound effects (footsteps, dragging, continuous collisions) are handled through throttling or looping playback, not retriggered every frame
+
+Recommended skill: `game-audio`; SFX reference `references/sfx-cdn.md`.
+
+---
+
+## Workflow
+
+1. Confirm the task type: BGM, SFX, or both
+2. Read the corresponding reference document and extract the CDN root, required prefix, and filename rules
+3. Find the exact object key from the user, design document, configuration table, or reference catalog
+4. Compose the full HTTPS URL (use the CDN root and prefix from the reference; do not additionally encode the entire URL)
+5. Write the URL into the corresponding configuration key, manifest, or runtime loading code, preserving the project's existing audio architecture
+6. Verify control flags: BGM obeys `audio_music_enabled`, SFX obeys `audio_sfx_enabled`; in-game loops do not leak into the menu or results page
+
+### Writing 2D Project Configuration (`public/config.json`)
+
+```json
+"bgm_main":   { "value": "https://...", "type": "audio", "label": "Background Music" },
+"sfx_jump":   { "value": "https://...", "type": "audio", "label": "Jump Sound Effect" }
+```
+
+### Writing 3D Project Configuration
+
+Write according to the project's existing configuration structure; config key names follow the `audio_bgm_*` / `audio_sfx_*` naming convention.
+
+---
+
+## Guardrails
+
+- Do not invent filenames, CDN domains, directory prefixes, or percent-encoded fragments
+- Do not silently swap the root paths for BGM and SFX
+- Do not load a removed local audio generation skill on the grounds of generating audio
+- When the object key is missing or the user has not provided a full URL, stop and require the user to provide it or update the reference; do not guess
+
+## References
+
+- BGM CDN catalog: `references/bgm-cdn.md`
+- SFX CDN catalog: `references/sfx-cdn.md`

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

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Game Audio"
+  short_description: "Choose background music and sound effects from hosted resources, and integrate them into game configuration and playback flow"
+  default_prompt: "Please use $game-audio to choose suitable hosted background music and sound effects for my game, and integrate them into the existing configuration and playback flow."

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

@@ -0,0 +1,103 @@
+---
+name: game-demo
+description: After the game engine and tech stack are clear, read the game design document and prioritize code safety and first-delivery success while building the file structure, code framework, and core systems for the minimal runnable Demo. Code and image generation proceed in parallel; all game image assets must use generated images, and SVG, line drawing, or large solid-color assets are prohibited. Use when creating a game Demo from scratch, turning a design document into the first playable version, or establishing the foundational project for later development.
+---
+
+# Game Demo
+
+## Goal
+
+Read the design document, implement the core gameplay as the minimal game Demo that can start, be played, end, and restart, and establish a clear engineering foundation for later development.
+
+This skill independently completes project setup. Its main outputs are actual project files and a runnable Demo that can continue to be improved. All game image assets are obtained through image generation and connected through a unified asset configuration or loading layer; the first batch of generated assets may be gradually replaced with higher-quality versions in later development.
+
+## Before Starting
+
+First clarify the game engine and tech stack used by the current project.
+
+For an existing project, read the package manifest, lock files, build configuration, entry files, and main dependencies to confirm. For a new project, have the developer confirm the technical choices.
+
+Confirm at least:
+
+- Game engine and version;
+- Programming language;
+- Rendering and UI approach;
+- Build tool and package manager;
+- Target platform, aspect ratio, and input method.
+
+Then read `/project.md` at the project root or the design document file specified by the developer to understand the core gameplay, Demo scope, game objects, controls, win/loss conditions, and the complete flow of one game session.
+
+## First-Delivery Principles
+
+The Demo's first delivery must target successful startup and a complete core loop. Implement only the minimum objects, systems, states, and interfaces needed for the gameplay to work, making every added part directly serve the core experience.
+
+Code safety has the highest priority. Architectural completeness, extensibility, visual presentation, feature count, and technical complexity all defer to the stability of the first delivery. Use mature, direct, and easy-to-debug implementation paths in the current tech stack, keep dependencies lean, keep module responsibilities clear, make state transitions explicit, and provide safety boundaries for loading failures and runtime exceptions.
+
+## Demo Production
+
+Produce the Demo as a complete task. After development begins, prioritize starting generation for the required image assets, and build the file structure, code framework, and core game systems at the same time. When image-generation tools can be called asynchronously, submit generation tasks and then continue code work so both advance in parallel.
+
+### Hard Requirements For Image Assets
+
+- The Demo must not contain any SVG assets, including SVG files, inline SVG, and `data:image/svg+xml`.
+- Do not use Canvas/Phaser/CSS lines, geometric outlines, or procedural drawing to impersonate game image assets such as characters, scenes, props, icons, or effects.
+- Do not use large solid-color blocks or solid-color backgrounds as formal game assets or visual placeholders.
+- All needed game image assets, including backgrounds, characters, enemies, props, terrain, decorations, icons, and visual effects, must be obtained through image generation and actually connected into the Demo.
+- Code development and image generation may proceed in parallel, but the required generated images must be connected before the first visual delivery. If assets are not finished, continue generating them or reduce the Demo asset scope; do not replace them with SVG, line drawing, or large solid-color placeholders.
+- Generated assets are first-version assets that can be iterated on; they can be gradually replaced later while keeping the asset interface stable, and development does not need to wait for final art quality.
+
+The Demo runs through the following minimal complete flow:
+
+```text
+Start -> Load -> Begin -> Play -> Success or Failure -> Results -> Restart
+```
+
+After the code build is complete, the core loop can run, and the generated images required for this round have been connected, start a static service and open the Demo page in the environment's browser for the developer to operate and accept directly. The first presentation must not contain SVG, line drawing, or large solid-color game assets.
+
+## Demo Construction
+
+### File Structure
+
+Create directories for the project entry, source code, configuration, game systems, entities, scenes, input, assets, UI, build output, and so on according to the game engine and tech stack. Give each directory and key file a clear responsibility.
+
+### Code Framework
+
+Set up foundational code for game startup, configuration loading, asset loading, state transitions, input mapping, game loop, render synchronization, UI communication, restart, and resource cleanup.
+
+Separate gameplay state, rendering presentation, input, and UI into clear modules, and connect them through explicit data, events, or interfaces.
+
+### Game Systems
+
+Build the systems actually needed by the core loop according to the design document, such as player control, enemies or obstacles, spawning, collision, damage, scoring, progress, time, win/loss, results, and pause.
+
+Select only the systems necessary for the current core loop, connecting them through parameterized content and a unified asset interface. All image assets use generated images and may be gradually replaced later through the same interface.
+
+## Acceptance
+
+The Demo is accepted in the developer's browser. The Agent does not perform automated gameplay testing, end-to-end testing, visual regression testing, or other Agent-side automated tests. After code finishes building and can run, the Agent is responsible for immediately starting a static service, opening the browser, and handing control to the developer; remaining images continue to be generated and connected after the presentation.
+
+Before delivering to the developer, confirm:
+
+- The project uses the confirmed game engine and tech stack;
+- The first delivery remains minimal and can build and start successfully;
+- File responsibilities and module boundaries are clear;
+- The core game loop can run completely;
+- Input, game state, rendering, and UI are correctly connected;
+- Success, failure, results, and restart can be repeated;
+- A new session restores the correct initial state;
+- The Demo does not contain SVG, line drawing, or large solid-color game assets or visual placeholders;
+- All game image assets required by the current Demo have been obtained through image generation, centrally managed, and actually connected;
+- The static service has been started, and the Demo page has been opened in the browser.
+
+## Output
+
+Actual project files and a runnable build are the main deliverables. After completion, briefly describe:
+
+- The game engine and tech stack used;
+- The main directories and code modules established;
+- The game systems built;
+- The centralized configuration, connection location, and later replacement method for generated image assets;
+- The generation and connection status of image assets;
+- The core game loop that has been run through;
+- The build and static-service commands executed;
+- The developer acceptance URL in the browser.

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

@@ -0,0 +1,7 @@
+interface:
+  display_name: "Game Demo"
+  short_description: "Build a safe, minimal, runnable game demo, completing code and image assets in parallel"
+  default_prompt: "Please use $game-demo to build a runnable game demo from the design document, advance image generation and code construction in parallel, provide vector fallback images for all images, and open the webpage for my acceptance review as soon as the code can run."
+
+policy:
+  allow_implicit_invocation: true

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

@@ -0,0 +1,111 @@
+---
+name: game-maker
+description: Organize the development goals of a game or game Demo into a progressively refinable task dependency graph. At the beginning, create only a rough task skeleton composed of main goals, key decisions, the core Demo, and necessary dependencies, then gradually refine relevant branches as development decisions are made and other Skills deliver their results. Use when the developer wants to create, prototype, expand, or systematically rework a game from scratch, or needs to establish and continuously maintain a game development task list.
+---
+
+# Game Maker
+
+## Goal
+Organize the developer's game idea into a rough task dependency graph that can start development, and progressively fill in task details as the project advances. Plan the next step based on currently confirmed information, let the corresponding Skill take over the concrete work, and return its results to the task graph.
+
+The core output of this Skill is a continuously updated game development task list. The initial list expresses the main work and necessary dependencies; later lists expand according to actual decisions and delivered results.
+
+## Core Principles
+1. The developer decides the game direction and concrete details, including gameplay direction, art style, UI style, and key parameters.
+2. The initial plan expresses only main goals, milestones, key decisions, and necessary dependencies, keeping tasks that have not entered execution at a coarse granularity.
+3. Create tasks and dependencies only from already confirmed information so the plan can start executing immediately.
+4. Use stable and unique task IDs to identify each task node.
+5. Refine the corresponding branch when a task is about to be executed, dependencies have been satisfied, or new delivery results appear.
+6. When refining tasks, keep the original task ID as a milestone, add concrete work using new task IDs, and update the milestone's prerequisites.
+7. Keep the core Demo as an early task node; within the same task, advance image generation and code construction in parallel, provide SVG fallbacks for all images, and show it to the developer as soon as the code can run.
+8. Hand concrete design and implementation to the corresponding Skill, and update the design document, task status, and dependencies based on its delivered results.
+
+## Progressive Planning
+
+### Establish The Initial Task Skeleton
+
+Read the developer's game idea, existing design document, and current project state. Confirm a small amount of key information that affects the overall direction, then create a rough task list containing the main decisions, core Demo, later main work, and final acceptance.
+
+An initial task may represent a complete milestone. Task names should let the developer understand what needs to be completed, and tasks should connect only to direct dependencies that are already clear.
+
+### Refine The Current Branch
+
+When a task becomes the next piece of work, judge whether it needs to be split based on the outputs of its prerequisite tasks. Tasks that can be directly handed to the corresponding Skill remain unchanged; tasks that need multiple independent results are expanded using new task IDs.
+
+After expansion, keep the original task as a milestone and make it depend on the newly added concrete tasks. Other branches that have not entered execution remain coarse-grained.
+
+### Update The Plan Based On Results
+
+After the developer makes a decision or another Skill returns delivered results:
+
+1. Update the corresponding task status;
+2. Add new tasks made clear by the result;
+3. Update dependencies that are directly affected;
+4. Select the next task whose dependencies have already been satisfied;
+5. Continue refining the corresponding branch before entering that task.
+
+## Game Development Points
+
+### Clarify Developer Requirements
+First, the Agent should accurately understand the game the developer wants to create. This stage focuses on the game's overall direction and core gameplay; concrete details are unfolded gradually in later planning. When the developer's description is relatively vague, ask follow-up questions about key information that affects the overall direction.
+
+### Every Game Starts With A Demo
+Treat building the Demo as the first main stage of the game plan. Keep the Demo minimal, implementing only the complete flow, project structure, and system architecture required to validate the core gameplay. Code safety and first-delivery success have higher priority than feature count, visual completeness, and extensibility design.
+
+Usually only one of the Demo and game concept art is delivered; both are used to let the developer quickly see the game effect. After Demo development begins, the playable Demo carries the effect presentation, and the Demo plan does not include a game concept art drawing task; add a concept art task only when the developer explicitly needs to confirm the art direction separately.
+
+The task list uses one "Create a playable Demo" node to uniformly carry core-loop confirmation, minimum playable system, project structure, code construction, image generation, SVG fallbacks, asset integration, and browser acceptance.
+
+When executing the Demo task, prioritize starting generation for the required image assets, and complete project and code construction at the same time. Prepare a corresponding SVG fallback image for each image asset and connect it into the game through a unified asset interface. Replace them one by one after generated images return; images that have not finished yet continue using SVG and do not affect core gameplay operation.
+
+After the code build is complete and the core loop can run, immediately start a static service and open the game webpage for developer acceptance. Remaining images continue to be generated and integrated after the first presentation; image-generation progress does not delay delivery of the playable Demo. Demo acceptance is completed by the developer in the browser, and no Agent-side automated test task is arranged.
+
+### Continuously Maintain The Overall Game Design Document
+As the core game loop and core game systems gradually become clear, the Agent and developer continuously refine the complete play path. Use `/project.md` to record gameplay, the core loop, game systems, and their details in detail.
+
+Whenever gameplay is adjusted, update `/project.md` at the same time. All changes to gameplay direction should be discussed with the developer, and the developer makes the final decision.
+
+### Keep Code Modular, Functional, And Parameterized
+While building the Demo and later optimizing gameplay, split different game systems into independent code modules, and reuse common functions and logic for similar systems. Keep code paths valid, structure clear, and maintenance easy, improving the project's usability and robustness.
+
+To make it easy for the developer to fully take over later game development, parameterize all configuration and centralize variables in locations the developer can easily find and modify. When image assets are involved, establish a unified SVG fallback and asset-loading flow for each asset, and connect generated images within the same Demo production process.
+
+### Art And Game Code Can Advance In Parallel
+The developer can advance art and code work in two separate conversations. Art creation starts with concept art and an art setting collection, used to unify and control the game's overall art style.
+
+First, create concept art that represents the direction of the final game product based on information provided by the developer. Then create corresponding setting images for each type of element in the game systems, uniformly using pure white background three-view images.
+
+Continuously adjust concept art and the setting collection based on developer feedback. After the art direction is complete and confirmed, generate the in-game asset images needed according to the corresponding concept art and setting images.
+
+### Split Complex Tasks Into Four Types Of Subtasks
+Any complex task can be split into the following four types of subtasks, and each type can contain multiple concrete tasks:
+
+1. Generation task: The Agent is responsible for generating the images, code, models, and text needed by the game.
+2. Automation task: The Agent is responsible for automated processing of assets and text, such as cutout, formatting, and Photoshop operations.
+3. Decision task: The developer is responsible for judgments and choices about the game development direction.
+4. Detail adjustment task: The developer is responsible for determining concrete in-game parameters, including the spatial positions of game elements, game system parameters, and in-game colors.
+
+## Special Requirements For evomeme Platform Game Development
+When the target platform is evomeme, the initial plan may first establish a platform adaptation milestone. After entering that branch, split the following requirements into task nodes and establish dependencies:
+
+1. Create a mobile portrait, touch-first web game task.
+2. Create an evomeme cloud upload task for binary assets such as images, audio, videos, fonts, and models.
+3. Create a `public/config.json` resource configuration task, dependent on asset links returned by the cloud upload task.
+4. Create a production build task, using `npm run build` to output the final webpage to `dist/`, and dependent on game functionality and resource configuration tasks.
+5. Create a `dist/` build output inspection task, making it contain only the text build outputs needed for webpage runtime, and dependent on the production build task.
+6. Create a mobile portrait, touch interaction, and remote asset loading validation task, dependent on the production build task.
+
+## Output
+Output a flat task dependency list in Markdown. Keep the initial list rough and include only the main tasks currently needed; as work advances, add refined tasks in the same list. All task nodes are arranged directly under the title. Each task uses a stable and unique task ID and references prerequisites by task ID.
+
+```markdown
+# Game Development Task List
+
+- [ ] T001 [Decision Task - Developer] <task name>
+- [ ] T002 [Generation Task - Agent] <task name> (depends on: T001)
+- [ ] T003 [Automation Task - Agent] <task name> (depends on: T001)
+- [ ] T004 [Detail Adjustment Task - Developer] <task name> (depends on: T002, T003)
+- [x] T005 [Generation Task - Agent] <completed task name>
+```
+
+Task types use "Generation Task, Automation Task, Decision Task, Detail Adjustment Task". Use `[ ]` for incomplete and `[x]` for complete. Task IDs increase in creation order and remain stable. Initial tasks may represent larger milestones; when refining, keep the original number and assign new numbers to new tasks. When direct dependencies exist, reference the corresponding task IDs at the end of the task, and keep the task relationship as a directed acyclic graph.

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

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Game Maker"
+  short_description: "Organize a game idea into development tasks and dependencies that can be progressively refined and continuously maintained"
+  default_prompt: "Please use $game-maker to create a rough development task list from my game idea, and progressively supplement and update it as development proceeds."

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

@@ -0,0 +1,58 @@
+---
+name: game-test
+description: After game development ends, perform smoke testing and gameplay QA for a 2D or 3D browser game, verifying that the game can start, display, and complete the core gameplay loop, while also checking main input, state transitions, failure/retry, and desktop and mobile behavior. Use when a just-completed game or Demo needs final self-checking, basic playability confirmation, or gameplay issue recording.
+---
+
+# Game Test
+
+## Goal
+
+After game development ends, perform one smoke test and gameplay QA pass to confirm from the player's perspective that the game can enter, be controlled, progress, end, and restart normally, and record issues that block the basic experience.
+
+## Smoke Testing And Gameplay QA
+
+Before testing, read the project's startup method, target devices, input methods, core gameplay loop, and win/loss conditions. Load [`references/checklists/playtest-qa.md`](references/checklists/playtest-qa.md) as the testing reference.
+
+### Workflow
+
+1. Install dependencies as needed by the project and run the existing build or type-check command.
+2. Start the development server or preview server and open the correct game page.
+3. Capture browser console, page, and network errors.
+4. Confirm the game screen displays normally, and the Canvas has a valid size and visible content.
+5. Starting from a clean load, actually play the core loop for at least 2 minutes.
+6. Test movement, aiming, jumping, attacking, dragging, or the primary inputs corresponding to the gameplay.
+7. Verify objective progress, scoring, collection, collisions, and other core state changes.
+8. Trigger actually existing paths such as success, failure, pause, resume, and restart.
+9. Rapidly switch inputs and test game boundaries, repeated actions, and state recovery after restart.
+10. Check visuals, HUD, text, safe areas, and touch regions under target desktop and mobile viewports.
+11. When audio is part of the core experience, verify first-interaction unlock, main sound effects, background music, pause behavior, and restart behavior.
+12. Record test results and discovered issues.
+
+### 2D Game Focus
+
+- Sprites, tiles, and platform positions are clear;
+- Animation, hit reaction, and state feedback are readable;
+- HUD and the core gameplay area remain clear;
+- Input results are consistent with game state.
+
+### 3D Game Focus
+
+- Scene, camera, materials, and lighting display normally;
+- Characters, environment, and objectives have clear silhouettes and depth relationships;
+- Camera controls, collision, and restart behavior are stable;
+- Models, textures, and animations can load and run during actual play.
+
+### Test Results
+
+Report using a brief format:
+
+```markdown
+# Smoke Testing And Gameplay QA
+
+- **Result**: <Pass / Fail>
+- **Runtime Environment**: <commands, page, and test viewports>
+- **Verified Paths**: <core operations and gameplay loop>
+- **Issues Found**: <none, or issue list>
+```
+
+For each issue, describe what the player sees, reproduction steps, and the impact on gameplay.

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

@@ -0,0 +1,7 @@
+interface:
+  display_name: "Game Test"
+  short_description: "Complete game smoke testing and gameplay acceptance from the player's perspective, recording issues that affect the experience"
+  default_prompt: "Please use $game-test to playtest this game, complete smoke testing and core gameplay acceptance, and record the issues found."
+
+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."