scene-scripting is a skill from the Summer skill library: a guide your AI agent reads when the task matches, so it builds the good version on the first try. Build scenes, levels, HUDs and wiring with one editor GDScript (summer_run_script) instead of call chains.
When your agent uses it
- A scene change needs 3+ related ops or any computed placement — scattering, grids, rings, procedural meshes, geometry helpers, terrain, lighting rigs, keyframe animation, shader FX
- A 2D level (tilemap paint, bodies, camera limits, parallax), an animated sprite, a HUD or Control tree, a persisted signal connection, an attached script, a prefab, input actions, an autoload, or the main scene should be built in one script
- An API property/method name must be verified with summer_api_docs before scripting
- A cold project-wide batch job belongs in summer_run_editor_script
Install
summer setup installs every skill for your agent. To add only this one:
claude-code for your agent, such as codex or cursor. See Skills for every option.
The skill
Overview
summer_run_script runs one GDScript inside the live editor, against the scene named by scenePath. When that scene is not the edited one, it is opened first (a request of its own) and the person’s tab comes back after the run; if it cannot be opened, the script does not run. One script replaces a chain of summer_add_node / summer_set_prop calls, and it does what single calls cannot: loops, randomness, math, procedural geometry, reading existing nodes before deciding.
The rule: 3 or more related scene edits, or ANY computed placement → one script. A single property tweak → summer_set_prop. A cold project-wide batch job → summer_run_editor_script (below).
The contract
scenePath— the exactres://scene the script changes (fromsummer_get_project_contextor the scene tree). Always pass it; without it the script runs against whichever tab happens to be open. The result’sscene_targetsays whether the scene was opened and which tab came back.source— just the function: noextends, no@tool(missing ones are added and reported innormalizations).ctx.get_scene_root()— root node of that scene.ctx.set_owner_recursive(node)— stamp a created subtree with the scene-root owner.ctx.report(key, value)— structured results back (reports).print(...)— captured intooutput.- Values are real GDScript:
Vector3(0, 10, 0),Color(1, 0, 0, 1). The quoted variant-string convention ("Vector3(0, 10, 0)") belongs tosummer_set_prop, not to script code. ctxis untyped, so its results are untyped: writevar wall = ctx.add_mesh(...).var wall := ctx.add_mesh(...)does not compile (“Cannot infer the type”).- Saving:
ctx.save_scene()writes the scene (after an ownership audit). Without it the change stays in the editor, unsaved. - Budget:
max_secondsdefault 20, clamp 5–120. The script blocks the editor between frames; on newer engines the budget is a HARD deadline ("Summer script budget exceeded (Ns)",budget_enforced: true). Split the work into smaller scripts — never resubmit the same oversized one. - Transactions: newer engines wrap the run in ONE named undo action (
undo: "action", the default) and roll it back on a mid-script runtime error — the result carriesrolled_back: trueand the scene is untouched.undo: "none"keeps partial mutations. Older engines ignore the param; treat anyerrorsthere as a possible half-applied mutation.
The core ctx API
Creation helpers set the owner for you and return the created node — prefer them overnew() + add_child + set_owner_recursive. Frozen signatures:
props apply via set() per key; unknown keys are collected into a prop_warnings report entry, never silently dropped — read it. On an older engine a missing helper is a plain GDScript error (Invalid call to method 'add_mesh'…): fall back to the manual form, which works everywhere.
Newer engines add three more tiers. Their frozen signatures, conventions and fallbacks are in references/ctx-api.md (read it with summer_docs_read id skill/scene-scripting/references/ctx-api.md):
- Geometry:
boolean,extrude_polygon,lathe,sweep,terrain,set_smooth,decimate,convex_collision,uv_planar/uv_box,mirror,animate,make_shader;add_meshalso takestorusandtext. - Animation:
animate_method,anim_state_machine,bone_pose,look_at_modifier(the full recipe lives incharacter-animation-wiring). - Game completeness (2D, UI, gameplay code):
add_sprite,add_animated_sprite,add_tilemap,paint_tiles/paint_rect,add_body_2d,add_camera_2d,add_parallax,add_ui,add_canvas_layer,set_theme_overrides,connect_signal,attach_script,make_prefab,add_autoload,add_input_action,set_main_scene.
undo: "action", the whole run rolls back. references/ctx-api.md has the table of what works on every engine.
Owner rules
Every node you create must be owned by the scene root, or it silently vanishes when the scene saves. Descendants too — being under an owned node is NOT enough.add_child succeeds, the screenshot even shows it, and the saved .tscn is missing it.
new(), call ctx.set_owner_recursive(node) (or set node.owner = root on the node AND each descendant) AFTER add_child — owner assignment fails on a node not yet in the tree. Re-stamp the owner after any reparent.
The loop
summer_world_snapshot— the structured BEFORE baseline; keep itssnapshot_id.summer_api_docs— verify every property/method name you are not certain of.summer_run_scriptwithscenePath— run the script.- Read
errors,reports,rolled_backandscene_targetin the result —rolled_back: truemeans a runtime error undid everything (fix and re-run); on older engines /undo: "none", an error can leave a partial mutation. summer_snapshot_diff from_id:<the id>— the structural receipt: exactly the nodes you meant to add were added, nothing else changed, nothing vanished (an unowned node dropping on save shows up HERE).summer_screenshot— LOOK at it. Usetarget:"scene" framing:"camera"when the change touched lighting, environment, or emissive materials — the preset framings render a flat substitute environment and cannot show those.- Iterate. Never claim visual success without steps 5–6 (a capture is a fact; describing an unseen frame is fabrication). The full perception discipline lives in
verifying-scenes.
Verify names with summer_api_docs — never guess
Wrong property names fail silently or throw mid-script after half the mutation applied. Before using an unfamiliar class:position lives on Node3D, not MeshInstance3D. Walk inherits upward when a member seems missing.
Two examples
Scatter 40 trees with deterministic randomness:summer_screenshot — lighting is exactly the kind of change you cannot judge without pixels.
More recipes, each the source of one call:
references/recipes-3d.md(skill/scene-scripting/references/recipes-3d.md): procedural meshes, CSG and boolean blockouts, lathe, sweep, terrain, text signage, decimate and convex collision, mirror, keyframe animation,make_shader, GridMap fills.references/recipes-2d-ui.md(skill/scene-scripting/references/recipes-2d-ui.md): a 2D platformer level, animated sprites, a HUD, a persisted button connection,attach_script,make_prefab, input actions, autoloads and the main scene, and how to verify 2D and UI work.
Which tool
summer_run_editor_script — the cold path
A different tool for a different job: it boots a fresh headless child editor against the ON-DISK project, runs oneEditorScript (func _run():), and exits.
- Unsaved live edits are INVISIBLE to it; the live editor may need a file reload to show its output.
- Use for batch/project-wide work: re-saving every scene, sweeping resources, mass fixes, generating
.tresassets. - Budget default 120s, clamp 15–600 — include boot time (30s+ on large projects).
- It confesses
no_rewind_point:truewhen no pre-run checkpoint could be taken — surface that to the user before more destructive work. - No renderer: it can never screenshot. Judge it by artifacts on disk (see
headless-scripting).
summer_run_script answers engine_lacks_op, the engine build predates RunSceneScript (Summer Engine 0.5.66 or newer has it): update Summer Engine, or use summer_run_editor_script for the same work.
Pitfalls
Related skills:
verifying-scenes— the perception discipline: snapshot/diff/screenshot before-and-after, runtime reads, honest claims.headless-scripting— shell-launched engine scripts, imports, exports.scene-composition— what a well-structured scene looks like before you generate one.ui-basics— Control hierarchy, containers, anchors, theme vs inline styling.character-animation-wiring— the animation tier end to end.gdscript-patterns— idioms for the scriptsattach_scriptwrites.verification-before-completion— proving the result before claiming done.
From a shell
No Summer MCP tools in this session? Run each one as a command; whensummer --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.
Files in this skill
Related skills
verifying-scenes: Prove scene work landed: snapshot, diff, screenshots, runtime reads, 3D audits, shot sheets and zooms.headless-scripting: Run a GDScript file against Summer Engine from the shell for what no MCP tool does: navmesh, TileSets.scene-composition: Scene structure: node hierarchy, when to extract sub-scenes, reusable prefabs, instance vs add node.character-animation-wiring: Wire a rigged character end to end: real clips and bones, locomotion states, method tracks, root motion.ui-basics: Build UI: HUDs, menus, health bars, dialogue boxes, Control trees, anchors, containers and themes.gdscript-patterns: GDScript conventions: type hints, signals, exports, onready, lifecycle methods, node paths, naming.sprite-sheet: Generate animated 2D character sprite sheets (walk, attack, idle, death) for AnimatedSprite2D.verification-before-completion: Run verification and read its output before claiming work done, fixed or passing: evidence first.
Source:
library/skills/scene-scripting/SKILL.md, rendered from summer-engine@4.3.0 on npm.
