summer-engine 3.8.0 → 4.2.0

package/library/skills/pixel-art/SKILL.md

@@ -1,11 +1,11 @@
 ---
 name: pixel-art
-description: "Generate pixel-art assets — sprites, items, tiles, portraits — at a specific resolution with pixel-perfect grid, limited palette, retro feel."
+description: "Generate pixel-art sprites, items, tiles and portraits at a set resolution with a limited palette."
 license: MIT
 compatibility: [Cursor, Claude Code, Windsurf, Codex]
 category: 2d-assets
 user-invocable: true
-allowed-tools: Read Grep Glob Write Edit summer_generate_image summer_search_assets summer_import_from_url summer_set_resource_property
+allowed-tools: Read Grep Glob Write Edit summer_assets_generate_image summer_assets_search summer_import_from_url summer_set_resource_property summer_call
 paths: ["assets/**", "art/pixel/**", "sprites/**"]
 ---
 
@@ -13,12 +13,12 @@ paths: ["assets/**", "art/pixel/**", "sprites/**"]
 
 This skill generates pixel-art sprites, items, tiles, icons and portraits at a target resolution (32×32, 64×64, 128×128). Pixel art has hard constraints (grid alignment, limited palette, no anti-aliased edges) that diffusion models break by default. The prompt patterns and post-processing below make the output read as pixel art instead of a blurry small image.
 
-**Backing tool:** `summer_generate_image` with an explicit pixel-art prompt.
+**Backing operation:** `assets.generate_image` with an explicit pixel-art prompt.
 
-Two things about that tool you have to know before writing a call, because both silently do nothing:
+Two things about that operation you have to know before writing a call:
 
 - **There is no `"pixel"` style preset.** `style` accepts exactly `realistic`, `cartoon`, `anime`, `none`; anything else is coerced to `none`. Only `cartoon` and `anime` do anything at all (they append a short suffix); `realistic` and `none` append nothing. So `style: "pixel"` is identical to `style: "none"` — the pixel look has to come entirely from the prompt. Use `style: "none"`.
-- **`options` is not a general passthrough.** The MCP tool forwards `options` to the server, which only recognizes Nano Banana provider keys: `seed`, `outputFormat`, `safetyTolerance`, `syncMode`, `systemPrompt`, `limitGenerations`, `thinkingLevel`. `image_size` and `negative_prompt` are not among them and are dropped without an error. There is no size or aspect-ratio argument on this tool at all — MCP images come back at the server's 1:1 default. Put framing and exclusions in the prompt text instead.
+- **There is no `options` object and no negative prompt.** Shape is `aspectRatio` (`1:1` default, right for sprites and tiles), a minimum size is `width` + `height`, and `seed` repeats a look on Nano Banana models. Exclusions go in the prompt text. The model renders far above the pixel grid either way; the target resolution comes from the downscale below.
 
 Pixel-perfect output is enforced in Summer Engine with Nearest texture filtering
 and by downscaling to the target resolution after generation.
@@ -62,7 +62,7 @@ shading: 3-tone (light, mid, shadow), no gradients, no AA
 ### 2. Search for existing assets
 
 ```
-summer_search_assets(query="<subject> pixel", assetType="2d_image", source="all")
+assets.search({ query: "<subject> pixel", assetType: "2d_image", scope: "all" })
 ```
 
 ### 3. Build the prompt
@@ -78,18 +78,18 @@ The model can't actually generate at 32×32 — it generates at 1024×1024 with
 ### 4. Generate
 
 ```
-summer_generate_image(
-  prompt="pixel art slime monster, 32x32 sprite, PICO-8 palette, hard 1px outline in palette's darkest color, 3-tone shading, no anti-aliasing, no blur, sharp pixel edges, front-facing. Not blurry, no smooth gradients, no soft edges, not photorealistic, no 3D render.",
-  model="nano-banana-2",
-  style="none",
-  removeBackground=true
-)
+assets.generate_image({
+  prompt: "pixel art slime monster, 32x32 sprite, PICO-8 palette, hard 1px outline in palette's darkest color, 3-tone shading, no anti-aliasing, no blur, sharp pixel edges, front-facing. Not blurry, no smooth gradients, no soft edges, not photorealistic, no 3D render.",
+  model: "nano-banana-2",
+  style: "none",
+  removeBackground: true
+})
 ```
 
 Two deliberate choices there:
 
-- **The negations live in the prompt.** There is no `negative_prompt` argument — putting one in `options` is dropped silently. Diffusion models honor in-prompt negations less reliably than a real negative-prompt field, so state them as plain sentences at the end and expect to regenerate more often than you would on a provider UI that exposes the field.
-- **`removeBackground: true` is a top-level argument**, not an `options` key. It runs a background-removal pass after generation and returns a PNG with true alpha. Prefer it over asking for "transparent background" in the prompt, which makes models paint a literal checkerboard.
+- **The negations live in the prompt.** There is no `negative_prompt` argument. Diffusion models honor in-prompt negations less reliably than a real negative-prompt field, so state them as plain sentences at the end and expect to regenerate more often than you would on a provider UI that exposes the field.
+- **`removeBackground: true` is its own argument.** It runs a background-removal pass after generation and returns a PNG with true alpha. Prefer it over asking for "transparent background" in the prompt, which makes models paint a literal checkerboard.
 
 ### 5. Downscale to target resolution
 
@@ -148,7 +148,7 @@ Confirm `Filter: Nearest` is set in the import dock OR project-wide.
 - **Skipping the downscale.** The model returns a 1024×1024 pixel-style image. If you import that as a 1024 texture, the "pixels" are actually 32-pixel blocks of soft color. Downscale to true target resolution OR set `Filter: Nearest` so the up-rendering doesn't smooth.
 - **No `Filter: Nearest`.** The default texture filtering is bilinear. Set
   Nearest on import or project-wide for pixel art.
-- **Reaching for `negative_prompt` or `image_size`.** Neither exists on this tool; both are dropped without an error, so the call looks like it worked and the output is off-style. Negations go in the prompt text; size is fixed.
+- **Reaching for `negative_prompt` or `image_size`.** Neither exists on `assets.generate_image`, and a field it does not list does nothing, so the call looks like it worked and the output is off-style. Negations go in the prompt text; shape is `aspectRatio`, a minimum size `width` + `height`.
 - **Inconsistent palette across the cast.** Pick a named palette (PICO-8, NES, custom hex list) and re-use across every asset in the project. Different palettes = the project doesn't read as one game.
 - **Generating walk-cycle frames as one image.** Sprite sheets via single-prompt are unreliable. Route to `sprite-sheet`.
 
@@ -160,20 +160,24 @@ Confirm `Filter: Nearest` is set in the import dock OR project-wide.
 - **User specifies a palette like "Sweetie-16" or "Endesga-32" and the model ignores it.** Name the hex codes explicitly. Palette names alone are unreliable below the top 5-10 famous ones.
 - **Tilesets need to tile cleanly.** Pixel-art tile-edge cleanliness from raw generation is poor. Generate the tile grid, then fix edge seams by hand in Aseprite.
 
+## Without Summer Engine
+
+In a session without Summer Engine tools (the assets profile; the `summer-assets` skill has the whole loop), do steps 1-5 and skip step 6 (import and wiring). In step 5, downscale with nearest-neighbour in an image editor; the engine settings there do not apply. Pass `out` with the person's folder so the PNG lands there (the `summer-assets` skill says how), and tell them to turn texture filtering off in their engine.
+
 ## Fallback (no MCP)
 
 Print the call:
 
 ```
-summer_generate_image(
-  prompt="<pixel art prompt with full anchor>. Not blurry, no smooth gradients, no anti-aliasing.",
-  model="nano-banana-2",
-  style="none",
-  removeBackground=true
-)
+assets.generate_image({
+  prompt: "<pixel art prompt with full anchor>. Not blurry, no smooth gradients, no anti-aliasing.",
+  model: "nano-banana-2",
+  style: "none",
+  removeBackground: true
+})
 ```
 
-The Summer dashboard *does* expose size and negative-prompt controls that the MCP tool does not — if the user is running it there, tell them to set square + a real negative prompt.
+The Summer dashboard also exposes a negative-prompt control — if the user is running it there, tell them to set square + a real negative prompt.
 
 Tell the user to run via the Summer dashboard, downscale in Aseprite/GIMP to true target resolution with nearest-neighbor, then `summer_import_from_url` (or drop into `res://sprites/`) and set `Filter: Nearest`.
 
@@ -193,4 +197,19 @@ After the asset is wired:
 - `sprite-sheet` — animated pixel frames.
 - `character-portrait` — high-res counterpart.
 - `asset-strategy` — meta-router.
-- `../../references/mcp-tools-reference/mcp-tools-reference.md` — `summer_generate_image` schema.
+- `summer_docs_read` id `reference/mcp-tools-reference` — how to call `assets.generate_image`.
+
+<!-- shell-commands: generated from the operation catalog by npm run generate:registry; do not edit by hand -->
+## From a shell
+
+No Summer MCP tools in this session? Run each one as a command; when `summer --version` is missing or below 4.0, use `npx -y summer-engine@latest` in place of `summer`. Fields are flags in kebab-case (`--scene-path res://main.tscn`) or one `--input '<json>'`, and `summer ops describe <op>` prints the exact input. The `summer-cli` skill has the rest.
+
+| In this skill | Command |
+|---|---|
+| `assets.generate_image`, `summer_assets_generate_image` | `summer assets generate-image` |
+| `summer_assets_search` | `summer assets search` |
+| `summer_docs_read` | `summer docs read` |
+| `summer_import_from_url` | `summer engine import-from-url` |
+| `summer_set_prop` | `summer engine set-prop` |
+| `summer_set_resource_property` | `summer engine set-resource-property` |
+<!-- /shell-commands -->

package/library/skills/pixel-art/resource.yaml

@@ -1,7 +1,7 @@
 id: skill/pixel-art
 kind: skill
 version: 1.0.4
-summary: Generate pixel-art assets — sprites, items, tiles, portraits — at a specific resolution with pixel-perfect grid, limited palette, retro feel.
+summary: "Generate pixel-art sprites, items, tiles and portraits at a set resolution with a limited palette."
 use_when:
   - generating pixel-art assets — sprites, items, tiles, portraits — in a pixel style at a specific resolution (32x32, 64x64, 128x128)
   - a retro or low-resolution 2D game needs sprites, tiles, or portraits on a fixed grid with a limited palette

package/library/skills/play/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: play
-description: "Run the project in Summer Engine, wait briefly, then report what's happening — clean run, errors, or warnings."
+description: "Run the project in Summer Engine, wait briefly, then report a clean run, errors or warnings."
 license: MIT
 compatibility: [Cursor, Claude Code, Windsurf, Codex]
 category: scene-and-project
@@ -111,3 +111,21 @@ Any Summer project with a main scene set in `project.godot`.
 ## See also
 
 - `debug` — what to do when /play surfaces an error
+
+<!-- shell-commands: generated from the operation catalog by npm run generate:registry; do not edit by hand -->
+## From a shell
+
+No Summer MCP tools in this session? Run each one as a command; when `summer --version` is missing or below 4.0, use `npx -y summer-engine@latest` in place of `summer`. Fields are flags in kebab-case (`--scene-path res://main.tscn`) or one `--input '<json>'`, and `summer ops describe <op>` prints the exact input. The `summer-cli` skill has the rest.
+
+| In this skill | Command |
+|---|---|
+| `summer_clear_console` | `summer engine clear-console` |
+| `summer_get_console` | `summer engine get-console` |
+| `summer_get_debugger_errors` | `summer engine get-debugger-errors` |
+| `summer_get_diagnostics` | `summer engine get-diagnostics` |
+| `summer_get_script_errors` | `summer engine get-script-errors` |
+| `summer_is_running` | `summer engine is-running` |
+| `summer_open_scene` | `summer engine open-scene` |
+| `summer_play` | `summer engine play` |
+| `summer_stop` | `summer engine stop` |
+<!-- /shell-commands -->

package/library/skills/play/resource.yaml

@@ -1,7 +1,7 @@
 id: skill/play
 kind: skill
 version: 1.0.2
-summary: Run the project in Summer Engine, wait briefly, then report what's happening — clean run, errors, or warnings.
+summary: "Run the project in Summer Engine, wait briefly, then report a clean run, errors or warnings."
 use_when:
   - the user says 'play', 'run it', 'test it', 'let me see it', or 'start the game'
   - checking that the project still starts and runs cleanly right after a change

package/library/skills/playtesting-a-feature/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: playtesting-a-feature
-description: "Before claiming a gameplay feature done: actually run the game and walk through the feature. Static diagnostics and type checks do not count."
+description: "Before calling a gameplay feature done, run the game and walk through it. Static checks do not count."
 ---
 
 # Playtesting A Feature
@@ -261,3 +261,26 @@ Press play. Walk the path. Probe the edges. Read the diagnostics. Then claim don
 - `debug` — when the playtest surfaces a crash or error.
 - `investigating-bugs` — when the playtest surfaces a reproducible logical bug.
 - `debugging-game-feel` — when the feature works but feels wrong.
+
+<!-- shell-commands: generated from the operation catalog by npm run generate:registry; do not edit by hand -->
+## From a shell
+
+No Summer MCP tools in this session? Run each one as a command; when `summer --version` is missing or below 4.0, use `npx -y summer-engine@latest` in place of `summer`. Fields are flags in kebab-case (`--scene-path res://main.tscn`) or one `--input '<json>'`, and `summer ops describe <op>` prints the exact input. The `summer-cli` skill has the rest.
+
+| In this skill | Command |
+|---|---|
+| `summer_batch` | `summer engine batch` |
+| `summer_clear_console` | `summer engine clear-console` |
+| `summer_game_control` | `summer engine game-control` |
+| `summer_game_input` | `summer engine game-input` |
+| `summer_game_probe` | `summer engine game-probe` |
+| `summer_get_console` | `summer engine get-console` |
+| `summer_get_debugger_errors` | `summer engine get-debugger-errors` |
+| `summer_get_diagnostics` | `summer engine get-diagnostics` |
+| `summer_get_runtime_tree` | `summer engine get-runtime-tree` |
+| `summer_inspect_runtime_node` | `summer engine inspect-runtime-node` |
+| `summer_is_running` | `summer engine is-running` |
+| `summer_play` | `summer engine play` |
+| `summer_recent_events` | `summer engine recent-events` |
+| `summer_wait_for_event` | `summer engine wait-for-event` |
+<!-- /shell-commands -->

package/library/skills/playtesting-a-feature/resource.yaml

@@ -1,7 +1,7 @@
 id: skill/playtesting-a-feature
 kind: skill
 version: 1.1.2
-summary: "Before claiming a gameplay feature done: actually run the game and walk through the feature. Static diagnostics and type checks do not count."
+summary: "Before calling a gameplay feature done, run the game and walk through it. Static checks do not count."
 use_when:
   - about to claim a gameplay feature is done, shipped, or working — requires actually running the game and walking through the feature first
   - a feature passes static diagnostics but nobody has actually run the game and exercised it yet

package/library/skills/procedural-animation/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: procedural-animation
-description: "Runtime bone modification on top of clips — head look-at, foot IK, hand-grabs-prop, additive lean, recoil. Code-and-modifier patterns, not generation."
+description: "Runtime bone changes on top of clips: head look-at, foot IK, hand grabs a prop, lean, recoil."
 license: MIT
 compatibility: [Cursor, Claude Code, Windsurf, Codex]
 category: animation
@@ -61,31 +61,35 @@ The most common NPC liveliness fix.
 ```gdscript
 func run(ctx):
     var skel = ctx.find("NPC").find_children("*", "Skeleton3D", true, false)[0]
-    var mod := ctx.look_at_modifier(skel, ctx.find("Player"), {
+    var mod = ctx.look_at_modifier(skel, ctx.find("Player"), {
         "bone_name": "Head", "forward_axis": 2, "primary_rotation_axis": 1,
         "use_secondary_rotation": true, "use_angle_limitation": true,
         "symmetry_limitation": true, "primary_limit_angle": 1.4, "secondary_limit_angle": 1.0,
     })
 ```
 
-Unknown prop names land in the `prop_warnings` report entry instead of failing silently — read it. On an older engine the helper is a plain script error; fall back to the structured ops:
+Unknown prop names land in the `prop_warnings` report entry instead of failing silently — read it. On an older engine the helper is a plain script error; fall back to plain GDScript in the same tool (confirm the bone names first with `summer_inspect_node`):
 
 ```
-summer_inspect_node "./World/NPC/Skeleton3D"   # confirm bone names
-summer_add_node parent="./World/NPC/Skeleton3D" type="LookAtModifier3D" name="HeadLookAt"
-summer_set_prop "./World/NPC/Skeleton3D/HeadLookAt" key="bone_name" value="Head"
-summer_set_prop "./World/NPC/Skeleton3D/HeadLookAt" key="forward_axis" value=2   # +Z forward (Meshy default)
-summer_set_prop "./World/NPC/Skeleton3D/HeadLookAt" key="primary_rotation_axis" value=1   # Y-up
-summer_set_prop "./World/NPC/Skeleton3D/HeadLookAt" key="use_secondary_rotation" value=true
-summer_set_prop "./World/NPC/Skeleton3D/HeadLookAt" key="use_angle_limitation" value=true    # OFF by default — nothing clamps until you set this
-summer_set_prop "./World/NPC/Skeleton3D/HeadLookAt" key="symmetry_limitation" value=true     # one angle drives both directions
-summer_set_prop "./World/NPC/Skeleton3D/HeadLookAt" key="primary_limit_angle" value=1.4      # ~80°, prevents the Exorcist
-summer_set_prop "./World/NPC/Skeleton3D/HeadLookAt" key="secondary_limit_angle" value=1.0
+summer_run_script(scenePath="res://main.tscn", source="""
+func run(ctx):
+    var skel = ctx.find("NPC").find_children("*", "Skeleton3D", true, false)[0]
+    var look = LookAtModifier3D.new()
+    look.name = "HeadLookAt"
+    look.bone_name = "Head"
+    look.forward_axis = 2                 # +Z forward (Meshy default)
+    look.primary_rotation_axis = 1        # Y-up
+    look.use_secondary_rotation = true
+    look.use_angle_limitation = true      # OFF by default: nothing clamps until you set this
+    look.symmetry_limitation = true       # one angle drives both directions
+    look.primary_limit_angle = 1.4        # ~80 degrees, prevents the Exorcist
+    look.secondary_limit_angle = 1.0
+    skel.add_child(look)
+    ctx.set_owner_recursive(look)
+    ctx.save_scene()
+""")
 ```
 
-Every `summer_set_prop` above also needs the required `scenePath` (e.g.
-`scenePath="res://main.tscn"`); the paths are shown bare here for readability.
-
 There is no `symmetry_limit` and no `secondary_rotation_axis` property on
 `LookAtModifier3D` — the real names are the ones above, and the secondary
 rotation axis is derived, not set. Confirmed against the shipped 4.6.1 binary;
@@ -264,3 +268,21 @@ driving them. Foot raycasts can be set up visually with a RayCast3D child.
 - Upstream API reference matching the current Summer technical base:
   `SkeletonModifier3D`, `LookAtModifier3D`, `SkeletonIK3D`,
   `PhysicalBoneSimulator3D`.
+
+<!-- shell-commands: generated from the operation catalog by npm run generate:registry; do not edit by hand -->
+## From a shell
+
+No Summer MCP tools in this session? Run each one as a command; when `summer --version` is missing or below 4.0, use `npx -y summer-engine@latest` in place of `summer`. Fields are flags in kebab-case (`--scene-path res://main.tscn`) or one `--input '<json>'`, and `summer ops describe <op>` prints the exact input. The `summer-cli` skill has the rest.
+
+| In this skill | Command |
+|---|---|
+| `summer_add_node` | `summer engine add-node` |
+| `summer_get_scene_tree` | `summer engine get-scene-tree` |
+| `summer_get_script_errors` | `summer engine get-script-errors` |
+| `summer_inspect_node` | `summer engine inspect-node` |
+| `summer_inspect_resource` | `summer engine inspect-resource` |
+| `summer_run_script` | `summer engine run-script` |
+| `summer_save_scene` | `summer engine save-scene` |
+| `summer_set_prop` | `summer engine set-prop` |
+| `summer_set_resource_property` | `summer engine set-resource-property` |
+<!-- /shell-commands -->

package/library/skills/procedural-animation/resource.yaml

@@ -1,7 +1,7 @@
 id: skill/procedural-animation
 kind: skill
 version: 1.0.4
-summary: Runtime bone modification on top of clips — head look-at, foot IK, hand-grabs-prop, additive lean, recoil. Code-and-modifier patterns, not generation.
+summary: "Runtime bone changes on top of clips: head look-at, foot IK, hand grabs a prop, lean, recoil."
 use_when:
   - the user needs runtime-driven bone modification on top of clips — head look-at, foot IK on uneven ground, additive lean, hit recoil, ragdoll
   - the character's feet float above or sink into stairs and slopes (foot placement)

package/library/skills/prop-model/SKILL.md

@@ -1,11 +1,11 @@
 ---
 name: prop-model
-description: "Generate a single static 3D prop — sword, barrel, chest, lantern, throne, statue — one isolated object, no rigging, wired as a MeshInstance3D."
+description: "Generate one static 3D prop (sword, barrel, chest, lantern, statue): one object, no rig, a MeshInstance3D."
 license: MIT
 compatibility: [Cursor, Claude Code, Windsurf, Codex]
 category: 3d-assets
 user-invocable: true
-allowed-tools: Read Grep summer_search_assets summer_list_my_assets summer_get_asset summer_import_asset_by_id summer_generate_3d summer_generate_image summer_import_from_url summer_add_node summer_set_prop summer_inspect_node summer_get_scene_tree summer_save_scene
+allowed-tools: Read Grep summer_assets_search summer_assets_get summer_import_asset_by_id summer_assets_generate_3d summer_assets_generate_image summer_import_from_url summer_add_node summer_set_prop summer_inspect_node summer_get_scene_tree summer_save_scene summer_jobs_wait summer_call
 paths: ["assets/models/**", "**/*.tscn", "**/*.gd"]
 ---
 
@@ -13,7 +13,7 @@ paths: ["assets/models/**", "**/*.tscn", "**/*.gd"]
 
 One prop, one mesh, one MeshInstance3D. Most game-world objects are static props, so this is the most common 3D-asset call. The skill keeps two things tight: the **prompt shape** that produces a clean isolated mesh on the first try, and the **wire-in pattern** that gets the asset into the scene without leaving orphans in `res://assets/models/`.
 
-The backing tool is `summer_generate_3d`. Default model is `hunyuan` (Hunyuan 3D v3.1 Pro — best quality). Use `trellis` when speed matters (Trellis 2 is ~2× faster, slightly lower fidelity). `meshy` is the legacy fallback — only pick it if the user asks by name.
+The backing operation is `assets.generate_3d`; it answers with a job that `jobs.wait` follows. Default model is `hunyuan` (Hunyuan 3D v3.1 Pro — best quality). Use `trellis` when speed matters (Trellis 2 is ~2× faster, slightly lower fidelity). `meshy` is the legacy fallback — only pick it if the user asks by name.
 
 ## When to use
 
@@ -37,7 +37,7 @@ The backing tool is `summer_generate_3d`. Default model is `hunyuan` (Hunyuan 3D
 ### 1. Search before generating
 
 ```
-summer_search_assets(query="<prop name>", assetType="3d_model", source="all")
+assets.search({ query: "<prop name>", assetType: "3d_model", scope: "all" })
 ```
 
 If a fitting model exists, propose reuse:
@@ -48,10 +48,10 @@ If a fitting model exists, propose reuse:
 
 | Use case | Tris | Pass via |
 |---|---|---|
-| Hero prop (sword on hip, key item) | 3k–8k | `options: { target_polycount: 5000 }` |
-| Background prop (crate, barrel, sack) | 200–800 | `options: { target_polycount: 600 }` |
-| Mid-range interactive (chest, lantern) | 1k–3k | `options: { target_polycount: 2000 }` |
-| Cinematic showcase (throne, statue) | 10k–30k | `options: { target_polycount: 20000 }` |
+| Hero prop (sword on hip, key item) | 3k–8k | `targetPolycount: 5000` |
+| Background prop (crate, barrel, sack) | 200–800 | `targetPolycount: 600` |
+| Mid-range interactive (chest, lantern) | 1k–3k | `targetPolycount: 2000` |
+| Cinematic showcase (throne, statue) | 10k–30k | `targetPolycount: 20000` |
 
 Default if you don't pass it: provider picks (~10k–30k). For most game-world props, that's overkill — pass a target.
 
@@ -74,22 +74,24 @@ The `isolated object` and `white background` clauses are load-bearing — withou
 
 > About to generate `viking_axe` via `hunyuan`, target ~5k tris, ~60s. This uses credits. OK?
 
+To say how many credits, run the same call with `dryRun: true` first: it returns `estimate` (`credits`, `balance`, `enough`) and generates nothing.
+
 ```
-summer_generate_3d(
-  prompt="A two-handed viking battle axe, weathered iron head with rune etchings, leather-wrapped wooden haft. Game asset, centered, stylized, white background, isolated object.",
-  model="hunyuan",
-  options={ target_polycount: 5000 },
-  wait=true
-)
+assets.generate_3d({
+  prompt: "A two-handed viking battle axe, weathered iron head with rune etchings, leather-wrapped wooden haft. Game asset, centered, stylized, white background, isolated object.",
+  model: "hunyuan",
+  targetPolycount: 5000
+})
+jobs.wait({ jobId: "<job.id>", timeoutSeconds: 50 })   // again until finished
 ```
 
-Returns a job result with `assetId` and `fileUrl`. Treat `assetId` as the
+The finished job's `result` holds `assetId` and `fileUrl`. Treat `assetId` as the
 stable handle and `fileUrl` as a fallback preview/import URL.
 
 ### 5. Import and wire
 
 ```
-summer_get_asset(assetId="<assetId>")
+assets.get({ assetId: "<assetId>" })
 summer_import_asset_by_id(
   assetId="<assetId>",
   path="res://assets/models/viking_axe.glb",
@@ -111,8 +113,8 @@ the parent-shape pattern.
 
 - **Scene context in the prompt.** "A sword lying on a wooden table" → the table becomes geometry. Always say `isolated object`.
 - **Multi-object prompts.** "A sword and a shield" → fused single mesh. Generate separately.
-- **Skipping `target_polycount` for background props.** A 30k-tri barrel in the background tanks frame rate when the level has 50 of them.
-- **Forgetting to import.** `fileUrl` from `summer_generate_3d` is a remote URL — you MUST `summer_import_asset_by_id` or `summer_import_from_url` before referencing it as `res://...`.
+- **Skipping `targetPolycount` for background props.** A 30k-tri barrel in the background tanks frame rate when the level has 50 of them.
+- **Forgetting to import.** `fileUrl` from `assets.generate_3d` is a remote URL — you MUST `summer_import_asset_by_id` or `summer_import_from_url` before referencing it as `res://...`.
 - **Generating before searching.** Reuse beats regenerate every time.
 - **Picking `meshy` by default.** It's legacy. `hunyuan` is better; `trellis` is faster.
 
@@ -123,6 +125,10 @@ the parent-shape pattern.
 - **Concave interior (open chest, hollow vase).** Specify "lid open" or "hollow inside" — Hunyuan defaults to closed solids.
 - **Symmetrical prop comes back asymmetric.** Add `symmetric, mirrored` to the prompt and regenerate.
 
+## Without Summer Engine
+
+In a session without Summer Engine tools (the assets profile; the `summer-assets` skill has the whole loop), do steps 1-4 and skip step 5 (import and wiring). Save the file where the person asked with `out` (the `summer-assets` skill says how), and tell them the path and format. The file is GLB. Generated models are not at real-world size, so give the person the target size (a chair about 1 m, a door about 2 m) to scale it to.
+
 ## Fallback (no MCP)
 
 The user can run the same prompt in the Summer dashboard or a supported
@@ -144,4 +150,27 @@ After the prop is wired:
 - `asset-strategy` — the meta-router that decides between this skill and Pipeline 2 (textures).
 - `character-model` — for humanoids.
 - `environment-kit` — for style-locked sets.
-- `../../references/mcp-tools-reference/mcp-tools-reference.md` — `summer_generate_3d` parameter schema.
+- `summer_docs_read` id `reference/mcp-tools-reference` — how to call `assets.generate_3d`; `summer_search` returns its exact input.
+
+<!-- shell-commands: generated from the operation catalog by npm run generate:registry; do not edit by hand -->
+## From a shell
+
+No Summer MCP tools in this session? Run each one as a command; when `summer --version` is missing or below 4.0, use `npx -y summer-engine@latest` in place of `summer`. Fields are flags in kebab-case (`--scene-path res://main.tscn`) or one `--input '<json>'`, and `summer ops describe <op>` prints the exact input. The `summer-cli` skill has the rest.
+
+| In this skill | Command |
+|---|---|
+| `assets.generate_3d`, `summer_assets_generate_3d` | `summer assets generate-3d` |
+| `summer_assets_generate_image` | `summer assets generate-image` |
+| `summer_assets_get` | `summer assets get` |
+| `summer_assets_search` | `summer assets search` |
+| `summer_docs_read` | `summer docs read` |
+| `summer_add_node` | `summer engine add-node` |
+| `summer_get_scene_tree` | `summer engine get-scene-tree` |
+| `summer_import_asset_by_id` | `summer engine import-asset-by-id` |
+| `summer_import_from_url` | `summer engine import-from-url` |
+| `summer_inspect_node` | `summer engine inspect-node` |
+| `summer_save_scene` | `summer engine save-scene` |
+| `summer_set_prop` | `summer engine set-prop` |
+| `jobs.wait`, `summer_jobs_wait` | `summer jobs wait` |
+| `summer_search` | `summer ops search "<what you want>"` |
+<!-- /shell-commands -->

package/library/skills/prop-model/resource.yaml

@@ -1,7 +1,7 @@
 id: skill/prop-model
 kind: skill
 version: 1.0.3
-summary: Generate a single static 3D prop — sword, barrel, chest, lantern, throne, statue — one isolated object, no rigging, wired as a MeshInstance3D.
+summary: "Generate one static 3D prop (sword, barrel, chest, lantern, statue): one object, no rig, a MeshInstance3D."
 use_when:
   - generating a single static 3D prop — sword, barrel, chest, lantern, throne, statue, crate, key, potion, banner
   - a scene needs one static object — furniture, weapon, container, decoration — as a MeshInstance3D without rigging

package/library/skills/psx-retro-rendering/resource.yaml

@@ -30,6 +30,7 @@ source: official
 license: MIT
 status: preview
 recommended: false
+bundled: false
 lint_exceptions:
   - url-allowlist
 lint_exception_reason: "Source citation: the body links the MIT-licensed godot-psxlike reference addon on GitHub (wyvernbw) that the extracted article names as its implementation evidence. Read-only provenance link; the skill never fetches or installs it."

package/library/skills/publish-your-game/SKILL.md

@@ -1,11 +1,11 @@
 ---
 name: publish-your-game
-description: "Publish a Summer game on Summer Games through MCP: store page, art, build upload, submit, and one approval link for the owner."
+description: "Publish a game on Summer Games through MCP: store page, art, build upload, submit, owner approval link."
 license: MIT
 compatibility: [Cursor, Claude Code, Windsurf, Codex]
 category: deployment
 user-invocable: true
-allowed-tools: summer_read_library
+allowed-tools: summer_docs_read
 ---
 
 # /publish-your-game — publish your game
@@ -14,12 +14,49 @@ This skill covers the whole publishing journey: find the game, make its store pa
 
 Its current text lives on the hosted Summer Engine MCP, the same text the Studio agent reads, so it changes with the store and is never stale here. Load it before you act:
 
-1. `summer_read_library` with id `skill/publish-your-game` returns the current text when this machine has a store sign-in (`summer login --store`).
+1. `summer_docs_read` with id `skill/publish-your-game` returns the current text when this machine is signed in (`summer login`).
 2. A host that shows MCP prompts or resources has it as the `publish-your-game` prompt and the resource `summer://skills/publish-your-game`.
 3. Without a store sign-in: https://docs.summerengine.com/llms.txt lists every docs page; fetch any page as .md.
 
-Before the build upload, run `release-readiness` on the exact `.zip` you upload, and report each check to the owner; a hosted game's upload checks can pass while every online join fails.
+## The journey in operations
 
-The one rule to keep even before you load it: Submitting does not publish. `summer_store_submit` returns an approval link; only the owner's click sends the game to review, and review comes before live.
+A call written `area.action({...})` is the tool `summer_area_action` when your client lists it, else `summer_call({ op: "area.action", input: {...} })`; `summer_search` finds any operation and its exact input. Engine tools keep their `summer_*` names.
 
-After the review: `summer_store_review` (hosted) returns Summer's decision, the reviewer's feedback and the next step. When Summer asks for changes or does not approve the game, fix every point in the feedback, then call `summer_store_submit` again; the owner approves the resubmission. If there is no written feedback, say so and ask the owner instead of guessing. The game is not live until Summer approves it.
+1. `games.list()` finds the game; `games.create({ title, targets })` makes a new one with its first store page draft. Include `web` in `targets` so it plays in the browser. Keep the `gameId`.
+2. `store.get_listing({ gameId })` reads the page: text per store, art per slot, the publish checklist and the tags a page can pick.
+3. `store.update_listing`, `store.set_art`, `store.set_trailer` and `store.set_sound` fill it until `readyToPublish` is true. Editing never publishes.
+4. Export with `summer_export_game`, run `release-readiness` on the exact `.zip`, and report each check to the owner; a hosted game's upload checks can pass while every online join fails. Then upload it: `store.upload_file({ gameId, clientVersion, confirm: true })` from this machine once the owner approved the exact file and version, or `store.upload_begin` (`kind` bundle, web or download), `store.upload_sign_parts` and `store.upload_complete` with the bytes. Finishing answers a job: `jobs.wait({ jobId })` until Summer's checks are done.
+5. `store.publish({ gameId, price, note, idempotencyKey })` asks the owner; `price` is `{ currency: "USD", amountMinor }` in cents (0 is free), omitted it keeps the current price. It answers `needs_approval` with the owner's link and a job. Give the owner the link; `jobs.wait({ jobId })` returns once they answer.
+6. `store.status({ gameId })` shows Summer's review decision and feedback, every upload, what players get now, and one next step.
+7. A store bundle goes to players with `store.release({ gameId, idempotencyKey })` once Summer approved the game: it releases only the build the owner approved, and answers a job. Web builds and downloads need no release.
+
+The one rule to keep even before you load it: Asking does not publish. `store.publish` returns an approval link; only the owner's click sends the game to review, and review comes before live.
+
+After the review: when `store.status` says `review.needsChanges`, fix every point in `review.feedback`, then call `store.publish` again with a new `idempotencyKey`; the owner approves the resubmission. If there is no written feedback, say so and ask the owner instead of guessing. The game is not live until Summer approves it.
+
+<!-- shell-commands: generated from the operation catalog by npm run generate:registry; do not edit by hand -->
+## From a shell
+
+No Summer MCP tools in this session? Run each one as a command; when `summer --version` is missing or below 4.0, use `npx -y summer-engine@latest` in place of `summer`. Fields are flags in kebab-case (`--scene-path res://main.tscn`) or one `--input '<json>'`, and `summer ops describe <op>` prints the exact input. The `summer-cli` skill has the rest.
+
+| In this skill | Command |
+|---|---|
+| `summer_docs_read` | `summer docs read` |
+| `summer_export_game` | `summer engine export-game` |
+| `games.create` | `summer games create` |
+| `games.list` | `summer games list` |
+| `jobs.wait` | `summer jobs wait` |
+| `summer_search` | `summer ops search "<what you want>"` |
+| `store.get_listing` | `summer store get-listing` |
+| `store.publish` | `summer store publish` |
+| `store.release` | `summer store release` |
+| `store.set_art` | `summer store set-art` |
+| `store.set_sound` | `summer store set-sound` |
+| `store.set_trailer` | `summer store set-trailer` |
+| `store.status` | `summer store status` |
+| `store.update_listing` | `summer store update-listing` |
+| `store.upload_begin` | `summer store upload-begin` |
+| `store.upload_complete` | `summer store upload-complete` |
+| `store.upload_file` | `summer store upload-file` |
+| `store.upload_sign_parts` | `summer store upload-sign-parts` |
+<!-- /shell-commands -->

package/library/skills/publish-your-game/resource.yaml

@@ -1,11 +1,11 @@
 id: skill/publish-your-game
 kind: skill
 version: 1.0.0
-summary: "Publish a Summer game on Summer Games through MCP: store page, art, build upload, submit, and one approval link for the owner."
+summary: "Publish a game on Summer Games through MCP: store page, art, build upload, submit, owner approval link."
 use_when:
   - "the user says 'publish my game', 'put it on summer.games', 'launch it on the store' or 'submit it for review'"
-  - "taking a built Summer game to a submitted store page: listing text, art, build upload, summer_store_submit and the owner's approval link"
-  - "an agent publishes for the owner end to end and needs the order of the summer_store_* and summer_build_* tools"
+  - "taking a built Summer game to a submitted store page: listing text, art, build upload, store.publish and the owner's approval link"
+  - "an agent publishes for the owner end to end and needs the order of the store.* operations"
 do_not_use_when:
   - "only producing a local export build — skill/export-and-ship"
 facets:

package/library/skills/realtime-wet-surfaces/resource.yaml

@@ -28,3 +28,4 @@ source: official
 license: MIT
 status: preview
 recommended: false
+bundled: false

package/library/skills/release-readiness/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: release-readiness
-description: "Before releasing a Summer game version, prove players can play it: server scene, online join, progress, Game ID, released Summer, packed files, app version."
+description: "Before releasing a Summer game version, prove players can play it: server, online join, progress, files."
 license: MIT
 compatibility: [Cursor, Claude Code, Windsurf, Codex]
 category: deployment
@@ -435,3 +435,15 @@ here would have caught:
 - [ ] 9. For an iPhone or Android bundle, `summerVersion` has the current Summer release's MAJOR.MINOR.
 - [ ] 10. A signed-in player played the released version for 3 minutes in each Summer Games app, through an analytics event, without the game closing or being signed out (or it is reported as not run).
 - [ ] One line per check reported to the user before anything is changed.
+
+<!-- shell-commands: generated from the operation catalog by npm run generate:registry; do not edit by hand -->
+## From a shell
+
+No Summer MCP tools in this session? Run each one as a command; when `summer --version` is missing or below 4.0, use `npx -y summer-engine@latest` in place of `summer`. Fields are flags in kebab-case (`--scene-path res://main.tscn`) or one `--input '<json>'`, and `summer ops describe <op>` prints the exact input. The `summer-cli` skill has the rest.
+
+| In this skill | Command |
+|---|---|
+| `summer_export_game` | `summer engine export-game` |
+| `summer_get_diagnostics` | `summer engine get-diagnostics` |
+| `summer_read_file` | `summer engine read-file` |
+<!-- /shell-commands -->

package/library/skills/release-readiness/resource.yaml

@@ -1,7 +1,7 @@
 id: skill/release-readiness
 kind: skill
 version: 1.0.0
-summary: "Before releasing a Summer game version, prove players can play it: server scene, online join, progress, Game ID, released Summer, packed files, app version."
+summary: "Before releasing a Summer game version, prove players can play it: server, online join, progress, files."
 use_when:
   - "before uploading, promoting or releasing a new version to players: is it ready to release"
   - "every online join fails with world_start_timeout, or the hosted server's log is empty, while Local Play works"