summer-engine 2.8.1 → 3.0.0

package/library/skills/play/resource.yaml

@@ -0,0 +1,26 @@
+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.
+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
+facets:
+  lifecycle:
+    - build
+  domains:
+    - scenes
+    - project
+  modalities:
+    - project
+compatibility:
+  engine: ">=4.6"
+related:
+  skills:
+    - skill/debug
+source: official
+license: MIT
+status: stable
+recommended: true
+aliases:
+  - skills/scene-and-project/play

package/{skills/workflow → library/skills}/playtesting-a-feature/SKILL.md

@@ -13,9 +13,9 @@ A game feature is not done because it compiles. It is not done because the tests
 
 This skill governs the play-the-game layer of verification. It does not replace:
 
-- `summer:verification-before-completion` — type checks, build output, test runs. Run that for the code layer.
-- `summer:debug` — operational triage when a feature is actively broken or crashing.
-- `summer:investigating-bugs` — root-cause analysis once a specific bug is reproducible.
+- `verification-before-completion` — type checks, build output, test runs. Run that for the code layer.
+- `debug` — operational triage when a feature is actively broken or crashing.
+- `investigating-bugs` — root-cause analysis once a specific bug is reproducible.
 
 Use those skills first if they apply. This skill runs **after** code-level verification, **before** telling the user the feature is done.
 
@@ -33,6 +33,8 @@ If you have not, in this session, driven the feature and read back what happened
 
 **You walk the feature. Not the user.** A `RunVerification` probe presses your game's real inputs, reads state back across frames, and saves real rendered frames. Handing the walkthrough to the user is a last resort for things a probe genuinely cannot judge — see [What only a human can answer](#what-only-a-human-can-answer) — not the default.
 
+On an engine build with the runtime-control ops (`summer_game_probe`, `summer_game_input`, `summer_game_control`, `summer_runtime_*`), drive the LIVE game instead of a hidden probe: deterministic launch, frame-stamped probe before and after every action, exact frame steps. That doctrine is the `agent-playtesting` skill; this skill's probe loop below is the path when those tools answer `engine_lacks_op`.
+
 ## The Loop
 
 ```
@@ -96,9 +98,9 @@ Four rules the probe API will punish you for breaking:
 - **`press()` and `key()` are coroutines.** `await press("jump", 50)` — calling them bare starts the press and never releases it. You also cannot store one in a variable and await it later; it returns void.
 - **Assert on physics-frame-derived state.** `await get_tree().physics_frame` N times, then read positions. That is reproducible run to run.
 - **Assert inequalities, never exact values.** `press(hold_ms)` waits on the wall clock, so the number of physics frames a key is held drifts between runs — the same walk lands on x=245 one run and x=250 the next. `position.x > start.x + 50` is a real assertion; `position.x == 250.0` is a flaky test you wrote yourself.
-- **The global RNG is not seeded.** Anything downstream of `randf()` differs every run. Assert ranges, or seed it yourself in the probe.
+- **The global RNG is not seeded by default.** Anything downstream of `randf()` differs every run. Assert ranges, seed it yourself in the probe, or pin the launch — see [Deterministic runs](#deterministic-runs).
 
-If the probe cannot express the check — no `SummerProbeBase` in this build, or a genuinely out-of-process feature — fall back to `summer_play` + console reads:
+If the probe cannot express the check — no `SummerProbeBase` in this build, or a genuinely out-of-process feature — fall back to `summer_play` + diagnostics reads:
 
 ```
   summer_clear_console
@@ -108,25 +110,29 @@ If the probe cannot express the check — no `SummerProbeBase` in this build, or
 
 `summer_clear_console` first so the buffer is not polluted by a previous session's errors. If you skip this, you will chase ghost errors that have nothing to do with the current feature.
 
+Boot time varies, so do not sleep a guessed delay after `summer_play`. On engines with the events channel: `summer_recent_events` (note `next_seq`) → `summer_play` → `summer_wait_for_event since:<next_seq> kinds:["play.started"]`, then wait on `script.error` during the walkthrough to catch runtime script errors the moment they fire. `engine_lacks_events` means the build predates the channel — confirm with `summer_is_running` and read the console as above. A `timed_out` wait is not proof the game failed to start; check, do not assume.
+
 ### 3. Read back what actually happened
 
-The probe's `results.json` is your primary evidence. Then check the editor's own view:
+The probe's `results.json` is your primary evidence. Then read the editor's own view — in this order, because a played game's runtime errors are collected by the debugger and never reach the editor console:
 
 ```
-  summer_get_console            (look for unexpected prints, warnings)
-  summer_get_debugger_errors    (runtime errors caught mid-play)
-  summer_get_diagnostics        (overall counts)
+  summer_get_diagnostics        (the verdict: console + debugger + script errors, complete counts)
+  summer_get_debugger_errors    (the runtime errors themselves, with stacks)
+  summer_get_console            (print() output and editor-side warnings — after the two above, never instead of them)
 ```
 
+`summer_get_console` alone is never the verdict. Right after a play session that raised four runtime errors it honestly reports `errors 0`, because those errors live in the debugger; its result says so in `_scope`. A clean console proves only that nothing was printed to the editor log.
+
 A probe also collects engine errors itself — `results.json` carries `errors_seen`. Read it. An empty `reports` block with `finished: false` means the probe hit its `max_seconds` ceiling before calling `finish()`, which is a failure, not a pass.
 
-If anything is non-zero or unexpected, the feature is not done. Go to `summer:debug`.
+If anything is non-zero or unexpected, the feature is not done. Go to `debug`.
 
 ### What only a human can answer
 
 A probe reports facts. It cannot hold an opinion. Ask the user only when the question is genuinely experiential:
 
-- **Does it feel right?** Floaty jumps, sluggish input, mushy hit feedback — see `summer:debugging-game-feel`.
+- **Does it feel right?** Floaty jumps, sluggish input, mushy hit feedback — see `debugging-game-feel`.
 - **Does it look good?** Composition, colour, readability. A probe can prove a light exists and prove the frame is not black; it cannot tell you the scene is ugly.
 - **Is this fun?** Not a measurable property.
 
@@ -150,8 +156,9 @@ You do not need to probe every edge for every feature. Pick the 2-3 that are mos
 After the walkthrough and edge probes, capture one final snapshot:
 
 ```
-  summer_get_diagnostics
-  summer_get_console  (if anything looked off)
+  summer_get_diagnostics        (debugger.errors and console errors must both be 0)
+  summer_get_debugger_errors    (if diagnostics shows any)
+  summer_get_console            (if the printed output looked off)
 ```
 
 State the result in plain language:
@@ -160,7 +167,16 @@ State the result in plain language:
 
 Or:
 
-> "Played the chest-open feature: golden path works, but pressing E twice in 100ms duplicates the pickup. Not done — going to summer:debug."
+> "Played the chest-open feature: golden path works, but pressing E twice in 100ms duplicates the pickup. Not done — going to debug."
+
+## Deterministic runs
+
+When a bug only shows on some runs, or two runs must be compared, pin the launch (newer engines): `summer_play seed:42 fixed_fps:60` (optionally `time_scale`). The pins ride on THIS launch's command line only — nothing is persisted, and omitting them is exactly the plain launch.
+
+- **`seed` pins the GLOBAL RNG only** — `randi`/`randf`/`randi_range`/`randf_range`/`randfn`, `Array.shuffle`, `Array.pick_random`, re-seeded after the scene tree initializes and before autoloads and the main scene. It does **not** pin `RandomNumberGenerator` instances (self-randomized on construction), scripts that call `randomize()` (re-randomizes the global RNG from the wall clock), `rand_from_seed` (caller-seeded), wall-clock reads, thread/IO timing, or audio-device timing. The result restates this as `determinism.seed_scope`; a feature that still diverges with a seed is using one of those.
+- **`fixed_fps` decouples scene time from the wall clock** — the game runs as fast as it renders, and frame-count-derived state lands on the same frame run to run. Assertions can become exact where they were ranges.
+- **Read `determinism.applied`.** `applied:false` carries a `reason`: `already_running` (stop first, the pins cannot reach a live process), `editor_run_args_override` (a user-configured run argument re-sets the same flag and wins — `conflicting_flag` names it), `launch_not_started`. A result with NO `determinism` block after you sent a pin means the engine predates the params — the tool says "not applied"; the run is NOT reproducible and you may not claim it is.
+- A `RunVerification` probe pins the same two flags on its own instance; `summer_play` pins are for the embedded game you then read through `summer_get_runtime_tree` / `summer_inspect_runtime_node`.
 
 ## "Looks right" vs "is right"
 
@@ -170,7 +186,7 @@ A common failure mode: the feature visually looks correct on first try, you stop
 
 **Is right** means the rendered frame matches expectations AND the underlying state is consistent AND it survives repetition AND no errors are silently logged.
 
-The console catches "looks right but isn't right" cases — silent errors, deprecation warnings, signal misfires that don't crash but indicate a real bug. **Always read `summer_get_console` after a playthrough, even when the visuals looked fine.**
+The debugger and the console catch "looks right but isn't right" cases — runtime errors that did not crash the game (debugger), deprecation warnings and signal misfires (console). **Always read `summer_get_diagnostics` after a playthrough, even when the visuals looked fine — and never let a clean `summer_get_console` stand in for it: the console does not receive a played game's runtime errors.**
 
 ## When to record video vs when console+diagnostics is enough
 
@@ -178,7 +194,7 @@ Your probe already produces the visual record: `save_frame()` writes a real rend
 
 Ask the user for a video or a live look only when:
 
-- The feature **feels wrong** — see `summer:debugging-game-feel`. Frame counts and console output cannot capture "the jump feels floaty."
+- The feature **feels wrong** — see `debugging-game-feel`. Frame counts and console output cannot capture "the jump feels floaty."
 - The bug is **non-deterministic** and your probe cannot reproduce it after several attempts.
 - The judgement is aesthetic — see [What only a human can answer](#what-only-a-human-can-answer).
 
@@ -196,12 +212,15 @@ Don't ask reflexively. A saved frame sequence answers most "did it visually work
 | "I already played it in a previous session" | State changed. Verify in this session. |
 | "I'll let the user catch any issues" | That is the user's job description for a non-AI engineer. Yours is to ship working features. |
 | Skipping `summer_clear_console` before `summer_play` | You will chase last session's errors. |
+| Sleeping a fixed delay after `summer_play` | Boot time varies. Wait for `play.started` with `summer_wait_for_event`, or confirm with `summer_is_running`. |
 | Skipping `summer_get_console` because diagnostics looked fine | Silent warnings and signal misfires hide there. |
+| Calling `summer_get_console` alone as the post-play check | It never receives a played game's runtime errors; `errors 0` there proves nothing. Read `summer_get_diagnostics` / `summer_get_debugger_errors`. |
 | "The MCP can't simulate input, so the user has to test it" | False. `RunVerification` presses actions and keys. Write the probe. |
 | "I'll ask the user to press jump and tell me what happened" | You can press jump. They should not have to QA your work. |
 | Probe returned `finished: false`, you called it a pass | It hit `max_seconds` before `finish()`. That is a failure. |
 | Asserting `position.x == 250.0` in a probe | Hold time is wall-clock. Assert `> start.x + 50`. |
 | `press("jump", 50)` without `await` | It is a coroutine. The key is never released. |
+| "I sent seed:42, so the run is reproducible" | Only if `determinism.applied` is true. An older engine ignores the pin and the tool says "not applied"; `seed` never pins `RandomNumberGenerator` instances or `randomize()` calls. |
 
 ## Rationalization Prevention
 
@@ -225,7 +244,7 @@ Don't ask reflexively. A saved frame sequence answers most "did it visually work
   --summer-verify-max 30
 ```
 
-Then read `<out-dir>/results.json` and the JPEGs beside it. The probe must extend the base class — copy `summer_probe_base.gd` into the project and `extends "res://summer_probe_base.gd"`, or use the project's `tests/autopilot/` scaffold if it has one. See `summer:headless-scripting` for the full pattern and its traps.
+Then read `<out-dir>/results.json` and the JPEGs beside it. The probe must extend the base class — copy `summer_probe_base.gd` into the project and `extends "res://summer_probe_base.gd"`, or use the project's `tests/autopilot/` scaffold if it has one. See `headless-scripting` for the full pattern and its traps.
 
 So if `summer_play` returns "Summer Engine is not running":
 
@@ -237,10 +256,10 @@ So if `summer_play` returns "Summer Engine is not running":
 
 A game feature is a promise to the player. Verifying it means seeing the promise kept on screen, not seeing the code that would, in theory, keep it.
 
-Press play. Walk the path. Probe the edges. Read the console. Then claim done.
+Press play. Walk the path. Probe the edges. Read the diagnostics. Then claim done.
 
 **Related skills:**
-- `summer:verification-before-completion` — the code-layer verification this skill builds on.
-- `summer:debug` — when the playtest surfaces a crash or error.
-- `summer:investigating-bugs` — when the playtest surfaces a reproducible logical bug.
-- `summer:debugging-game-feel` — when the feature works but feels wrong.
+- `verification-before-completion` — the code-layer verification this skill builds on.
+- `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.

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

@@ -0,0 +1,31 @@
+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."
+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
+  - a playtest must be reproducible run to run (pin the launch with seed / fixed_fps and read what the pin does and does not cover)
+facets:
+  lifecycle:
+    - build
+  domains:
+    - agent-workflow
+    - verification
+  modalities:
+    - project
+compatibility:
+  engine: ">=4.6"
+related:
+  tools:
+    - tool/play
+    - tool/get-runtime-tree
+    - tool/inspect-runtime-node
+  skills:
+    - skill/agent-playtesting
+source: official
+license: MIT
+status: stable
+recommended: true
+aliases:
+  - skills/workflow/playtesting-a-feature

package/{skills/animation → library/skills}/procedural-animation/SKILL.md

@@ -5,7 +5,7 @@ license: MIT
 compatibility: [Cursor, Claude Code, Windsurf, Codex]
 category: animation
 user-invocable: false
-allowed-tools: Read Grep Edit Write summer_get_scene_tree summer_inspect_node summer_inspect_resource summer_add_node summer_set_prop summer_set_resource_property summer_save_scene summer_get_script_errors
+allowed-tools: Read Grep Edit Write summer_get_scene_tree summer_inspect_node summer_inspect_resource summer_run_script summer_add_node summer_set_prop summer_set_resource_property summer_save_scene summer_get_script_errors
 paths: ["**/*.gd", "**/*.tscn", "**/*.tres"]
 ---
 
@@ -31,7 +31,7 @@ the contact frame and accept some clipping.
 
 - The clip already covers it. Don't IK what mocap already nailed — adds CPU cost and rounding error.
 - The character is far from the camera (LOD2+). Procedural cost outpaces visual benefit. Disable modifiers past 15m.
-- You need facial animation. That's `summer:animation/facial-and-lipsync`.
+- You need facial animation. That's `facial-and-lipsync`.
 - You haven't generated base clips yet. Skeleton modifiers compose ON TOP of clips; without a base pose they'll stack on T-pose and look wrong.
 
 ## The three patterns
@@ -54,7 +54,21 @@ The skeleton hands off to physics on death. Bones become `PhysicalBone3D` rigid
 
 ### A1 — Head look-at the player
 
-The bread-and-butter NPC liveliness fix. Three lines of scene + one script function.
+The bread-and-butter NPC liveliness fix.
+
+**ctx lane (animation-tier engines):** one `summer_run_script` call creates the owned modifier and sets the props — prefer it over the 10-call CRUD chain below:
+
+```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"), {
+        "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:
 
 ```
 summer_inspect_node "./World/NPC/Skeleton3D"   # confirm bone names
@@ -219,7 +233,7 @@ You need PhysicalBone3D children matching every major bone (set up once via the
 
 ## Anti-patterns
 
-- Writing `skel.set_bone_pose_position(...)` in `_process`. Bypasses the AnimationTree, fights it next frame, results in jitter. Use modifiers instead — they integrate with the pipeline.
+- Writing `skel.set_bone_pose_position(...)` in `_process`. Bypasses the AnimationTree, fights it next frame, results in jitter. Use modifiers instead — they integrate with the pipeline. (Edit-time STILL poses — a corpse, a statue — are the exception: no tree is running, so `ctx.bone_pose(skel, bone, {position/rotation/scale})` on animation-tier engines, or `set_bone_pose_*` in a one-off `summer_run_script`, is exactly right. See `character-animation-wiring`.)
 - Putting IK targets in worldspace and forgetting they don't follow the character. Parent IK targets under the character root or bone — IK target is in the modifier's local space.
 - Procedural look-at without a fade-out at distance. Distant NPCs all snap to player every frame, looks like a hivemind.
 - Foot IK on flying / floating characters. Disable when `is_on_floor() == false`.
@@ -229,7 +243,7 @@ You need PhysicalBone3D children matching every major bone (set up once via the
 - **Character is mounted (riding a horse).** Disable foot IK on the rider; ride animation already sells the contact. Enable upper-body additive sway driven by horse acceleration.
 - **First-person hands.** Same modifier set, but only the arm chain is visible — disable head/spine modifiers, keep hand-on-prop IK.
 - **Character is a quadruped.** All four legs need foot IK. The bone names are different (`FrontLeftLeg`, `BackRightLeg`, etc.); inspect first.
-- **Network-synced ragdoll.** Don't simulate on every client. Simulate on the host, send bone transforms via `MultiplayerSynchronizer`, blend on receivers. Out of scope; see `summer:multiplayer-and-networking`.
+- **Network-synced ragdoll.** Don't simulate on every client. Simulate on the host, send bone transforms via `MultiplayerSynchronizer`, blend on receivers. Out of scope; see `setup-multiplayer`.
 
 ## Fallback (no MCP)
 
@@ -239,11 +253,12 @@ driving them. Foot raycasts can be set up visually with a RayCast3D child.
 
 ## Handoff
 
-- For the AnimationTree these procedural layers compose with, `summer:animation/animation-tree`.
-- For the source clips that procedural overlays modify, `summer:animation/generate-motion`.
-- For face / lipsync (a different modifier family — BlendShapes, not bones), `summer:animation/facial-and-lipsync`.
-- For NPC behavior triggering ragdoll on death, `summer:ai-and-npcs/design-npc`.
-- For first-person aim sway / ADS, `summer:character-controllers/fps-controller`.
+- For the end-to-end rigged-character wiring these layers sit on top of (locomotion, method-track events, root motion), `character-animation-wiring`.
+- For the AnimationTree these procedural layers compose with, `animation-tree`.
+- For the source clips that procedural overlays modify, `generate-motion`.
+- For face / lipsync (a different modifier family — BlendShapes, not bones), `facial-and-lipsync`.
+- For NPC behavior triggering ragdoll on death, `design-npc`.
+- For first-person aim sway / ADS, `fps-controller`.
 
 ## See also
 

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

@@ -0,0 +1,33 @@
+id: skill/procedural-animation
+kind: skill
+version: 1.0.3
+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.
+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)
+facets:
+  lifecycle:
+    - build
+  domains:
+    - animation
+    - 3d
+  modalities:
+    - animation
+    - scripts
+compatibility:
+  engine: ">=4.6"
+related:
+  skills:
+    - skill/character-animation-wiring
+    - skill/design-npc
+    - skill/animation-tree
+    - skill/facial-and-lipsync
+    - skill/generate-motion
+    - skill/fps-controller
+    - skill/retarget
+source: official
+license: MIT
+status: stable
+recommended: false
+aliases:
+  - skills/animation/procedural-animation

package/{skills/3d-assets → library/skills}/prop-model/SKILL.md

@@ -25,11 +25,11 @@ The backing tool is `summer_generate_3d`. Default model is `hunyuan` (Hunyuan 3D
 
 ## When NOT to use
 
-- Character / humanoid → `summer:3d-assets/character-model` (needs T-pose + rig pass).
-- A set of matching pieces (walls, floors, doors, pillars) → `summer:3d-assets/environment-kit` (style-locked family).
-- Trees, rocks, foliage → `summer:3d-assets/organic-model` (organic forgives AI artifacts; cheaper recipe).
-- Cars, ships, mechs → `summer:3d-assets/vehicle-model` (hard-surface specifics).
-- Walls / floors / repeating geometry → `summer:asset-pipeline/asset-strategy` Pipeline 2 (textures + CSG).
+- Character / humanoid → `character-model` (needs T-pose + rig pass).
+- A set of matching pieces (walls, floors, doors, pillars) → `environment-kit` (style-locked family).
+- Trees, rocks, foliage → `organic-model` (organic forgives AI artifacts; cheaper recipe).
+- Cars, ships, mechs → `vehicle-model` (hard-surface specifics).
+- Walls / floors / repeating geometry → `asset-strategy` Pipeline 2 (textures + CSG).
 - "I just need a placeholder" → propose a primitive (`BoxMesh` / `CylinderMesh`) instead. Generation is metered.
 
 ## Steps
@@ -104,7 +104,7 @@ summer_save_scene(scenePath="res://main.tscn")
 
 For interactive props (chest the player opens, lantern the player picks up),
 wrap the instantiated model in a `StaticBody3D` (or `RigidBody3D` for physics
-props) with a `CollisionShape3D` sibling — see `summer:scene-composition` for
+props) with a `CollisionShape3D` sibling — see `scene-composition` for
 the parent-shape pattern.
 
 ## Anti-patterns
@@ -135,13 +135,13 @@ assign the mesh.
 After the prop is wired:
 
 > `viking_axe.glb` imported and placed at `./World/Props/VikingAxe`. Next:
-> - For physics (player can knock it over), wrap in `RigidBody3D` + `CollisionShape3D` — see `summer:scene-composition`.
-> - For pickup interaction, see `summer:design-mechanic` for the pickup pattern.
-> - For matching props in the same style (chest → barrel → crate as a treasure-room kit), use `summer:3d-assets/environment-kit` with this prop as the style anchor.
+> - For physics (player can knock it over), wrap in `RigidBody3D` + `CollisionShape3D` — see `scene-composition`.
+> - For pickup interaction, see `design-mechanic` for the pickup pattern.
+> - For matching props in the same style (chest → barrel → crate as a treasure-room kit), use `environment-kit` with this prop as the style anchor.
 
 ## See also
 
-- `summer:asset-pipeline/asset-strategy` — the meta-router that decides between this skill and Pipeline 2 (textures).
-- `summer:3d-assets/character-model` — for humanoids.
-- `summer:3d-assets/environment-kit` — for style-locked sets.
-- `../../../references/mcp-tools-reference.md` — `summer_generate_3d` parameter schema.
+- `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.

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

@@ -0,0 +1,33 @@
+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.
+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
+do_not_use_when:
+  - the object needs rigging or animation — that is character-model territory
+facets:
+  lifecycle:
+    - build
+  domains:
+    - 3d
+    - assets
+  modalities:
+    - 3d-models
+    - scenes
+compatibility:
+  engine: ">=4.6"
+related:
+  skills:
+    - skill/character-model
+    - skill/environment-kit
+    - skill/organic-model
+    - skill/vehicle-model
+    - skill/asset-strategy
+source: official
+license: MIT
+status: stable
+recommended: true
+aliases:
+  - skills/3d-assets/prop-model