evomeme 0.1.9 → 0.1.10

package/dist/skills/en-US/evomeme-canvas/SKILL.md

@@ -0,0 +1,52 @@
+---
+name: evomeme-canvas
+description: Before generating or editing any game asset, MUST ensure the evomeme asset canvas for the current workspace is visible to the user and tell the user the canvas link. Use when the task involves image generation, image editing, cutouts, layer separation, video generation, or other evomeme asset tools.
+---
+
+# evomeme Asset Canvas
+
+Before calling any asset generation or editing tool, first complete the canvas startup flow in this skill. The canvas MUST correspond to the workspace for the current task.
+
+## Pre-Launch Checks
+
+Determine whether a canvas service can be reused ONLY from the current conversation record. MUST NOT infer that a service belongs to the current workspace solely because the port is occupied or `/api/health` responds normally.
+
+- When the current conversation explicitly records a foreground canvas terminal and address launched in this conversation for the same workspace, visit `<canvas address>/api/health`; reuse it if the response is normal. If the address is unknown, the health check fails, or the terminal has closed, start it again.
+- When the current conversation has no canvas startup record, MUST NOT reuse an existing evomeme canvas service even if one is found. That service may belong to another workspace; first close the existing service, then follow the flow below to start a new foreground service for the current workspace.
+- When the canvas in the current conversation record belongs to another workspace, likewise close that service first, then restart it for the current workspace.
+
+When closing an existing service, close ONLY processes that can be confirmed to be the evomeme canvas. MUST NOT terminate an unidentified process occupying a port.
+
+## Foreground Launch
+
+1. Open a separate user-visible interactive terminal or command window at the current workspace root.
+2. In that terminal, run the following in the foreground, and run ONLY this:
+
+   ```text
+   npx -y evomeme@latest canvas
+   ```
+
+3. Keep this terminal open. The command MUST continue occupying that terminal, and the user MUST be able to press `Ctrl+C` in it or directly close the terminal window to stop the service.
+4. Wait for the terminal to output "Asset canvas started" and "Canvas address". If startup fails, handle the error or explain it to the user first; MUST NOT continue calling asset generation tools.
+
+MUST NOT run the command as a hidden, detached, or background process. MUST NOT use `&`, `nohup`, `start /B`, `Start-Job`, hidden windows, service managers, or other background startup methods, and DO NOT add `--no-open`. If the current execution environment cannot provide a user-visible terminal that the user can interrupt themselves, ask the user to run the command above in a visible terminal; continue only after confirming the startup output or a passing health check.
+
+Keeping the canvas terminal running in the foreground does not prevent continued work in another terminal or with other tools; DO NOT close the canvas terminal just to continue generation.
+
+## Tell and Guide the User
+
+After obtaining the actual address output by the terminal, immediately send the user a clickable link before calling the first asset tool, and explain:
+
+- Keep the canvas terminal open; pressing `Ctrl+C` in that terminal or closing that terminal will stop the service.
+- The canvas lets the user view the current workspace's assets, generation task status, and generation results in real time.
+- The user can select reference images, generate images, or continue editing directly in the canvas; the AI will also continue using the asset tools for the current workspace, and results will appear in the canvas.
+
+Use the actual address; DO NOT guess the port. You can use the concise wording below:
+
+```markdown
+The asset canvas has started: [Open the evomeme asset canvas](<actual address>). Please keep the command-line window running the canvas open; you can monitor tasks in the canvas, and you can also select reference images directly and use image generation or editing features. Press Ctrl+C in the command line or close that command line to stop the service.
+```
+
+## During Generation
+
+After confirming the canvas is available and telling the user, continue the already authorized asset task. There is no need to ask for confirmation again ONLY to open the canvas. Later generation can reuse ONLY the healthy same-workspace canvas explicitly recorded in the current conversation; if the service stops midway, complete the startup flow again before the next asset tool call.

package/dist/skills/en-US/evomeme-canvas/agents/openai.yaml

@@ -0,0 +1,7 @@
+interface:
+  display_name: "evomemeCanvas"
+  short_description: "Start and guide use of the evomeme asset canvas before asset generation"
+  default_prompt: "Use $evomeme-canvas to start the asset canvas for the current workspace, then continue generating assets after the canvas is running."
+
+policy:
+  allow_implicit_invocation: true

package/dist/skills/en-US/evomeme-cloud-fs/SKILL.md

@@ -0,0 +1,176 @@
+---
+name: evomeme-cloud-fs
+description: Explain evomeme workspace init, .evomemeignore, and cloud file MCPs such as source submission. Use when running npx -y evomeme@latest init, editing ignore rules, or calling evomeme_submit_game_code / evomeme_upload_game_asset.
+---
+
+# evomeme Cloud File System
+
+Explains local workspace initialization, submission ignore rules, and MCPs related to source submission / binary upload.
+
+Load `../evomeme-login/SKILL.md` only after authentication fails; DO NOT load the login skill preventively.
+
+---
+
+## `npx -y evomeme@latest init`
+
+### Purpose
+
+Initialize the evomeme local environment at the project workspace root so later submission and skill orchestration can be used:
+
+- Generate the default **`.evomemeignore`** if it does not exist
+- Copy package-provided skills into the workspace **`.codex/skills/`**
+- Confirm the local login state (for later MCP use)
+
+The npm package name is **`evomeme`** (executable entry `evomeme`).
+
+### Usage
+
+Run at the **project workspace root**:
+
+```bash
+npx -y evomeme@latest init
+```
+
+Optional: use `--cwd <path>` to specify the workspace; use `--name <name>` to provide the work name when a new cloud work needs to be created.
+
+To install the plugin into the IDE (writes MCP configuration, different from init), use:
+
+```bash
+npx -y evomeme@latest install --ide codex
+```
+
+### Notes
+
+- init is **workspace preparation** (ignore rules, skills, login state), not a prerequisite that must be completed before making a game.
+- During development, there is no need to run init for work binding; when submission is needed, directly call `evomeme_submit_game_code` (see below).
+- An existing `.evomemeignore` **will not be overwritten**; skills will be copied/updated into `.codex/skills/` according to the package contents.
+
+---
+
+## `.evomemeignore`
+
+### Purpose
+
+Controls **which paths are ignored** when `evomeme_submit_game_code` collects source code, preventing dependencies, secrets, binaries, or local caches from being submitted to the cloud.
+
+### Usage
+
+- File location: **`.evomemeignore`** at the workspace root
+- **Syntax**: same as `.gitignore` (`#` comments, trailing `/` for directories, `!` negation, etc.)
+- **Scope**: affects only file collection during submission; unrelated to git, and still takes effect even if the project does not use git
+- **Who writes it**: `npx -y evomeme@latest init` generates default contents when the file does not exist; **it does not overwrite when it already exists**. If init has never been run, client submission still applies the built-in default rules
+- **Typical items ignored by default**: `assets/` (including all descendant files), `node_modules/`, `.env` / `.env.*` (retaining `!.env.example`), logs, `.DS_Store` / `Thumbs.db`, `.vscode/` / `.idea/`, `.git/`, `.evomeme/`, `.evomemeignore` itself, `.codex/` (including skills copied by init), etc.
+- **Directory rules apply recursively**: a directory rule ending with `/` ignores the directory itself and all contents at any depth inside it; the root `dist/` and its contents are the ONLY mandatory-submission exception
+- **Binary assets**: **No binary file may be uploaded as source code through `evomeme_submit_game_code`**. Local binaries referenced by the game MUST first go through TOS (see pre-submission checks), then be referenced as URLs in `public/config.json`.
+
+### `dist/` Hard Rules (MUST NOT Be Violated)
+
+Platform preview / draft runtime depends on build artifacts. The **`dist/` under the workspace root MUST be uploaded** and MUST NOT be excluded from submission.
+
+1. **MUST submit `dist/`**: Before calling `evomeme_submit_game_code`, complete the project build first (usually `npm run build` / `pnpm build`), confirm a usable `dist/` exists (containing at least `dist/index.html`); the submitted collection result **MUST include** files under `dist/`.
+2. **MUST NOT write ignore rules**: MUST NOT add `dist`, `dist/`, `/dist`, `/dist/**`, `**/dist/**`, or any other rule that would exclude the build artifact directory to `.evomemeignore` (also MUST NOT bypass this with equivalent patterns).
+3. **If already ignored, MUST fix it first**: If the existing `.evomemeignore` (or equivalent rules) already ignores `dist/`, these rules **MUST be deleted** before submission, then build, then submit. Calling `evomeme_submit_game_code` is **forbidden** until the ignore has been removed.
+4. **DO NOT solve binaries inside dist with ignore**: If `dist/` contains binaries that cannot go through source submission, handle them on the source side (local assets first TOS + `public/config.json` URL, then rebuild) so the new `dist/` can be submitted; it is **forbidden** to add the whole `dist/` to ignore for this reason.
+5. **`dist/` MUST contain zero binaries**: Recursively check every file in `dist/`; only files that can be strictly decoded as UTF-8 text are allowed. Images, audio, video, fonts, models, WASM, archives, executable files, and all other binaries are forbidden, even if the file extension is disguised as text.
+6. **`dist/` MUST be self-contained and portable**: Package runtime dependencies may point ONLY to files inside `dist/`, and must use `./` or `../` paths relative to the referencing file; they MUST NOT depend on the workspace, source directory, development server, or deployment site root path.
+
+After modifying `.evomemeignore`, the next `evomeme_submit_game_code` will collect according to the new rules.
+
+---
+
+## File-System-Related MCP Tools
+
+When cloud file capability is needed, **directly call** the tools below. DO NOT bypass MCP by using curl / scripts instead.
+
+| Tool Name | Function |
+| --- | --- |
+| `evomeme_submit_game_code` | **Game publication** (not pure source upload): collects according to `.evomemeignore` and fully overwrites the cloud work, **MUST include a runnable `dist/`**; irreversible. |
+| `evomeme_upload_game_asset` | Hands supported local images, audio, video, or common 3D models (GLB/GLTF/FBX/OBJ/STL) to the server for TOS upload; a public `asset_url` is returned only after content review passes. Other types are forbidden to upload. |
+
+### `evomeme_submit_game_code`
+
+Fully syncs the **UTF-8 text source code** collected from the current workspace according to `.evomemeignore` to the cloud work.
+
+**Hard constraint: no binary file may be uploaded through this tool** (including images, models, audio/video, fonts, archives, etc.). Source submission collects only text; supported images, audio, video, and common 3D models (GLB/GLTF/FBX/OBJ/STL) can go to TOS only through `evomeme_upload_game_asset`; fonts, archives, and other unlisted types do not support upload. Before submission, the release artifact gate below MUST also pass; if any binary or absolute local dependency is found, calling this tool is forbidden.
+
+Optional parameters:
+
+- `name`: work display name.
+- `cover_url`: game cover (public image URL).
+
+#### Two Points That MUST Be Emphasized During Submission
+
+1. **Name: SHOULD include `name` with every submission (pass the current official name, not a new name each time)**  
+   The interface-level `name` is optional, but the Agent **SHOULD by default** include the game's **current official name** on every call (consistent with the plan / cover title / user-approved name). The intent is for the cloud to always receive this name and stay synchronized, **not** to require changing it to a new name every time. When the user has not requested a rename, repeatedly passing the same old name is fine. Omit it ONLY when the user explicitly says "do not include the name this time".
+
+2. **Cover: first submission MUST have a cover**  
+   - When submitting this work to the cloud for the **first time** (no local successful submission record yet / no cover has been included yet), `cover_url` **MUST** be included; empty submission is not allowed.  
+   - Before submission, first read **`_game_cover_url`** from `public/config.json`:  
+     - If it exists and `value` is a usable image URL -> **directly use** that value as `cover_url`;  
+     - If it does not exist or is invalid -> **MUST** load and follow `../evomeme-cover/SKILL.md` to generate a 9:16 cover, write `_game_cover_url`, then submit (DO NOT skip the cover skill and hard-code a URL).  
+
+Before calling, tell the user in one or two sentences that this submission will **fully overwrite** the existing cloud code and is irreversible; if the user explicitly objects, DO NOT submit.
+
+#### Pre-Submission Code Safety Review (A Simple Pass Is Enough)
+
+Before calling `evomeme_submit_game_code`, the Agent SHOULD quickly read the main source code that will be submitted (focus on files the user changed or added; if time is tight, sample entry files, `package.json`, scripts, and network-related files), and submit only after confirming there is no obviously dangerous code.
+
+Pay special attention to the following (if any are found, **refuse submission** and tell the user why; DO NOT call this tool):
+
+- Download and execute: `curl ... | bash`, `Invoke-Expression` + remote download, `certutil` / `bitsadmin` pulling files, etc.
+- Reverse shell / remote-control traces, mining scripts, or mining-pool addresses
+- Long encoded execution chains such as `eval(atob(...))` / `Function(atob(...))`; long `powershell -enc` payloads
+- `preinstall` / `postinstall` / `prepare` in `package.json` pulling remote resources or executing unknown commands
+
+This is a **shallow manual (Agent) review** and does not replace server-side checks; `fetch` in normal game logic and ordinary build scripts do not need to be treated as dangerous.
+
+#### Pre-Submission Release Artifact Gate (MUST NOT Be Skipped)
+
+Before calling `evomeme_submit_game_code`:
+
+1. Confirm `.evomemeignore` **does not** ignore `dist/` (see "`dist/` Hard Rules" above); if it does, delete those rules first.
+2. Run the production build, confirm `dist/` at the workspace root has been generated, and that it contains at least `dist/index.html`.
+3. **Recursively check the contents of all files in `dist/`, not only extensions**: every file MUST be readable strictly as UTF-8 text; if a single binary file exists, immediately stop submission, report the exact path, then migrate the asset according to the flow below and rebuild.
+4. **Scan dependency references in the source, configuration, and `dist/` text included in this submission**, focusing on HTML `src` / `href`, CSS `url()`, JS/TS `import` / `require` / dynamic imports, `fetch`, Worker, `new URL(...)`, and asset paths in configuration. The following are forbidden:
+   - Windows drive paths (such as `C:\\...`), UNC paths (such as `\\\\server\\...`), or POSIX local absolute paths (such as `/Users/...`, `/home/...`, `/tmp/...`);
+   - `file://`, and any path pointing to a local file in the current workspace or outside the workspace;
+   - site-root paths starting with `/` (such as `/assets/a.js`, `/config.json`). The game may be published under a subpath, so runtime in-package references MUST use `./` or `../`;
+   - `localhost`, `127.0.0.1`, `0.0.0.0`, development server addresses, or runtime dependencies on `src/`, `public/`, the project root, or unbuilt `.ts` / `.tsx` files.
+5. **The ONLY allowed exceptions are intentionally used and publicly accessible external `https://` URLs**, such as TOS assets, CDNs, or official APIs; they are not local absolute dependencies. MUST NOT treat `http://`, local-machine URLs, or accidentally leftover development addresses as exceptions. Third-party package names in source code may exist only as build-time inputs; the production build MUST resolve or bundle them and MUST NOT leave browser-unresolvable dependencies in `dist/`.
+6. Preview with `dist/` as the static server root. MUST NOT let the server fall back to reading source code or other workspace directories; confirm the page and key game flow run, and that requests do not escape `dist/` (except intentionally used public `https://` external requests).
+7. Confirm the submission collection result includes the complete `dist/`. If any check fails, MUST list the exact file and matched path / dependency, fix it, rebuild, and recheck from step 1; **submission is forbidden until the gate passes**.
+
+#### Local Binary Reference Check Before Submission (MUST NOT Be Skipped)
+
+Before calling `evomeme_submit_game_code`, MUST proactively check whether the workspace still contains **local binary files referenced by code or configuration** (for example, relative paths in source pointing to `.png` / `.jpg` / `.webp` / `.gif` / `.glb` / `.mp3`, etc., or configuration containing local paths instead of public `https://` URLs).
+
+If such references exist, MUST finish handling all of them before submission. The order is fixed:
+
+1. Use `evomeme_upload_game_asset` to upload the local binary to TOS and obtain a public `asset_url`;
+2. Add that local path to `.evomemeignore` to ensure it does not enter source collection (**MUST NOT** ignore `dist/` for this reason);
+3. Change the runtime reference to be written into `public/config.json` (a flat visible parameter, with `type` as `image` / `audio`, etc., and `value` as the `asset_url` above), and have game code read the URL only from configuration;
+4. Rebuild to refresh `dist/`; confirm source, configuration, and `dist/` no longer depend on local binary paths, and that the new `dist/` contains no binary files, then call `evomeme_submit_game_code`.
+
+Submission is **forbidden** until the checks and handling above are complete. If `.evomemeignore` was just changed, use the updated rules as authoritative.
+
+Call results:
+
+- **Success**: The tool returns a **plain-text multiline** description (for example, containing `thread_id`, `checkpoint_id`, etc.), not JSON with a `success` field. Restate key information to the user according to the body. After success, **MUST** give the user the evomeme drafts link and guide them to open and browse the work just submitted:
+
+  https://www.evomeme.com/profile/works/draft
+
+  Also tell them: they can view the draft on that page and publish the game themselves in evomeme. DO NOT only say "submission succeeded" without giving the link.
+- **Failure**: The MCP result has `isError`, and the body is the error description. Show the original text to the user; if the error points to login / token expiration, load `../evomeme-login/SKILL.md`, recover, and retry the original submission.
+
+### `evomeme_upload_game_asset`
+
+Hands supported local images, audio, video, or common 3D models (GLB/GLTF/FBX/OBJ/STL) to the server for TOS upload, and returns a public `asset_url` only after content safety review passes; other types are forbidden to upload. Prefer this tool when handling media / model resources before source submission; see `../evomeme-tos-upload/SKILL.md` for details.
+
+---
+
+## References
+
+- Main entry and development orchestration: `../game-director/SKILL.md`, `../game-develop/SKILL.md`
+- Game cover: `../evomeme-cover/SKILL.md`
+- Login recovery (only after authentication errors): `../evomeme-login/SKILL.md`
+- TOS upload: `../evomeme-tos-upload/SKILL.md`

package/dist/skills/en-US/evomeme-cloud-fs/agents/openai.yaml

@@ -0,0 +1,7 @@
+interface:
+  display_name: "evomemeCloud FS"
+  short_description: "Initialize the game workspace, manage submission ignore rules, and safely submit code and binary assets"
+  default_prompt: "Use $evomeme-cloud-fs to prepare my game workspace, check the submission contents, and safely submit the game to the cloud."
+
+policy:
+  allow_implicit_invocation: true

package/dist/skills/en-US/evomeme-cover/SKILL.md

@@ -0,0 +1,132 @@
+---
+name: evomeme-cover
+description: Use the image-generation MCP to generate a 9:16 portrait game cover (with a large title, gameplay-related background, and art consistent with the game). After success, MUST write the URL to _game_cover_url in public/config.json. Use when a work cover or submitted cover_url is needed, or when the user wants a promotional image/store cover.
+---
+
+# Game Cover Generation
+
+## Overview
+
+Generate **one** portrait cover image for an evomeme work, for cloud submission (`cover_url` of `evomeme_submit_game_code`) or display.
+
+It **MUST** be generated through MCP `evomeme_generate_game_image`; MUST NOT use local SVG, screenshot collage, or non-MCP channels to impersonate a cover.
+
+Load `../evomeme-login/SKILL.md` only after authentication fails; DO NOT load the login skill preventively.
+
+---
+
+## Hard Requirements (All Required)
+
+| Requirement | Description |
+| --- | --- |
+| **Aspect ratio** | MUST be **9:16 portrait**. MCP `size` is **fixed** to `1440x2560` (the ONLY allowed preset that is exactly 9:16). MUST NOT use square, landscape, or any other size. |
+| **Large title** | The image MUST contain a clear, readable **large Chinese game title** (or the official name specified by the user), centered or with a clear visual focus, large enough to look like a store/store-page cover rather than small text in a corner. |
+| **Strongly relevant background** | The background scene / main composition MUST directly reflect the game's core gameplay, character, or world (for example, parkour should show running and obstacles, match-3 should show a gem-board atmosphere). MUST NOT use unrelated scenery or generic abstract gradients. |
+| **Consistent art style** | Style, color palette, line/rendering texture MUST match the current game (`../game-art/SKILL.md` or the established art specification), and MUST NOT start a separate style. |
+
+Difference from the runtime asset skill: `../game-asset-image-generator/SKILL.md` often requires backgrounds to have "no text"; **the cover MUST have a large title**, so DO NOT apply its `no text` prohibition here.
+
+---
+
+## Preparation Before Generation
+
+1. Confirm the game's **official name** (used for the large text in the image; DO NOT use a temporary placeholder such as "Untitled Game").
+2. Summarize from the plan / `game-art` / existing visuals:
+   - one-sentence gameplay and visual subject;
+   - art-style keywords (such as pixel, flat cartoon, cyberpunk, etc.);
+   - main colors and mood.
+3. Optional: if there is a public URL for a strong style reference image, it may be used as `reference_image_url` (it MUST match this game).
+
+---
+
+## MCP Call (Fixed Parameters)
+
+Call `evomeme_generate_game_image` **once**:
+
+| Parameter | Value |
+| --- | --- |
+| `image_type` | `background` (the cover is a full portrait composition; DO NOT use the `asset` cutout type) |
+| `size` | **`1440x2560`** (mandatory, corresponding to 9:16) |
+| `image_model` | **`asset-pro`** (quality tier for covers; DO NOT use `asset-lite`) |
+| `prompt` | See the prompt structure below |
+| `reference_image_url` | Optional |
+
+MUST NOT pass a size that is not in the tool enum (such as `1080x1920`). `image_model` allows ONLY `asset-max` / `asset-pro` / `asset-lite`.
+
+### Prompt Structure (MUST Cover)
+
+Chinese or a Chinese-English mix may be used, but the following elements MUST be written clearly:
+
+1. **Portrait composition**: `9:16 vertical poster` / `mobile portrait cover`, with the subject filling the vertical frame.
+2. **Large title**: state the **exact game name** to render in the image, and require `large bold title text`, high contrast, clearly readable, no garbled characters.
+3. **Gameplay-related background**: describe a scene and key object/character pose strongly related to the game subject (serving only the cover narrative; DO NOT pile up UI).
+4. **Art style**: a style sentence consistent with the game (aligned with `game-art`); one sentence for color palette and mood.
+5. **Quality**: `high detail`, `game store cover`, `no watermark`, `no UI chrome`, `no small unreadable text`.
+
+DO NOT write `no text` (it conflicts with the large title).
+
+### Successful Return and Permanent Save (MUST)
+
+The tool will poll the task to a terminal state by itself and return text metadata plus an MCP `image` content block. Parse `tos_url` (and `job_id`, `local_path`, etc.) from the text; `tos_url` is the public cover address.
+
+**After image generation succeeds, the Agent MUST immediately** write that URL into the fixed key **`_game_cover_url`** in the workspace `public/config.json` as the permanent cover record. The cover flow MUST NOT be considered complete until this has been written.
+
+Write convention:
+
+1. If `public/config.json` does not exist, create a valid JSON object before writing.
+2. The key name MUST be **`_game_cover_url`** (DO NOT rename it, DO NOT write it to another key).
+3. Recommended structure (consistent with other asset items, convenient for tools and submission to read):
+
+```json
+{
+  "_game_cover_url": {
+    "value": "https://...",
+    "type": "image",
+    "image_type": "Cover",
+    "size": "1440x2560",
+    "label": "Game Cover"
+  }
+}
+```
+
+4. If the project already has other configuration items, **merge the write** and MUST NOT overwrite or empty the whole file.
+5. When regenerating the cover, **overwrite** the `value` of `_game_cover_url` with the new `tos_url`.
+6. After writing, confirm the JSON parses, then report to the user.
+
+For subsequent submission, read the cover link from `public/config.json` -> `_game_cover_url` -> `value`, and pass it into `cover_url` of `evomeme_submit_game_code` (see `../evomeme-cloud-fs/SKILL.md`).
+
+---
+
+## Delivery and Follow-Up
+
+1. `_game_cover_url` has been written to `public/config.json`; show the cover URL to the user, and explain that it was generated in 9:16 with a title, style consistency, and gameplay relevance.
+2. If used for cloud submission: read `_game_cover_url.value` as `cover_url`; `name` SHOULD match the game name on the cover.
+3. If the user is not satisfied: tighten style/subject/title layout according to feedback, then **call** the image-generation MCP **again** and **overwrite** `_game_cover_url` with the new URL. DO NOT fake it by locally editing the image.
+
+---
+
+## Checklist
+
+Before calling:
+
+- [ ] Is `size` `1440x2560`
+- [ ] Is `image_type` `background`
+- [ ] Is `image_model` `asset-pro`
+- [ ] Does the prompt contain the **exact game name** and require a large title
+- [ ] Is the prompt background strongly related to gameplay/subject
+- [ ] Is the prompt style consistent with the current game art
+- [ ] Has `no text` / landscape size / `asset` cutout type not been misused
+
+After a successful call (MUST):
+
+- [ ] `tos_url` has been written to `_game_cover_url` in `public/config.json`
+- [ ] JSON is valid, and no other configuration items were accidentally deleted
+
+---
+
+## References
+
+- Image-generation details and other sizes: `../game-asset-image-generator/SKILL.md`
+- Art style: `../game-art/SKILL.md`
+- Submit cover: `../evomeme-cloud-fs/SKILL.md`
+- Login recovery (only after authentication errors): `../evomeme-login/SKILL.md`

package/dist/skills/en-US/evomeme-cover/agents/openai.yaml

@@ -0,0 +1,7 @@
+interface:
+  display_name: "evomemeCover"
+  short_description: "Generate a 9:16 portrait cover with the official title for a game, and save the publication link"
+  default_prompt: "Use $evomeme-cover to generate a portrait cover for my game with the official title, core gameplay, and consistent style, then save the cover link to the project configuration."
+
+policy:
+  allow_implicit_invocation: true