summer-engine 3.4.0 → 3.5.0

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

@@ -11,18 +11,18 @@ paths: ["**/*.gd", "**/*.tscn", "**/*.tres"]
 
 # AnimationTree — Wire Clips Into Behavior
 
-Generation gives you clips. The AnimationTree gives the character life. This skill is **not generative** — no FAL, no MCP AI calls. It composes existing clips on an `AnimationPlayer` into an `AnimationTree` with a `StateMachine` for distinct states (idle / attack / hit / dead) and `BlendSpace` nodes for continuous parameters (walk-run blend by speed). Done right, the character moves like a shipped game; done wrong, you get T-poses, snapping, or animations that "eat" each other.
+This skill generates nothing. It composes existing clips on an `AnimationPlayer` into an `AnimationTree` with a `StateMachine` for distinct states (idle / attack / hit / dead) and `BlendSpace` nodes for continuous parameters (walk-run blend by speed). Wired wrong, you get T-poses, snapping, or clips that cut each other off.
 
 The canonical Summer Engine stack:
 
 ```
 Character (CharacterBody3D)
-├── Skeleton3D (from the Meshy rig)
+├── Skeleton3D (from the rigged GLB)
 ├── AnimationPlayer            # holds the raw clips (idle, walk, run, attack_sword, ...)
 └── AnimationTree              # references AnimationPlayer, drives behavior
 ```
 
-Before adding the tree, prove direct `AnimationPlayer.play()` visibly moves the rig. Godot may import animation GLBs as `AnimationLibrary` resources or as `PackedScene`s with embedded `AnimationPlayer`s. If a copied clip appears in the list but the mesh T-poses, its tracks probably target a different root/skeleton path. Use the embedded player that came with the matching GLB, or remap/copy tracks only after confirming they target the active `Skeleton3D`. An inactive AnimationTree is also a no-op, so always set `AnimationTree.active = true`.
+Before adding the tree, prove direct `AnimationPlayer.play()` visibly moves the rig. The engine may import animation GLBs as `AnimationLibrary` resources or as `PackedScene`s with embedded `AnimationPlayer`s. If a copied clip appears in the list but the mesh T-poses, its tracks probably target a different root/skeleton path. Use the embedded player that came with the matching GLB, or remap/copy tracks only after confirming they target the active `Skeleton3D`. An inactive AnimationTree is also a no-op, so always set `AnimationTree.active = true`.
 
 ## When to use this skill
 
@@ -72,7 +72,7 @@ Before walking the CRUD steps below, check the ctx lane — one `summer_run_scri
 - **Animation-tier engines:** `ctx.anim_state_machine(character, {states: {...}, transitions: [[from, to, {blend_s: 0.2}], ...], start: "idle"})` gets-or-creates the AnimationTree, wires it to the player, builds the state machine, sets `active = true`. Unknown clip names come back as a report entry listing the player's REAL clips — never wire against guessed names. Full recipe (inspect clips/bones first, method-track events, root motion, playtest verification): `character-animation-wiring`.
 - **Any engine (raw fallback):** the same classes are fully script-bound — `AnimationNodeStateMachine.add_node(name, AnimationNodeAnimation)`, `add_transition(from, to, AnimationNodeStateMachineTransition)` (one transition resource each, `xfade_time` on it), then `tree.anim_player = tree.get_path_to(player)`, `tree.tree_root = sm`, `tree.active = true`, and `ctx.set_owner_recursive(tree)`. The raw script is quoted in `character-animation-wiring`.
 
-Note the helper's scope honestly: `anim_state_machine` builds clip states + transitions only. The canonical machine below — BlendSpace1D locomotion, OneShot attack/hit — still needs the `.tres` (or raw-script) lane for those node types. Discrete idle/walk/run backbones don't.
+Scope: `anim_state_machine` builds clip states + transitions only. The canonical machine below — BlendSpace1D locomotion, OneShot attack/hit — still needs the `.tres` (or raw-script) lane for those node types. Discrete idle/walk/run backbones don't.
 
 ## Steps via MCP
 
@@ -259,7 +259,7 @@ Then `summer_play` and watch — the goblin should idle in place, blend up to wa
 
 - **OneShot:** the action is a *temporary override* of an underlying state (attack while running, hit-react while attacking). The base keeps playing.
 - **StateMachine state:** the action is a *replacement* (dead, stunned, ragdoll). Nothing else plays.
-- Combat in 2026-feel games is almost always OneShot for attacks + StateMachine state for "dead". Don't model attacks as StateMachine states unless you need precise transition control between attack-string variants.
+- Action combat is usually OneShot for attacks + a StateMachine state for "dead". Don't model attacks as StateMachine states unless you need precise transition control between attack-string variants.
 
 ### BlendSpace1D vs BlendSpace2D
 
@@ -270,7 +270,7 @@ Then `summer_play` and watch — the goblin should idle in place, blend up to wa
 
 - Skipping AnimationTree and calling `AnimationPlayer.play("walk")` from script. Works for one clip; breaks the moment you need a crossfade.
 - Modeling every attack as a StateMachine state. The transition matrix explodes (N states × N transitions). Use one OneShot per attack and switch its inner clip via `parameters/Attack/animation`.
-- Writing the `.tres` by hand without using sub_resource IDs — Godot loses references and the inspector is unhappy. Always use `[sub_resource id="..."]` blocks.
+- Writing the `.tres` by hand without using sub_resource IDs — the engine loses the references. Always use `[sub_resource id="..."]` blocks.
 - Driving `blend_position` from raw input (`Input.get_axis(...)`). Drive from actual velocity — that way the blend matches the body's real motion, including knockback and slope-slide.
 
 ## Edge cases

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

@@ -13,7 +13,7 @@ paths: [".summer/**", "project.godot", "**/*.tscn"]
 
 ## Overview
 
-A consistent art direction is what makes a low-budget game *look* like a finished game. Most solo devs lose this fight by mixing styles — a toon-shaded character on a photoreal terrain, a pixel UI over a smooth 3D world. This skill builds an art bible the rest of the project obeys: references, palette, mood, lighting plan, post-processing, and a do/don't list. It writes to `.summer/art-bible.md` — the file every rendering / shader / lighting / VFX skill reads later.
+A consistent art direction makes a low-budget game look finished. Solo developers most often lose it by mixing styles — a toon-shaded character on a photoreal terrain, a pixel UI over a smooth 3D world. This skill builds an art bible the rest of the project obeys: references, palette, mood, lighting plan, post-processing, and a do/don't list. It writes to `.summer/art-bible.md` — the file every rendering / shader / lighting / VFX skill reads later.
 
 **Core principle:** Constraint produces style. A game with **15 colors total** looks more intentional than a game with infinite-color textures. Pick the constraint, then defend it.
 
@@ -118,7 +118,7 @@ State the plan in one block. For the current Summer Engine rendering stack:
 ```
 Sun: DirectionalLight3D, color #fff2d9, energy 0.9, angle ~30° (warm low-angle)
 Sky: ProceduralSkyMaterial, sky_top_color #6b88a3, sky_horizon_color #d8b88e
-Ambient: AmbientLight #4a5570, energy 0.15
+Ambient: Environment ambient_light_color #4a5570, ambient_light_energy 0.15
 Indoor fills: OmniLight3D color #ffd9a8, energy 0.6, range 4m
 NEVER: pure-white DirectionalLight, no ambient, hard cube shadows
 ```
@@ -138,7 +138,7 @@ Summer Engine post stack: Glow, SDFGI, SSAO, SSR, Adjustments, Color Correction
 
 ```
 Glow: ON, threshold 0.9, intensity 0.5  (soft bloom on highlights only)
-SDFGI: OFF for vertical-slice scope (perf cost; bake light probes later)
+SDFGI: OFF for vertical-slice scope (perf cost; bake lightmaps later)
 SSAO: ON, light_affect 0.3 (just enough for grounding)
 SSR: OFF unless we have wet/glass surfaces
 Color correction: Filmic tonemap, slight S-curve LUT toward warm
@@ -159,7 +159,7 @@ This is the contract. Five do's, five don'ts. Specific, enforceable.
 - Outline shader on character + interactable props (no outline on environment).
 - Soft shadows (DirectionalLight3D shadow_blur 1.5).
 - Warm key + cool fill — never both warm or both cool.
-- Texture filter: Linear with mipmaps OFF for crunchy near-pixel feel.
+- Texture filter: Nearest for a crunchy, near-pixel feel.
 
 ## DON'T
 - No pure white (#ffffff). Use #f4ecdf.
@@ -176,7 +176,7 @@ Some art-direction calls translate to `project.godot` settings. Apply them.
 **Preferred (Summer MCP):**
 
 ```
-summer_project_setting(key="rendering/textures/canvas_textures/default_texture_filter", value="2")  # Linear no mipmaps if pixel-art-ish
+summer_project_setting(key="rendering/textures/canvas_textures/default_texture_filter", value="0")  # Nearest, if pixel-art-ish (1 = Linear, the default)
 summer_project_setting(key="rendering/environment/defaults/default_clear_color", value="Color(0.227, 0.290, 0.227)")  # palette primary
 summer_project_setting(key="rendering/anti_aliasing/quality/msaa_3d", value="2")  # MSAA 2x for clean edges
 ```
@@ -274,9 +274,6 @@ No template — this is a workflow that produces the bible the rest of the proje
 
 ## See also
 
-- `scene-and-project/brainstorm-game/SKILL.md` — produces the brief that anchors the bible
-- `audio/audio-direction/SKILL.md` — the sonic counterpart
-- `rendering-and-lighting/3d-lighting/SKILL.md` — implements the lighting plan
-- `shaders/shader-basics/SKILL.md` — for outline / toon shaders
-- `post-processing/bloom-and-glow/SKILL.md` — implements the glow rule
-- `post-processing/color-grading/SKILL.md` — implements the LUT and tonemap call
+- `brainstorm-game` — produces the brief that anchors the bible
+- `audio-direction` — the sonic counterpart
+- `3d-lighting` — implements the lighting plan and the environment's glow, tonemap and SSAO settings

package/library/skills/asset-strategy/SKILL.md

@@ -34,7 +34,7 @@ Ask the **exact phrase** before dispatching. Skipping the question is the most c
 | Concept art vs character portrait | "Quick check — exploring the look (3-4 variants for art direction) or generating a final character portrait for dialogue UI?" | `concept-art` (exploring) / `character-portrait` (final) |
 | Prop vs character model | "Static object (sword, chair, lantern) or rigged character that needs animation?" | `prop-model` / `character-model` |
 | Tile vs sprite sheet | "One seamless tile that repeats, or a frame grid for an animated sprite?" | `tileable-texture` / `sprite-sheet` |
-| SFX vs music | "One-shot effect or a longer track (loop, theme, ambient bed)?" | `sound-effect` / `music-track` (or `audio/ambient-bed`) |
+| SFX vs music | "One-shot effect or a longer track (loop, theme, ambient bed)?" | `sound-effect` / `music-track` (or `ambient-bed`) |
 | Generate vs retarget motion | "Generate a new clip on this character, or apply an existing library to a new character?" | `generate-motion` / `retarget` |
 | VFX recipe vs game-feel | "Particle/shader effect in the world or screen-feel (camera shake, hit-stop)?" | `vfx-<name>` / `game-feel` |
 
@@ -61,7 +61,7 @@ Invoke the specialist via the `Skill` tool. Don't paraphrase — let it run. Pas
 | Request | Skill |
 |---|---|
 | Sword / chair / barrel / static object | `prop-model` |
-| Player / NPC / enemy / boss / rigged humanoid | `character-model` (canonical Meshy auto-rig) |
+| Player / NPC / enemy / boss / rigged humanoid | `character-model` (generated mesh + auto-rig) |
 | Modular dungeon / building blocks | `environment-kit` |
 | Car / spaceship / hard-surface vehicle | `vehicle-model` |
 | Tree / rock / mushroom / foliage | `organic-model` |
@@ -132,4 +132,4 @@ VFX is **code, not generative** — recipes are shader + GDScript + node setup,
 
 ## Fallback (no MCP)
 
-The router still works without MCP — classification is text-only. It hands off to the specialist, which surfaces its own no-MCP fallback (typically: run the equivalent generation via the Summer dashboard / Meshy / nano-banana web, then `summer_import_from_url` once MCP is back).
+The router still works without MCP — classification is text-only. It hands off to the specialist, which surfaces its own no-MCP fallback (typically: run the same generation in the Summer dashboard, then `summer_import_from_url` once MCP is back).

package/library/skills/audio-direction/SKILL.md

@@ -13,7 +13,7 @@ paths: [".summer/**", "project.godot", "**/*.tscn", "audio/**"]
 
 ## Overview
 
-Most indie games sound like a single library used flat. The same generic "swoosh" for menu, jump, pickup, hit. That's not audio direction — that's audio absence. This skill builds an audio bible that names the music style, the SFX vocabulary, the dynamic music plan, and the spatial / mix rules. Writes to `.summer/audio-bible.md` and configures the audio bus layout in the project so the rest of the work has a real foundation.
+Many indie games sound like one sound library used flat: the same generic "swoosh" for menu, jump, pickup and hit. This skill builds an audio bible that names the music style, the SFX vocabulary, the dynamic music plan, and the spatial / mix rules. Writes to `.summer/audio-bible.md` and configures the audio bus layout in the project so the rest of the work has a real foundation.
 
 **Core principle:** SFX needs a *vocabulary*, not a *library*. Eight named SFX classes with consistent character beat 80 random library hits.
 
@@ -25,7 +25,7 @@ Ask exactly this:
 
 > Three reference tracks, games, or films for the music. What instruments matter? And what's the SFX vibe — chunky, clean, synthetic, or organic?
 
-Three is the minimum. One or two collapses into a clone. References are the highest-signal input — listen carefully.
+Three is the minimum. One or two collapses into a clone.
 
 If they freeze, offer four axes (not titles):
 
@@ -237,9 +237,9 @@ End with:
 | Music louder than SFX | Players need SFX for gameplay; music is mood. Default mix is -8 dB music vs 0 dB SFX. |
 | No reverb buses | "Send" architecture (rooms route to a small/large/outdoor reverb bus) is mandatory or your mix sounds dry-then-wet inconsistently. |
 | Pure sine "ding" for pickup | Reads as cheap mobile game. Use a major-third interval with character. |
-| Same footstep sample for all surfaces | Material-aware footsteps are 80% of the perceived audio quality. |
+| Same footstep sample for all surfaces | Players hear footsteps constantly; material-aware steps carry much of the perceived audio quality. |
 | No master ceiling / true peak | Audio clips on console builds without `-1 dBTP` ceiling. Always set it. |
-| Assuming SetResourceProperty fails silently on inline sub_resources | It does not — inline targets work, and the structural failures (`node not found`, `property is not a resource`, `resource is null`) are explicit errors. What *is* silent on current engines is a bad value shape: a JSON object instead of a Godot literal string, a misspelled `subProperty`, or a wrong-typed value returns `ok:true` yet no-ops or coerces destructively. Pass class names and literal strings, and confirm in the saved `.tres`/`.tscn`, never from `ok` alone. See `../../references/mcp-tools-reference/mcp-tools-reference.md`. |
+| Assuming SetResourceProperty fails silently on inline sub_resources | It does not — inline targets work, and the structural failures (`node not found`, `property is not a resource`, `resource is null`) are explicit errors. What *is* silent on current engines is a bad value shape: a JSON object instead of an engine literal string, a misspelled `subProperty`, or a wrong-typed value returns `ok:true` yet no-ops or coerces destructively. Pass class names and literal strings, and confirm in the saved `.tres`/`.tscn`, never from `ok` alone. See `../../references/mcp-tools-reference/mcp-tools-reference.md`. |
 
 ## Collaborative protocol
 
@@ -255,9 +255,7 @@ No template — this is a workflow that produces the bible the rest of the proje
 - `../../references/godot-version/godot-version.md` — Summer compatibility and
   version-sensitive audio API notes
 - `../../references/mcp-tools-reference/mcp-tools-reference.md`
-- `scene-and-project/brainstorm-game/SKILL.md` — produces the brief that anchors the bible
-- `rendering-and-lighting/art-direction/SKILL.md` — the visual counterpart; audio must rhyme with it
-- `audio/audio-bus-setup/SKILL.md` (NEXT) — implements the bus layout in detail
-- `audio/3d-spatial-audio/SKILL.md` (NEXT) — spatial attenuation patterns
-- `audio/footstep-systems/SKILL.md` (NEXT) — material-aware footstep impl
-- `audio/dynamic-music-stingers/SKILL.md` (LATER) — implements the dynamic music plan
+- `brainstorm-game` — produces the brief that anchors the bible
+- `art-direction` — the visual counterpart; audio must rhyme with it
+- `adaptive-music` — implements the dynamic music plan
+- `sound-effect`, `music-track`, `ambient-bed`, `voice-line` — generate the audio the bible describes

package/library/skills/auto-fire-targeting/SKILL.md

@@ -172,10 +172,11 @@ Use `summer_get_diagnostics` to confirm no new errors.
 `summer_inspect_node` will **not** show you `pending_damage` mid-fight. It reads
 the edited scene in the editor — the response even tags itself
 `provenance: editor_scene` — so it reports the saved node, not the live
-instance. Runtime values need a runtime probe.
+instance. Runtime values need a runtime read: with the game running, read
+the enemy with `summer_inspect_runtime_node` or `summer_game_probe` (engine
+builds with the runtime-control ops; see the `agent-playtesting` skill).
 
-The route that works from MCP is the `RunVerification` op, sent through
-`summer_batch`. It spins up a hidden, disposable game instance that runs a
+On any build, the `RunVerification` op, sent through `summer_batch`, also works. It spins up a hidden, disposable game instance that runs a
 GDScript probe and exits; it never touches the editor:
 
 ```

package/library/skills/bounded-engine-runs/SKILL.md

@@ -11,9 +11,9 @@ paths: ["project.godot", "tests/**/*.gd", "tools/**/*.gd"]
 
 # Bounded engine runs for agents
 
-Agents verify games by running the engine many times: imports, tests, captures, multiplayer bots. Each run
-that hangs, overlaps another, makes noise or hides an error costs time and trust. These rules come from a
-day of several agents sharing one project on one Mac.
+Agents verify games by running the engine many times: imports, tests, captures, multiplayer bots. A run
+that hangs, overlaps another, makes noise or hides an error costs time. These rules keep runs safe when
+several agents share one project on one machine.
 
 ## 1. Every run is bounded, muted and alone
 
@@ -29,14 +29,13 @@ day of several agents sharing one project on one Mac.
     <project>/.engine.lock 180 <summer> ...
   ```
   Put this in one wrapper script and make every agent use it.
-- **Cap its memory.** A time limit does not stop a run from eating all memory first. One day of several agents
-  running builds, renders and a browser load of a large web export at once kernel-panicked the Mac
-  (compressor full, swap unable to grow). The wrapper should run the command as a child, sum the resident
+- **Cap its memory.** A time limit does not stop a run from eating all memory first; several engine runs plus a
+  browser loading a large web export can exhaust memory and crash the machine. The wrapper should run the command as a child, sum the resident
   memory of its whole process tree (browsers spawn GPU/renderer helpers), kill the tree past a cap (e.g.
   3 GB), and also stop when system free memory falls low (`sysctl -n kern.memorystatus_level` < 15 on macOS),
   because GPU memory on Apple Silicon is system memory but is not counted in RSS. Refuse to start when the
   system is already short (< 35).
-- **Mute it.** `--audio-driver Dummy`. Someone is working next to you.
+- **Mute it.** `--audio-driver Dummy`.
 - **Render only when you must, and offscreen.** `--headless` for logic (no pixels). For visual checks use
   `--summer-offscreen` with a fixed `--resolution` and a capture script that saves PNGs and quits. Visible
   windows only when a human asked to watch.

package/library/skills/brainstorm-game/SKILL.md

@@ -201,8 +201,8 @@ No template — this is a workflow that produces the brief that drives template
 
 ## See also
 
-- `gameplay-mechanics/design-mechanic/SKILL.md` — design the core loop in detail
-- `level-design/design-level/SKILL.md` — sketch level 1
-- `rendering-and-lighting/art-direction/SKILL.md` — turn the one-phrase look into a full bible
-- `audio/audio-direction/SKILL.md` — sonic identity
-- `scene-and-project/make-game/SKILL.md` — scaffold the project once the brief is locked
+- `design-mechanic` — design the core loop in detail
+- `design-level` — sketch level 1
+- `art-direction` — turn the one-phrase look into a full bible
+- `audio-direction` — sonic identity
+- `make-game` — scaffold the project once the brief is locked

package/library/skills/brainstorming/SKILL.md

@@ -22,21 +22,19 @@ Every project goes through this process. A todo list, a single-function utility,
 You MUST create a task for each of these items and complete them in order:
 
 1. **Explore project context** — check files, docs, recent commits
-3. **Ask clarifying questions** — one at a time, understand purpose/constraints/success criteria
-4. **Propose 2-3 approaches** — with trade-offs and your recommendation
-5. **Present design** — in sections scaled to their complexity, get user approval after each section
-6. **Write design doc** — save to `.summer/specs/YYYY-MM-DD-<topic>-design.md` in the game project and commit
-7. **Spec self-review** — quick inline check for placeholders, contradictions, ambiguity, scope (see below)
-8. **User reviews written spec** — ask user to review the spec file before proceeding
-9. **Transition to implementation** — invoke writing-plans skill to create implementation plan
+2. **Ask clarifying questions** — one at a time, understand purpose/constraints/success criteria
+3. **Propose 2-3 approaches** — with trade-offs and your recommendation
+4. **Present design** — in sections scaled to their complexity, get user approval after each section
+5. **Write design doc** — save to `.summer/specs/YYYY-MM-DD-<topic>-design.md` in the game project and commit
+6. **Spec self-review** — quick inline check for placeholders, contradictions, ambiguity, scope (see below)
+7. **User reviews written spec** — ask user to review the spec file before proceeding
+8. **Transition to implementation** — invoke writing-plans skill to create implementation plan
 
 ## Process Flow
 
 ```dot
 digraph brainstorming {
     "Explore project context" [shape=box];
-    "Visual questions ahead?" [shape=diamond];
-    "Offer Visual Companion\n(own message, no other content)" [shape=box];
     "Ask clarifying questions" [shape=box];
     "Propose 2-3 approaches" [shape=box];
     "Present design sections" [shape=box];
@@ -46,10 +44,7 @@ digraph brainstorming {
     "User reviews spec?" [shape=diamond];
     "Invoke writing-plans skill" [shape=doublecircle];
 
-    "Explore project context" -> "Visual questions ahead?";
-    "Visual questions ahead?" -> "Offer Visual Companion\n(own message, no other content)" [label="yes"];
-    "Visual questions ahead?" -> "Ask clarifying questions" [label="no"];
-    "Offer Visual Companion\n(own message, no other content)" -> "Ask clarifying questions";
+    "Explore project context" -> "Ask clarifying questions";
     "Ask clarifying questions" -> "Propose 2-3 approaches";
     "Propose 2-3 approaches" -> "Present design sections";
     "Present design sections" -> "User approves design?";
@@ -62,7 +57,7 @@ digraph brainstorming {
 }
 ```
 
-**The terminal state is invoking writing-plans.** Do NOT invoke frontend-design, mcp-builder, or any other implementation skill. The ONLY skill you invoke after brainstorming is writing-plans.
+**The terminal state is invoking writing-plans.** Do NOT invoke any implementation skill. The ONLY skill you invoke after brainstorming is writing-plans.
 
 ## The Process
 
@@ -109,7 +104,6 @@ digraph brainstorming {
 
 - Write the validated design (spec) to `.summer/specs/YYYY-MM-DD-<topic>-design.md` in the game project
   - (User preferences for spec location override this default)
-- Use elements-of-style:writing-clearly-and-concisely skill if available
 - Commit the design document to git
 
 **Spec Self-Review:**

package/library/skills/celeste-momentum-platforming/SKILL.md

@@ -16,11 +16,11 @@ confidence: extracted
 
 ## Outcome
 
-A 2D character controller for SummerEngine that reproduces the tuning architecture and forgiveness mechanics of Celeste's player movement: momentum-based running with distinct ground/air acceleration, variable-height jumping with coyote time, a multi-directional dash with cooldown and residual speed, wall interaction (jump, slide, climb with stamina), and pixel-scale corner corrections that make near-miss inputs succeed instead of fail.
+A 2D character controller for Summer Engine that reproduces the tuning architecture and forgiveness mechanics of Celeste's player movement: momentum-based running with distinct ground/air acceleration, variable-height jumping with coyote time, a multi-directional dash with cooldown and residual speed, wall interaction (jump, slide, climb with stamina), and pixel-scale corner corrections that make near-miss inputs succeed instead of fail.
 
 ## When to Use
 
-- Building a precision 2D platformer in SummerEngine where movement feel is the core gameplay.
+- Building a precision 2D platformer in Summer Engine where movement feel is the core gameplay.
 - Porting or prototyping Celeste-style mechanics (dash, wall jump, climb stamina).
 - Tuning an existing platformer controller that feels "unfair" or unresponsive — the forgiveness systems below are the primary fix.
 
@@ -28,9 +28,9 @@ Do not use for: 3D character controllers, physics-driven (RigidBody) movement, o
 
 ## Core Principle
 
-Celeste's movement is a **single controller class driven by an explicit integer state machine**, with all feel-critical numbers as a **flat compile-time constants table** at the top of the class. The retrieved source (Player.cs, 5,471 lines) defines states `Normal=0, Climb=1, Dash=2, Swim=3, Boost=4, RedDash=5, HitSquash=6, Launch=7, Pickup=8, DreamDash=9` (+ a Summit state), each with Begin/Update/End callbacks. State transitions are direct integer assignments.
+Celeste's movement is a **single controller class driven by an explicit integer state machine**, with all feel-critical numbers as a **flat compile-time constants table** at the top of the class. The released source (`Player.cs`, 5,471 lines) defines states `Normal=0, Climb=1, Dash=2, Swim=3, Boost=4, RedDash=5, HitSquash=6, Launch=7, Pickup=8, DreamDash=9` (+ a Summit state), each with Begin/Update/End callbacks. State transitions are direct integer assignments.
 
-The second principle: **forgiveness at the pixel and millisecond scale**. The code repeatedly nudges the player 2–6 pixels or grants 50–200 ms windows so that inputs which are *almost* correct still succeed. This is the source of the "tightest" feel described in the originating post.
+The second principle: **forgiveness at the pixel and millisecond scale**. The code repeatedly nudges the player 2–6 pixels or grants 50–200 ms windows so that inputs which are *almost* correct still succeed. Most of the "tight" feel comes from these windows.
 
 ## Tuning Constants (verbatim from Player.cs)
 
@@ -133,7 +133,7 @@ Celeste's units are pixels/second for speeds and pixels/second² for acceleratio
 | DuckWindMult | 0 (ducking negates wind) |
 | SpacePhysicsMult | 0.6 (low-gravity zones) |
 
-## Scene / Node Shape (Godot 4)
+## Scene / Node Shape
 
 ```
 Player (CharacterBody2D)
@@ -300,7 +300,7 @@ func _probe_wall() -> int:
     return 0
 ```
 
-The skeleton above is a structural translation for Godot; the exact per-frame update bodies from Player.cs were not fully retrievable (see evidence limitations). The constants, state IDs, and confirmed behaviors (corner correction loops, variable-jump window logic, forced wall-jump timers, stamina costs, squish safety) are extracted directly from the source.
+The skeleton above is a structural translation to GDScript, not a line-by-line port of the per-frame update bodies in `Player.cs`. The constants, state IDs, and confirmed behaviors (corner correction loops, variable-jump window logic, forced wall-jump timers, stamina costs, squish safety) are extracted directly from the source.
 
 ## Confirmed Behavioral Patterns to Replicate
 
@@ -322,7 +322,7 @@ The skeleton above is a structural translation for Godot; the exact per-frame up
 6. Implement dash with 8-way aim, cooldown, residual EndDashSpeed, and corner correction.
 7. Implement climb stamina with the three cost rates and tired threshold.
 8. Add forgiveness pass: upward corner correction on jump, dash nudges, jump-through assist, wall speed retention, squish-safety cascade.
-9. Rescale units if SummerEngine's pixels-per-meter differs from Celeste's native resolution: preserve ratios (e.g., DashSpeed ≈ 2.67× MaxRun; RunAccel ≈ 11× MaxRun).
+9. Rescale units if your game's pixels-per-meter differs from Celeste's native resolution: preserve ratios (e.g., DashSpeed ≈ 2.67× MaxRun; RunAccel ≈ 11× MaxRun).
 
 ## Tunables
 
@@ -358,9 +358,4 @@ After implementing, test each forgiveness system explicitly:
 
 ## Confidence
 
-`extracted` — All tuning values, state IDs, and confirmed behavioral patterns are taken directly from the retrieved Player.cs source. Per-state update-loop bodies from the middle of the 182 KB file were not retrievable (tool truncation); where the skeleton fills standard platformer patterns (e.g., jump-cut-on-release), this is noted as structural translation, not extracted code. Not yet verified inside SummerEngine.
-
-## Evidence
-
-- sources/web/celeste-player-cs/source.md — primary source record: constants tables, state machine, confirmed behavioral snippets, retrieval limitations.
-- sources/x/valigo-celeste-movement/source.md — originating post and primary-source identification.
+`extracted` — All tuning values, state IDs, and confirmed behavioral patterns come from Celeste's publicly released `Player.cs`. Where the skeleton fills in standard platformer patterns (for example jump-cut-on-release), it is a structural translation, not extracted code. Not yet verified inside Summer Engine.

package/library/skills/celeste-momentum-platforming/resource.yaml

@@ -9,7 +9,7 @@ use_when:
   - "my 2D platformer controller feels unfair or unresponsive"
 do_not_use_when:
   - "3D character controllers, physics-driven RigidBody movement, or games that want floaty arcade jump physics over momentum precision"
-  - "intake from the gamedev-knowledge pipeline (source-cited, pipeline-validated, not yet exercised in-engine by the Summer team) — verify results in the engine as you would any technique"
+  - "you need an in-engine verified controller — this one is source-cited but not yet exercised in Summer Engine; verify results in the engine before relying on it"
 facets:
   lifecycle:
     - build

package/library/skills/character-animation-wiring/SKILL.md

@@ -172,7 +172,7 @@ func run(ctx):
 
 That is the mechanism; a full audio-synced viseme timeline is `facial-and-lipsync`. Bone-track keyframes work the same way through `animate()` v2 — `ctx.animate(character, "Skeleton3D:Head/rotation", keys, "nod")` creates a proper bone rotation track (the helper owns the quaternion conversion; never hand-build quaternion tracks).
 
-## Step 6 — Root motion, honestly
+## Step 6 — Root motion
 
 Meshy/mocap locomotion clips translate the root bone forward (Meshy `run` moves ~5m per cycle). Two valid setups — **pick one, never both**:
 
@@ -185,7 +185,7 @@ Root motion CANNOT be judged from the editor state. Playtest it: `summer_play`,
 
 ## Raw lane — the same wiring on older engines
 
-Every class above is script-bound; `ctx.anim_state_machine` is convenience, not capability. The raw locomotion wiring, verbatim the calls that matter:
+Every class above is script-bound; `ctx.anim_state_machine` is convenience, not capability. The raw locomotion wiring:
 
 ```gdscript
 func run(ctx):

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

@@ -11,31 +11,21 @@ paths: ["assets/characters/**", "assets/models/**", "**/*.tscn", "**/*.gd"]
 
 # Character Model — T-Pose to Rigged Humanoid, Gated
 
-This is the **canonical Meshy auto-rig pipeline**. It produces a humanoid `.glb` with a Meshy-compatible skeleton that `generate-motion` can drive directly. The work is split into two paid passes with a **mandatory user-review gate between them** — the rig pass is more expensive and locks the topology, so the user must see the un-rigged preview and approve before you spend on the rig.
+This is the canonical auto-rig pipeline. It produces a humanoid `.glb` with a skeleton that `generate-motion` can drive directly. The work is two paid passes with a **mandatory user-review gate between them**: the rig pass costs more credits and locks the topology, so the user must see the un-rigged preview and approve it first.
 
 The whole flow:
 
 ```
-1. T-pose reference image    →  summer_generate_image                          (~$0.05, ~10s)
-2. Un-rigged 3D mesh         →  summer_generate_3d(image-to-3d)                (~$0.50, ~60s)
+1. T-pose reference image    →  summer_generate_image                          (~10s)
+2. Un-rigged 3D mesh         →  summer_generate_3d(image-to-3d)                (~60s)
 3. ── USER REVIEW GATE ──
-4. Rigged .glb               →  summer_generate_3d(image-to-3d, rig=true)      (~$1.00, ~90s)
+4. Rigged .glb               →  summer_generate_3d(image-to-3d, rig=true)      (~90s)
 5. Import → editor RESTART → wire as CharacterBody3D / Node3D
 6. Hand off to generate-motion for clips
 ```
 
 The animation skill (`generate-motion`) requires a rigged humanoid; a static `.glb` won't drive motion.
 
-## Web Chat / Public Orchestrator Equivalent
-
-When this skill is running inside the PublicSummerEngine chat orchestrator, use the chat-native tools directly instead of sending the user to Studio:
-
-```
-generateImage -> createCharacter -> checkGenerationStatus/meshyJobStatus -> listUserAssets readiness -> rigModel if needed -> generateAnimation -> meshyJobStatus -> importAssets -> import-character
-```
-
-Use Studio only when the user explicitly asks for visual/manual picking or when chat-side generation fails. The recovered working flow used `createCharacter`, confirmed the rig had `hasMeshyRigTask` or `animationsReady:true`, then generated `idle`, `walk`, `run`, `jump`, and `attack`, imported the rig plus child animation GLBs into `res://characters/<slug>/`, then wired playback from the imported GLB AnimationPlayers/libraries. If `generateAnimation` returns `animations_preparing`, wait, poll/list the rig asset again, and retry instead of routing to Studio. Keep this path repeatable for "animated character", "3D character with animations", "walking enemy", and similar prompts.
-
 ## When to use
 
 - "Make a knight character for the player to control."
@@ -121,11 +111,11 @@ Before paying for the rig pass, surface the un-rigged mesh:
 
 > Un-rigged knight mesh ready: `res://assets/characters/knight_unrigged.glb` (~12k tris, [preview link]).
 >
-> Next step is the **rig pass** (~$1.00, ~90s, Meshy auto-rig). It locks the topology and adds a skeleton compatible with `generate-motion`. Once you approve I'll run it.
+> Next step is the **rig pass** (uses credits, ~90s). It locks the topology and adds a skeleton compatible with `generate-motion`. Once you approve I'll run it.
 >
 > **Approve the mesh and proceed to rig?** Or regenerate the mesh first (different prompt, different polycount, different model)?
 
-If the user wants changes, loop back to step 1 or 2. Do NOT silently run the rig pass — it doubles the cost and locks the design.
+If the user wants changes, loop back to step 1 or 2. Do NOT silently run the rig pass — it spends more credits and locks the design.
 
 ### 4. Run the rig pass
 
@@ -205,17 +195,16 @@ The imported `.glb` includes its own `Skeleton3D` and `AnimationPlayer` (empty l
 
 ### 7. Hand off to animation
 
-> Knight is wired at `./World/Knight` with a Meshy-rigged skeleton. `rigAssetId` saved.
+> Knight is wired at `./World/Knight` with an auto-rigged skeleton. `rigAssetId` saved.
 >
 > Next: `generate-motion` to add idle / walk / run / attack
 > clips. Example call: `summer_generate_motion(rigAssetId: "<saved id>",
-> backend: "meshy-library", motionName: "walk")`. Custom prompt-driven motion
-> is not shipped; hand-author one-off moves in Summer Engine or import a
-> licensed clip.
+> backend: "meshy-library", motionName: "walk")`. For custom actions, use
+> `text-to-motion` (`backend: "text-to-motion"`).
 
 ## Anti-patterns
 
-- **Skipping the user-review gate.** Doubles cost, locks the design, and removes the user's chance to course-correct cheaply.
+- **Skipping the user-review gate.** Spends the rig credits, locks the design, and removes the user's chance to course-correct cheaply.
 - **Generating the mesh from a non-T-pose image.** Locomotion will look broken (inverted knees, snapped elbows). Always re-pose first.
 - **Forgetting the editor restart.** Animations will appear to bind successfully but play to a stale skeleton — the character T-poses motionless. The fix is always restart, never code.
 - **Wrapping a cinematic NPC in CharacterBody3D.** Wastes physics ticks; use Node3D.
@@ -225,7 +214,7 @@ The imported `.glb` includes its own `Skeleton3D` and `AnimationPlayer` (empty l
 
 ## Edge cases
 
-- **Multiple characters share a silhouette.** Generate the rig once, then re-skin via texture swap (cheaper than re-rigging). See `character-model` retexture flow (TBD) — for now, route to `asset-strategy`.
+- **Multiple characters share a silhouette.** Generate the rig once, then re-skin via texture swap (cheaper than re-rigging): generate a new albedo and assign it as a material override.
 - **Character has wings, tail, extra limbs.** Meshy's humanoid rig only weights the standard skeleton — extras sag. Either prompt them as static (e.g. cape held by physics in-engine) or hand-rig in Blender post-export.
 - **Child / dwarf / giant.** Generate at correct proportions in the T-pose; the rig retargets cleanly. Locomotion clips from `generate-motion` will retarget but stride length needs `playback_speed` tuning on the AnimationPlayer.
 - **First-person hands-only character.** Generate just hands + forearms in T-pose; rig pass still works. See `fps-controller` for first-person wiring.
@@ -233,20 +222,20 @@ The imported `.glb` includes its own `Skeleton3D` and `AnimationPlayer` (empty l
 
 ## Fallback (no MCP)
 
-1. Generate the T-pose reference at the Summer dashboard (or any image gen — Midjourney, nano-banana web, DALL-E).
-2. Upload to Meshy at meshy.ai → Image to 3D → enable rigging.
+1. Generate the T-pose reference in the Summer dashboard.
+2. Run image-to-3D with rigging enabled in the Summer dashboard.
 3. Download the `.glb`.
 4. Drop into `res://assets/characters/`; Summer Engine's Import dock picks it up.
 5. Restart the editor.
 6. Wire as CharacterBody3D / Node3D in Summer Engine manually.
 
-The output is identical to the MCP path — same Meshy skeleton, same compatibility with `generate-motion` (which has its own dashboard fallback).
+The output matches the MCP path — same skeleton, same compatibility with `generate-motion` (which has its own dashboard fallback).
 
 ## Handoff
 
 After the rigged character is wired:
 
-> `Knight` is at `./World/Knight` with a Meshy-rigged skeleton. Next:
+> `Knight` is at `./World/Knight` with an auto-rigged skeleton. Next:
 > - **Animations:** `generate-motion` for idle / walk / run / attack. Pass the `rigAssetId` returned in step 4.
 > - **State machine:** after a few clips exist, `animation-tree` for idle → walk → run blends.
 > - **Player input:** if this is the player, wire WASD + mouse via `fps-controller` or a third-person controller skill.

package/library/skills/character-movement/SKILL.md

@@ -207,7 +207,7 @@ integration handed off for a playtest, not an incomplete one.
    Referencing an unbound action is a silent no-op that reads as "controls dead".
 5. Compile-check, then run and watch it move. Feel is a user call, not a still frame.
 
-## 2D side-scroller controller (the 40% every 2D game shares)
+## 2D side-scroller controller
 
 ```gdscript
 extends CharacterBody2D

package/library/skills/character-movement/references/movement-3d.md

@@ -84,7 +84,7 @@ Set its `collision_mask` to your Level layer only (not the player).
 Third-person differences from FPS:
 - Mouse motion rotates the `CameraController` (orbit), not the body.
 - The visual wrapper rotates to face the MOVEMENT direction, decoupled from the camera.
-  Because imported characters face Godot forward `-Z`, lerp
+  Because imported characters face the engine forward `-Z`, lerp
   `CharacterRotationRoot.rotation.y` toward `atan2(-direction.x, -direction.z)`.
 - Rotate only `CharacterRotationRoot.rotation.y`. Do not yaw the CharacterBody3D or add a
   compensating 180-degree model rotation. The package already normalizes forward to `-Z`.

package/library/skills/character-portrait/SKILL.md

@@ -5,7 +5,7 @@ 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_generate_image summer_search_assets summer_import_from_url summer_set_prop summer_set_resource_property
 paths: ["assets/**", "art/portraits/**", "ui/portraits/**"]
 ---
 
@@ -62,7 +62,7 @@ background: muted painterly gradient, dark teal to deep brown, no scene detail
 style: semi-realistic painterly, soft edges, oil-painting feel
 ```
 
-Note there is no aspect line. `summer_generate_image` has no size or aspect argument — every MCP image comes back at the server's 1:1 default. Bust framing reads fine square, which is why this skill works over MCP at all; if the cast needs true portrait framing, generate in the Summer dashboard (which exposes aspect ratio) and bring the results back with `summer_import_from_url`, or crop after. Whichever you pick, do it for the *whole* cast — mixed aspect is as visible as mixed lighting.
+Note there is no aspect line. `summer_generate_image` has no size or aspect argument — every MCP image comes back at the server's 1:1 default. Bust framing reads fine square; if the cast needs true portrait framing, generate in the Summer dashboard (which exposes aspect ratio) and bring the results back with `summer_import_from_url`, or crop after. Whichever you pick, do it for the *whole* cast — mixed aspect is as visible as mixed lighting.
 
 Every subsequent portrait in this cast appends the anchor to the prompt verbatim. **Do not edit the anchor mid-cast** unless the user explicitly says "I want the new ones to look different."
 
@@ -86,7 +86,7 @@ The character description should include: identity (age, build, hair, distinctiv
 
 ### 4. Confirm and call
 
-> Generating Aria the witch portrait — 1 image, ~$0.02, model nano-banana-2, anchor locked from `.summer/portrait-anchor.md`. OK?
+> Generating Aria the witch portrait — 1 image (uses credits), model nano-banana-2, anchor locked from `.summer/portrait-anchor.md`. OK?
 
 ```
 summer_generate_image(
@@ -96,7 +96,7 @@ summer_generate_image(
 )
 ```
 
-`style: "none"` because the anchor's "semi-realistic painterly" already specifies style. Be clear about what the preset actually does though: only `cartoon` and `anime` append anything to the prompt, and `realistic` / `none` append nothing — any other value is coerced to `none`. So the preset cannot "fight" a painterly anchor; it just does nothing either way, and every bit of the look has to be in the prompt.
+`style: "none"` because the anchor's "semi-realistic painterly" already specifies style. Only `cartoon` and `anime` append anything to the prompt, and `realistic` / `none` append nothing — any other value is coerced to `none`. So the preset cannot "fight" a painterly anchor; it just does nothing either way, and every bit of the look has to be in the prompt.
 
 `options={ image_size: ... }` is dropped without an error — see the anchor note above.