summer-engine 3.8.0 → 4.2.0

package/library/skills/debugging-game-feel/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: debugging-game-feel
-description: "Debug features that work but feel wrong — floaty jumps, mushy combat, sluggish camera — subjective bugs living in tuning, timing, and feedback layers."
+description: "Debug features that work but feel wrong: floaty jumps, mushy combat, sluggish camera."
 ---
 
 # Debugging Game Feel
@@ -189,3 +189,15 @@ After diagnosis pins down which variable(s) are wrong, the tuning is done — bu
 - `investigating-bugs` — for logical bugs with concrete repros, not feel.
 - `playtesting-a-feature` — the playtest discipline this skill plugs into.
 - `debug` — when the feel investigation surfaces an actual 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_batch` | `summer engine batch` |
+| `summer_inspect_node` | `summer engine inspect-node` |
+| `summer_play` | `summer engine play` |
+<!-- /shell-commands -->

package/library/skills/debugging-game-feel/resource.yaml

@@ -1,7 +1,7 @@
 id: skill/debugging-game-feel
 kind: skill
 version: 1.0.3
-summary: Debug features that work but feel wrong — floaty jumps, mushy combat, sluggish camera — subjective bugs living in tuning, timing, and feedback layers.
+summary: "Debug features that work but feel wrong: floaty jumps, mushy combat, sluggish camera."
 use_when:
   - a gameplay feature works correctly but feels wrong — floaty jumps, mushy combat, sluggish camera, weightless impacts
   - tuning jump height, gravity, camera lag, hit-stop, or impact feedback until controls feel right

package/library/skills/design-level/SKILL.md

@@ -1,11 +1,11 @@
 ---
 name: design-level
-description: "Design a single level — layout, pacing, encounters, secrets, reward gating — outputs a level design doc and a node-tree skeleton for summer_create_scene."
+description: "Design one level (layout, pacing, encounters, secrets) as a design doc plus a node-tree skeleton."
 license: MIT
 compatibility: [Cursor, Claude Code, Windsurf, Codex]
 category: level-design
 user-invocable: true
-allowed-tools: Read Grep Glob Write Edit summer_get_scene_tree summer_create_scene summer_open_scene summer_add_node summer_set_prop summer_save_scene summer_get_script_errors
+allowed-tools: Read Grep Glob Write Edit summer_get_scene_tree summer_create_scene summer_open_scene summer_run_script summer_add_node summer_set_prop summer_save_scene summer_get_script_errors
 paths: ["**/*.tscn", "**/*.gd", ".summer/**", "levels/**"]
 ---
 
@@ -148,44 +148,32 @@ Show the skeleton. Ask:
 
 ### 8. Scaffold via MCP
 
-**Preferred (Summer MCP):**
+**Preferred (Summer MCP):** create the scene, then build the whole skeleton in one script.
 
-`summer_create_scene` takes `path`, `rootName`, and a mandatory safety gate.
-There is no `root_type` or `root_name` argument. The tool refuses to run unless
-`allow_temporary_scene_mutation` is explicitly true, because of how it works: it
-opens the currently-open scene (or the project's main scene) as a template,
-removes every child, renames the root, saves-as to the new path, then reopens
-the original. Ask the user before setting the flag.
-
-The consequence to plan around: **the new scene's root node type is copied from
-the template's root**, not chosen by you. Create levels from a scene whose root
-is already `Node3D`, or fix the root afterwards in the editor.
+`summer_create_scene` takes `path`, `rootName` and `rootType` (default `Node3D`) and writes the new scene to disk without opening it. `summer_run_script` with that `scenePath` opens it, runs, and gives the user their tab back; the run is one undo step, so one Ctrl+Z removes the skeleton.
 
 ```
-summer_create_scene(path="res://levels/level_01.tscn", rootName="World", allow_temporary_scene_mutation=true)
-summer_add_node(scenePath="res://levels/level_01.tscn", parent="./World", type="Node3D", name="Geometry")
-summer_add_node(parent="./World/Geometry", type="Node3D", name="IntroAtrium")
-summer_add_node(parent="./World/Geometry", type="Node3D", name="Corridor")
-summer_add_node(parent="./World/Geometry", type="Node3D", name="PeakArena")
-summer_add_node(parent="./World/Geometry", type="Node3D", name="BossChamber")
-summer_add_node(parent="./World", type="Node3D", name="Spawns")
-summer_add_node(parent="./World/Spawns", type="Node3D", name="PlayerSpawn")
-summer_add_node(parent="./World/Spawns", type="Node3D", name="E1_Spawn")
-# ... and so on
-summer_add_node(parent="./World", type="Node3D", name="Triggers")
-summer_add_node(parent="./World/Triggers", type="Area3D", name="E2_GateTrigger")
-# ... etc.
-summer_add_node(parent="./World", type="Node3D", name="Lighting")
-summer_add_node(parent="./World/Lighting", type="WorldEnvironment", name="WorldEnvironment")
-summer_add_node(parent="./World/Lighting", type="DirectionalLight3D", name="Sun")
-summer_save_scene(scenePath="res://levels/level_01.tscn")
+summer_create_scene(path="res://levels/level_01.tscn", rootName="World", rootType="Node3D")
+summer_run_script(scenePath="res://levels/level_01.tscn", source="""
+func run(ctx):
+    var skeleton = {
+        "Geometry": [["Node3D", "IntroAtrium"], ["Node3D", "Corridor"], ["Node3D", "PeakArena"], ["Node3D", "BossChamber"]],
+        "Spawns": [["Node3D", "PlayerSpawn"], ["Node3D", "E1_Spawn"], ["Node3D", "E2_Spawn"], ["Node3D", "E3_Wave_Spawns"], ["Node3D", "MiniBoss_Spawn"]],
+        "Triggers": [["Area3D", "E2_GateTrigger"], ["Area3D", "PeakWaveTrigger"], ["Area3D", "BossDoorTrigger"]],
+        "Pickups": [["Node3D", "HealAfterE2"], ["Node3D", "CurrencyS1"]],
+        "Secrets": [["StaticBody3D", "S1_BreakableWall"], ["StaticBody3D", "S2_ParryLedge"], ["StaticBody3D", "S3_LockedDoor"]],
+        "Lighting": [["WorldEnvironment", "WorldEnvironment"], ["DirectionalLight3D", "Sun"]],
+    }
+    for group in skeleton:
+        var parent = ctx.add_node("Node3D", group)
+        for child in skeleton[group]:
+            ctx.add_node(child[0], child[1], parent)
+    ctx.report("skeleton", ctx.summary())
+    ctx.save_scene()
+""")
 ```
 
-Every `summer_add_node` above takes the same required
-`scenePath="res://levels/level_01.tscn"`; it is elided after the first line only
-to keep the tree readable. A call without `scenePath` is rejected by the tool
-schema. Better still, send the whole block as one `summer_batch(scenePath=...,
-ops=[...])` so the user can undo the skeleton with a single Ctrl+Z.
+Compare the `skeleton` report (node counts by class) with the tree you showed the user, then `summer_get_scene_tree` on the new scene.
 
 This is a **skeleton, not playable geometry**. Markers and Area3Ds, no meshes, no enemy scripts. Implementation in subsequent sessions / templates.
 
@@ -278,3 +266,20 @@ The skeleton this skill produces is meant to be filled in via `/design-mechanic`
 - `design-npc` — designs the enemies the encounters reference
 - `3d-lighting` — sets the lighting in `WorldEnvironment` + lights
 - `art-direction` — defines the visual style the level expresses
+
+<!-- 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_create_scene` | `summer engine create-scene` |
+| `summer_get_scene_tree` | `summer engine get-scene-tree` |
+| `summer_get_script_errors` | `summer engine get-script-errors` |
+| `summer_open_scene` | `summer engine open-scene` |
+| `summer_run_script` | `summer engine run-script` |
+| `summer_save_scene` | `summer engine save-scene` |
+| `summer_set_prop` | `summer engine set-prop` |
+<!-- /shell-commands -->

package/library/skills/design-level/resource.yaml

@@ -1,7 +1,7 @@
 id: skill/design-level
 kind: skill
 version: 1.0.3
-summary: Design a single level — layout, pacing, encounters, secrets, reward gating — outputs a level design doc and a node-tree skeleton for summer_create_scene.
+summary: "Design one level (layout, pacing, encounters, secrets) as a design doc plus a node-tree skeleton."
 use_when:
   - designing a single level — layout, pacing, encounters, secrets, reward gating
   - turning a level idea into a layout with a critical path, encounters, secrets, and pacing beats

package/library/skills/design-mechanic/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: design-mechanic
-description: "Design one game mechanic in detail — input, response, feedback, failure modes, depth, tunables — outputs a design doc, node-graph sketch, GDScript stub."
+description: "Design one mechanic in detail (input, feedback, failure modes, tunables) as a doc plus a script stub."
 license: MIT
 compatibility: [Cursor, Claude Code, Windsurf, Codex]
 category: gameplay-mechanics
@@ -271,3 +271,20 @@ This skill is a workflow that designs and scaffolds — the templates are runnab
 - `fps-controller` — FPS movement scaffolding
 - `gdscript-patterns` — state machines and other script patterns for complex mechanics
 - `audio-direction` — defines the SFX vocabulary the mechanic draws from
+
+<!-- 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_diagnostics` | `summer engine get-diagnostics` |
+| `summer_get_scene_tree` | `summer engine get-scene-tree` |
+| `summer_get_script_errors` | `summer engine get-script-errors` |
+| `summer_input_map_bind` | `summer engine input-map-bind` |
+| `summer_inspect_node` | `summer engine inspect-node` |
+| `summer_save_scene` | `summer engine save-scene` |
+| `summer_set_prop` | `summer engine set-prop` |
+<!-- /shell-commands -->

package/library/skills/design-mechanic/resource.yaml

@@ -1,7 +1,7 @@
 id: skill/design-mechanic
 kind: skill
 version: 1.0.2
-summary: Design one game mechanic in detail — input, response, feedback, failure modes, depth, tunables — outputs a design doc, node-graph sketch, GDScript stub.
+summary: "Design one mechanic in detail (input, feedback, failure modes, tunables) as a doc plus a script stub."
 use_when:
   - designing one specific game mechanic in detail — input, response, feedback, failure modes, depth, tunables
   - add a grappling hook, dash, double jump, wall run, or parry

package/library/skills/design-npc/SKILL.md

@@ -1,11 +1,11 @@
 ---
 name: design-npc
-description: "Design enemy/NPC/boss/companion behavior — perception, personality, intent, action state machine, telegraphs — outputs a GDScript stub plus node tree."
+description: "Design enemy, NPC, boss or companion behavior: perception, state machine, telegraphs, script stub."
 license: MIT
 compatibility: [Cursor, Claude Code, Windsurf, Codex]
 category: ai-and-npcs
 user-invocable: true
-allowed-tools: Read Grep Edit Write summer_get_scene_tree summer_inspect_node summer_add_node summer_set_prop summer_set_resource_property summer_connect_signal summer_save_scene summer_get_script_errors summer_input_map_bind
+allowed-tools: Read Grep Edit Write summer_get_scene_tree summer_inspect_node summer_run_script summer_add_node summer_set_prop summer_set_resource_property summer_connect_signal summer_save_scene summer_get_script_errors summer_input_map_bind
 paths: ["**/*.gd", "**/*.tscn"]
 ---
 
@@ -179,31 +179,31 @@ Identify where the NPC will live (an `Enemies` parent, or directly under World).
 
 **Preferred (Summer MCP):**
 
-Every tool below takes a required `scenePath` naming the exact `res://` scene;
-it is written out on the first line and elided after for readability. Better
-still, send the whole block as one `summer_batch(scenePath=..., ops=[...])` so
-the user can undo the enemy with a single Ctrl+Z.
+One script builds the whole enemy; `scenePath` names the exact `res://` scene,
+and the run is one undo step, so one Ctrl+Z removes the enemy:
 
 ```
-summer_add_node(scenePath="res://main.tscn", parent="./World/Enemies", type="CharacterBody3D", name="Enemy")
-summer_add_node(parent="./World/Enemies/Enemy", type="CollisionShape3D", name="Body")
-summer_add_node(parent="./World/Enemies/Enemy", type="MeshInstance3D", name="Mesh")
-summer_add_node(parent="./World/Enemies/Enemy", type="Area3D", name="Vision")
-summer_add_node(parent="./World/Enemies/Enemy/Vision", type="CollisionShape3D", name="VisionShape")
-summer_add_node(parent="./World/Enemies/Enemy", type="RayCast3D", name="Sight")
-summer_set_prop(path="./World/Enemies/Enemy/Sight", key="enabled", value="true")
-summer_set_prop(path="./World/Enemies/Enemy/Sight", key="target_position", value="Vector3(0, 0, -12)")
+summer_run_script(scenePath="res://main.tscn", source="""
+func run(ctx):
+    var enemy = ctx.add_node("CharacterBody3D", "Enemy", ctx.find("Enemies"))
+    ctx.add_node("CollisionShape3D", "Body", enemy, {"shape": CapsuleShape3D.new()})
+    ctx.add_node("MeshInstance3D", "Mesh", enemy, {"mesh": CapsuleMesh.new()})
+    var vision = ctx.add_node("Area3D", "Vision", enemy)
+    var sight_sphere = SphereShape3D.new()
+    sight_sphere.radius = 12.0
+    ctx.add_node("CollisionShape3D", "VisionShape", vision, {"shape": sight_sphere})
+    ctx.add_node("RayCast3D", "Sight", enemy, {"enabled": true, "target_position": Vector3(0, 0, -12)})
+    ctx.save_scene()
+""")
 ```
 
-Give the Vision area its sphere. Either form works — a class-name string embeds
-the resource in the scene, a `res://` path reuses a shared one. Prefer the shared
-`.tres` when several enemy archetypes want the same sight radius:
+The script embeds the sight sphere in the scene. When several enemy archetypes
+want the same sight radius, share one file instead:
+`{"shape": load("res://shapes/vision_sphere.tres")}`. Tuning one value later is
+one call:
 
 ```
-summer_set_prop(scenePath="res://main.tscn", path="./World/Enemies/Enemy/Vision/VisionShape", key="shape", value="res://shapes/vision_sphere.tres")
-# or, embedded, then tune it:
-summer_set_prop(scenePath="res://main.tscn", path="./World/Enemies/Enemy/Vision/VisionShape", key="shape", value="SphereShape3D")
-summer_set_resource_property(scenePath="res://main.tscn", nodePath="./World/Enemies/Enemy/Vision/VisionShape", resourceProperty="shape", subProperty="radius", value="12.0")
+summer_set_resource_property(scenePath="res://main.tscn", nodePath="./World/Enemies/Enemy/Vision/VisionShape", resourceProperty="shape", subProperty="radius", value="14.0")
 ```
 
 `summer_set_resource_property` works against scene-embedded (`[sub_resource]`)
@@ -224,9 +224,7 @@ summer_connect_signal(scenePath="res://main.tscn", emitter="./World/Enemies/Enem
 ```
 
 The parameters are `scenePath`, `emitter`, `signal`, `receiver`, `method`. There
-is no `from` / `to`; those spellings fail schema validation. The same required
-`scenePath` applies to `summer_add_node`, `summer_set_prop` and
-`summer_save_scene` in the block above.
+is no `from` / `to`; those spellings fail schema validation.
 
 **Fallback (no MCP):** write the scene as `.tscn` text. Ask the user to paste their existing scene first, then propose a unified diff.
 
@@ -500,3 +498,24 @@ For an animated NPC in a runnable project: `summer create 3d-fps-simple-animated
 - `vfx-dissolve` — death dissolve recipe
 - `game-feel` — screen-feel discipline (camera shake, hit-stop)
 - `gdscript-patterns` — generic state machine and script patterns
+
+<!-- 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_connect_signal` | `summer engine connect-signal` |
+| `summer_get_scene_tree` | `summer engine get-scene-tree` |
+| `summer_get_script_errors` | `summer engine get-script-errors` |
+| `summer_input_map_bind` | `summer engine input-map-bind` |
+| `summer_inspect_node` | `summer engine inspect-node` |
+| `summer_play` | `summer engine play` |
+| `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` |
+| `summer_stop` | `summer engine stop` |
+<!-- /shell-commands -->

package/library/skills/design-npc/resource.yaml

@@ -1,7 +1,7 @@
 id: skill/design-npc
 kind: skill
 version: 1.0.2
-summary: Design enemy/NPC/boss/companion behavior — perception, personality, intent, action state machine, telegraphs — outputs a GDScript stub plus node tree.
+summary: "Design enemy, NPC, boss or companion behavior: perception, state machine, telegraphs, script stub."
 use_when:
   - designing an enemy, NPC, boss, companion, civilian, or wave-spawned mob's behavior — perception, intent, state machine, telegraphs, defeat handling
   - enemies that patrol, chase, attack, or flee when they see the player (line of sight)

package/library/skills/diagnosing-perf-regressions/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: diagnosing-perf-regressions
-description: "Find why frame rate, frame time, or load time got worse since a known-good state — regression hunting, not general performance tuning."
+description: "Find why frame rate, frame time or load time got worse since a known-good state."
 ---
 
 # Diagnosing Performance Regressions
@@ -208,3 +208,15 @@ If the MCP tools report the engine isn't running:
 - `investigating-bugs` — when the slow path turns out to be a logic bug (errors in a tight loop).
 - `debug` — when the perf issue is actually a crash or freeze.
 - `verification-before-completion` — to claim the fix worked, with numbers.
+
+<!-- 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_get_diagnostics` | `summer engine get-diagnostics` |
+| `summer_get_scene_tree` | `summer engine get-scene-tree` |
+<!-- /shell-commands -->

package/library/skills/diagnosing-perf-regressions/resource.yaml

@@ -1,7 +1,7 @@
 id: skill/diagnosing-perf-regressions
 kind: skill
 version: 1.0.3
-summary: Find why frame rate, frame time, or load time got worse since a known-good state — regression hunting, not general performance tuning.
+summary: "Find why frame rate, frame time or load time got worse since a known-good state."
 use_when:
   - frame rate, frame time, or load time has gotten worse since a known-good state — 'it used to run at 60, now it's at 30'
   - bisecting recent scene, script, or asset changes to find which one slowed frame time or loading

package/library/skills/driving-the-editor-ui/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: driving-the-editor-ui
-description: "Drive the editor UI by name: invoke actions, clear blocking dialogs, switch the main screen, read a dock — and route scene work to the scene tools instead."
+description: "Drive the editor UI by name: run actions, clear blocking dialogs, switch screens, read a dock."
 ---
 
 # Driving the Editor UI
@@ -83,3 +83,26 @@ The engine refuses, with `denied_action`, anything that ends or replaces the ses
 | `no_renderer` | headless editor, no pixels | `summer_ui_tree`; pixels need a display |
 
 **Related skills:** `scene-scripting` and `verifying-scenes` own the scene loop this skill deliberately stays out of; `verification-before-completion` carries the done-claiming rules; `headless-scripting` is the route when there is no editor UI at all.
+
+<!-- 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_get_scene_tree` | `summer engine get-scene-tree` |
+| `summer_ui_actions` | `summer engine list-ui-actions`, `summer engine invoke-ui-action` |
+| `summer_open_scene` | `summer engine open-scene` |
+| `summer_project_setting` | `summer engine project-setting` |
+| `summer_run_script` | `summer engine run-script` |
+| `summer_save_scene` | `summer engine save-scene` |
+| `summer_screenshot` | `summer engine screenshot` |
+| `summer_select_node` | `summer engine select-node` |
+| `summer_set_prop` | `summer engine set-prop` |
+| `summer_snapshot_diff` | `summer engine snapshot-diff` |
+| `summer_ui_activate` | `summer engine ui-activate` |
+| `summer_ui_screenshot` | `summer engine ui-screenshot` |
+| `summer_ui_tree` | `summer engine ui-tree` |
+| `summer_world_snapshot` | `summer engine world-snapshot` |
+<!-- /shell-commands -->

package/library/skills/driving-the-editor-ui/resource.yaml

@@ -1,7 +1,7 @@
 id: skill/driving-the-editor-ui
 kind: skill
 version: 1.0.0
-summary: "Drive the editor UI by name: invoke actions, clear blocking dialogs, switch the main screen, read a dock — and route scene work to the scene tools instead."
+summary: "Drive the editor UI by name: run actions, clear blocking dialogs, switch screens, read a dock."
 use_when:
   - an editor-workflow step a human would do with the mouse — open the Import dock, switch the 2D/3D/Script main screen, toggle a bottom panel, open an editor dialog by name
   - a dialog or popup is blocking the editor and tool calls come back modal_open — see it (summer_ui_tree root dialogs) and clear it (summer_ui_activate action dismiss_dialog)

package/library/skills/environment-kit/SKILL.md

@@ -1,11 +1,11 @@
 ---
 name: environment-kit
-description: "Generate a modular environment kit — wall pieces, floor tiles, pillars, doors, arches, corners — snap-together meshes sharing one visual style."
+description: "Generate a modular environment kit: walls, floor tiles, pillars, doors, arches in one visual style."
 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/kits/**", "assets/models/**", "**/*.tscn", "**/*.gd"]
 ---
 
@@ -13,7 +13,7 @@ paths: ["assets/kits/**", "assets/models/**", "**/*.tscn", "**/*.gd"]
 
 A kit is a *family* of meshes — wall, floor, door, pillar, corner, arch — that the level designer snaps together to build interiors and exteriors. The skill exists to solve **one specific failure mode**: generating each piece with a fresh prompt produces six pieces that look like they came from six different games. The fix is the **style anchor pattern** — generate one piece first, lock its prompt suffix, and reuse that exact suffix for every subsequent piece.
 
-The backing tool is `summer_generate_3d`, called once per piece. A 6-piece kit is six generations and about 5 minutes. Generation uses credits, so confirm scope before starting.
+The backing operation is `assets.generate_3d`, called once per piece; each call answers with a job that `jobs.wait` follows. A 6-piece kit is six generations and about 5 minutes. Generation uses credits, so confirm scope before starting (`dryRun: true` on one piece's call gives its credits).
 
 ## When to use
 
@@ -63,7 +63,7 @@ Kit pieces only feel modular if they snap to a fixed grid. Pick the grid before
 | **2m** | Standard interiors (homes, taverns, offices) | Wall = 2×3×0.3m. Floor = 2×2m. Halves piece count. |
 | **4m** | Exteriors and large halls (temples, warehouses, throne rooms) | Wall = 4×4×0.4m. Floor = 4×4m. Quarter the piece count for the same area. |
 
-**Critical:** include the dimensions in the prompt. `summer_generate_3d` doesn't enforce them, but Hunyuan respects scale cues — `2 meter tall wall section` produces a mesh that imports near 2m tall. Then verify with `summer_inspect_resource` and scale-correct in the editor if needed.
+**Critical:** include the dimensions in the prompt. `assets.generate_3d` doesn't enforce them, but Hunyuan respects scale cues — `2 meter tall wall section` produces a mesh that imports near 2m tall. Then verify with `summer_inspect_resource` and scale-correct in the editor if needed.
 
 ## Steps
 
@@ -76,13 +76,13 @@ Kit pieces only feel modular if they snap to a fixed grid. Pick the grid before
 Use the prop-style prompt with explicit dimensions:
 
 ```
-summer_generate_3d(
-  prompt="A 2 meter wide by 3 meter tall stone dungeon wall section, mossy granite blocks with iron reinforcements, torch-bracket sconce, weathered surface. Game asset, centered, stylized low-poly game art, warm torchlight palette, white background, isolated object.",
-  model="hunyuan",
-  options={ target_polycount: 1500 },
-  wait=true
-)
-summer_get_asset(assetId="<assetId>")
+assets.generate_3d({
+  prompt: "A 2 meter wide by 3 meter tall stone dungeon wall section, mossy granite blocks with iron reinforcements, torch-bracket sconce, weathered surface. Game asset, centered, stylized low-poly game art, warm torchlight palette, white background, isolated object.",
+  model: "hunyuan",
+  targetPolycount: 1500
+})
+jobs.wait({ jobId: "<job.id>", timeoutSeconds: 50 })   // again until finished; result.assetId
+assets.get({ assetId: "<assetId>" })
 summer_import_asset_by_id(assetId="<assetId>", path="res://assets/kits/dungeon/wall.glb")
 ```
 
@@ -90,19 +90,19 @@ Show the result to the user. **Iterate the anchor until approved** — every oth
 
 ### 3. Lock the suffix and generate the remaining pieces
 
-Once the user says "yes, that's the look", store the locked suffix and crank through the rest. Same model, same polycount, same `options`. Only the object description changes.
+Once the user says "yes, that's the look", store the locked suffix and crank through the rest. Same model, same `targetPolycount` scale. Only the object description changes. Start every piece first, then wait on the jobs: they run side by side.
 
 ```
 # Floor
-summer_generate_3d(prompt="A 2 by 2 meter square stone dungeon floor tile, mossy granite blocks with iron reinforcements, weathered surface. Game asset, centered, stylized low-poly game art, warm torchlight palette, white background, isolated object.", model="hunyuan", options={ target_polycount: 800 })
+assets.generate_3d({ prompt: "A 2 by 2 meter square stone dungeon floor tile, mossy granite blocks with iron reinforcements, weathered surface. Game asset, centered, stylized low-poly game art, warm torchlight palette, white background, isolated object.", model: "hunyuan", targetPolycount: 800 })
 
 # Pillar
-summer_generate_3d(prompt="A 3 meter tall stone dungeon pillar, square base, fluted shaft, mossy granite blocks with iron reinforcements, weathered surface. Game asset, ...", model="hunyuan", options={ target_polycount: 1500 })
+assets.generate_3d({ prompt: "A 3 meter tall stone dungeon pillar, square base, fluted shaft, mossy granite blocks with iron reinforcements, weathered surface. Game asset, ...", model: "hunyuan", targetPolycount: 1500 })
 
-# Door, Corner, Arch — same pattern.
+# Door, Corner, Arch — same pattern. Then jobs.wait on each job id.
 ```
 
-For each completed generation, capture the returned `assetId`, then import that
+For each finished job, capture the returned `assetId`, then import that
 exact ID with `summer_import_asset_by_id`. Do not search for generated pieces by
 name after creating them; exact IDs are the production path.
 
@@ -149,6 +149,10 @@ Check the AABB. If the wall is 1.85m tall when you asked for 3m, scale it in the
 - **Sci-fi kit (corridors, doors, terminals).** The style suffix becomes critical — `clean panels, soft cyan emissive trim, brushed metal, white background, isolated object`. Hard surfaces drift more than organic ones; review every piece.
 - **The user wants to add a piece later.** The locked suffix lives in the kit's notes (drop it in `assets/kits/dungeon/STYLE.md` if the user wants persistence). Reuse it verbatim for any addition — never re-derive.
 
+## Without Summer Engine
+
+In a session without Summer Engine tools (the assets profile; the `summer-assets` skill has the whole loop), do steps 1-3 and skip steps 4-5 (staging in a kit scene). Save the file where the person asked with `out` (the `summer-assets` skill says how), and tell them the path and format. Tell the person the grid from step 1, so they can check scale and pivots in their own engine.
+
 ## Fallback (no MCP)
 
 1. Run each prompt at the Summer dashboard (or Hunyuan / Trellis web UIs), keeping the locked suffix.
@@ -173,3 +177,26 @@ After the kit is staged:
 - `asset-strategy` — Pipeline 2 (textures + CSG) is the cheaper alternative when pieces are flat.
 - `scene-composition` — how to organize the kit scene and the level scenes that consume it.
 - `3d-lighting` — interior kit pieces typically need warm point lights at sconce positions.
+
+<!-- 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_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_inspect_resource` | `summer engine inspect-resource` |
+| `summer_instantiate_scene` | `summer engine instantiate-scene` |
+| `summer_save_scene` | `summer engine save-scene` |
+| `summer_set_prop` | `summer engine set-prop` |
+| `jobs.wait`, `summer_jobs_wait` | `summer jobs wait` |
+<!-- /shell-commands -->

package/library/skills/environment-kit/resource.yaml

@@ -1,7 +1,7 @@
 id: skill/environment-kit
 kind: skill
 version: 1.0.3
-summary: Generate a modular environment kit — wall pieces, floor tiles, pillars, doors, arches, corners — snap-together meshes sharing one visual style.
+summary: "Generate a modular environment kit: walls, floor tiles, pillars, doors, arches in one visual style."
 use_when:
   - generating a modular environment kit of snap-together pieces that form a level — dungeon kit, modular walls, interior pieces
   - building a dungeon, interior, or town kit from repeatable pieces that snap together in one style

package/library/skills/export-and-ship/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: export-and-ship
-description: "Assess and prepare a game export: inventory installed templates and targets, validate release assets and config, produce supported builds after approval."
+description: "Prepare a game export: check templates and targets, validate release assets, build after approval."
 license: MIT
 compatibility: [Cursor, Claude Code, Windsurf, Codex]
 category: deployment
@@ -295,7 +295,7 @@ For each build:
 
 Per platform, point the user at the correct upload path:
 
-- **summer.games:** `summer_export_game` writes the summer.games `.zip`; `summer_publish_build` uploads it to the game's store listing after the user confirms the exact game, file and version (needs `summer login --store`). If it answers `store_auth_refused`, the user uploads the `.zip` in Studio instead.
+- **summer.games:** `summer_export_game` writes the summer.games `.zip`; `store.upload_file` uploads it to the game's store listing after the user confirms the exact game, file and version (needs `summer login --store`; through `summer_call` when your client does not list it). If the store refuses this machine's sign-in, the user uploads the `.zip` in Studio instead. The `publish-your-game` skill takes it from there to `store.publish`.
   - Per platform, the store takes: iPhone, Android, macOS and Windows in the Summer apps = one summer.games bundle (`summer_export_game` `targets`, format `bundle`; no template, no signing; a game without a server targets `ios`/`android` only). Web = an HTML5 `.zip` on Summer's WebGPU Forward+ template (`targets:["web"]`; the project must render with Forward+ or Mobile). A macOS or Windows download for the store page = `targets:["macos"]` or `["windows"]` with format `download`. Download exports need the template: `summer_export_templates` `install` fetches it from Summer's CDN.
   - Hosted games: if `summer_export_game` fails with "… is in the source graph's authority_engine domain, which the client pack leaves out", an authority root in `source-domains.json` holds a file the client loads (often the composition `.tres`). Narrow that root to the server-only files, or move the shared file under a `shared` path, then export again. Every exporter message is in the `multiplayer-publish` skill's export-errors.md; the folder rules are in `multiplayer-project`.
   - Every summer.games bundle: export with the released Summer editor from the download page, never a development build, and export again after updating Summer. Otherwise its scripts can fail to compile on players' devices and the game opens to an empty window, though every upload check passes. `release-readiness` check 7 proves it.
@@ -358,7 +358,7 @@ Use this as a one-shot grep before any export:
 
 ## Collaborative protocol
 
-This skill produces release artifacts. Always ask before each build is invoked. Group platforms — "I'm about to build Windows + Mac + Linux release configs into `build/`. OK?". See `../../references/collaborative-protocol/collaborative-protocol.md`.
+This skill produces release artifacts. Always ask before each build is invoked. Group platforms — "I'm about to build Windows + Mac + Linux release configs into `build/`. OK?". See `summer_docs_read` id `reference/collaborative-protocol`.
 
 ## Want a working starter?
 
@@ -366,9 +366,32 @@ No template — this is a workflow. Each project's export config and store asset
 
 ## See also
 
-- `../../references/mcp-tools-reference/mcp-tools-reference.md` — full MCP tool list
-- `../../references/godot-version/godot-version.md` — Summer compatibility and
+- `summer_docs_read` id `reference/mcp-tools-reference` — full MCP tool list
+- `summer_docs_read` id `reference/godot-version` — Summer compatibility and
   export-template versioning
-- `../../references/collaborative-protocol/collaborative-protocol.md` — "May I write" pattern
+- `summer_docs_read` id `reference/collaborative-protocol` — "May I write" pattern
 - `headless-scripting` — the headless CLI pattern the export command follows
 - `tune-performance` — pre-ship performance pass
+
+<!-- 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_capture_gameplay` | `summer engine capture-gameplay` |
+| `summer_export_game` | `summer engine export-game` |
+| `summer_export_templates` | `summer engine export-templates` |
+| `summer_get_console` | `summer engine get-console` |
+| `summer_get_diagnostics` | `summer engine get-diagnostics` |
+| `summer_get_project_context` | `summer engine get-project-context` |
+| `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_project_setting` | `summer engine project-setting` |
+| `summer_screenshot` | `summer engine screenshot` |
+| `store.publish` | `summer store publish` |
+| `store.upload_file` | `summer store upload-file` |
+<!-- /shell-commands -->

package/library/skills/export-and-ship/resource.yaml

@@ -1,7 +1,7 @@
 id: skill/export-and-ship
 kind: skill
 version: 1.0.3
-summary: "Assess and prepare a game export: inventory installed templates and targets, validate release assets and config, produce supported builds after approval."
+summary: "Prepare a game export: check templates and targets, validate release assets, build after approval."
 use_when:
   - the user wants to assess or prepare a Summer game export — Steam, itch, HTML5, iOS, Android targets as available in the installed build
   - the user says 'publish my game', 'release it', or 'ship a build to players' — produce the build they will upload