summer-engine 3.4.0 → 3.4.1

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

@@ -33,15 +33,17 @@ export command.
 1. Read `engineBinaryPath` from `summer_get_project_context`.
 2. Resolve the matching export-template directory for that exact Summer
    technical base.
-3. Inventory the installed templates and any `custom_template/release` paths
-   already configured in `export_presets.cfg`.
+3. Inventory the installed templates (`summer_export_templates` lists them and
+   installs Summer's macOS, Windows and web templates) and any
+   `custom_template/release` paths already configured in `export_presets.cfg`.
 4. Build a capability table with `available`, `missing prerequisite`, or
    `impossible on this build` for every requested target.
 
-A stock Summer 4.6.1 Mono install has only the macOS template. Web export is
-incompatible with that Mono build. Windows, Linux, Android, and iOS require a
-matching custom template or an external CI/build environment, plus their
-platform toolchains where applicable.
+A stock Summer Mono install ships only the macOS template. Web export is
+incompatible with that Mono build. Run `summer_export_templates` before marking
+another target missing: it installs Summer's macOS and Windows templates. Linux,
+Android, and iOS require a matching custom template or an external CI/build
+environment, plus their platform toolchains where applicable.
 
 **Hard gate:** an absent template or toolchain means the target is unavailable.
 Do not create its preset, recommend it as a local option, or invoke an export
@@ -55,7 +57,8 @@ Offer only targets marked `available` by step 1. Record other requested
 destinations as blocked follow-ups with their exact prerequisite.
 
 > Locally proven targets: **macOS**. Requested but blocked: **Windows**
-> (matching template or external CI), **Web** (non-Mono build), **Android**
+> (install the template with `summer_export_templates`), **Web** (non-Mono
+> build), **Android**
 > (template + Android toolchain). Which proven target should I prepare?
 
 Each destination has a different list. Multiple destinations = multiple lists. Don't shortcut — the iOS list does not satisfy the Steam list.
@@ -145,7 +148,7 @@ Build config:
 
 #### c) Web (HTML5) — unavailable on the stock Mono build
 
-Do not recommend or attempt this target from the stock Summer installation.
+Do not recommend or attempt this target from the stock Mono installation.
 Route it to a verified non-Mono Summer-compatible build environment first.
 Once that prerequisite is proven, these browser constraints apply:
 
@@ -157,7 +160,7 @@ Once that prerequisite is proven, these browser constraints apply:
 Build config:
 - Export preset: **Web**.
 - Output `.html` + `.wasm` + `.pck` + `.js`.
-- Disable: "Variant: Editor support", "Encryption". Keep: "GLES3 Fallback to GLES2" if targeting old browsers.
+- Disable: "Variant: Editor support", "Encryption".
 
 Known traps:
 - Audio: Chrome blocks autoplay. First user click must trigger audio context resume.
@@ -168,7 +171,7 @@ Known traps:
 | Asset | Resolution / Format |
 |---|---|
 | App icon | 1024×1024 PNG (Apple generates the rest) |
-| Launch screen | Storyboard (Godot generates) |
+| Launch screen | Storyboard (the engine generates it) |
 | Screenshots | 6.5" iPhone: 1242×2688 / 2688×1242 (≥ 3); 12.9" iPad if iPad-eligible |
 | App Store description | text per locale, ≤ 4000 chars |
 | Keywords | ≤ 100 chars, comma-separated |
@@ -230,13 +233,14 @@ For each preset:
 | `texture_format/etc2_astc` | `true` for mobile | Smaller texture compression |
 | `application/short_version` | matches `application/config/version` | Steam reads it |
 | `script_encryption_key` in `export_credentials.cfg` | set only when the user explicitly chooses script encryption | The similarly named preset field does not exist |
-| `application/icon` | path to your `.ico` / `.icns` / `.png` | Otherwise generic Godot icon ships |
+| `application/icon` | path to your `.ico` / `.icns` / `.png` | Otherwise the default engine icon ships |
 
 ### 6. Propose the build sequence
 
-> Capability proof: macOS available locally; Windows and Linux require external
-> CI; Web is unavailable on this Mono build. Pre-flight is clean for the macOS
-> preset. May I produce that one proven build now?
+> Capability proof: macOS available locally; Windows needs its template
+> (`summer_export_templates`); Linux requires external CI; Web is unavailable
+> on this Mono build. Pre-flight is clean
+> for the macOS preset. May I produce that one proven build now?
 
 ### 7. Produce a proven build
 
@@ -270,14 +274,14 @@ To enable another target, prove one of these before returning to step 2:
 
 ### Export-option cautions
 
-- **`script/encryption_key` does not exist.** The real key is `script_encryption_key`, and it lives in a separate `export_credentials.cfg`, not `export_presets.cfg` (`editor/export/editor_export.cpp:101,372-373`). Writing the wrong name produces an **unencrypted build with no error at all**.
+- **`script/encryption_key` does not exist.** The real key is `script_encryption_key`, and it lives in a separate `export_credentials.cfg`, not `export_presets.cfg`. Writing the wrong name produces an **unencrypted build with no error at all**.
 - **There is no `debug` field in a preset.** Debug versus release is chosen by `--export-debug` versus `--export-release`, nothing else.
 
 On Apple Silicon, `binary_format/architecture="arm64"` is the natural guess, and it fails leaving a **0-byte `.app` that looks like success**. Only `"universal"` ships.
 
 See `headless-scripting` for the wider pattern this is one instance of.
 
-If the user is on a CI system (GitHub Actions etc), this is the right place to point them at a cross-compile workflow — Godot can export Windows + Linux from a Linux runner.
+If the user is on a CI system (GitHub Actions etc), point them at a cross-compile workflow: the engine can export Windows and Linux from a Linux runner.
 
 ### 8. Verify each build
 
@@ -354,7 +358,7 @@ This skill produces release artifacts. Always ask before each build is invoked.
 
 ## Want a working starter?
 
-No template — this is a workflow. Each project's export config and store assets are project-specific. For the Steam-specific GodotSteam GDExtension setup, see `deployment/steam-uploader/SKILL.md` (when shipped).
+No template — this is a workflow. Each project's export config and store assets are project-specific.
 
 ## See also
 
@@ -362,10 +366,5 @@ No template — this is a workflow. Each project's export config and store asset
 - `../../references/godot-version/godot-version.md` — Summer compatibility and
   export-template versioning
 - `../../references/collaborative-protocol/collaborative-protocol.md` — "May I write" pattern
-- `deployment/export-presets/SKILL.md` — preset config deep dive
-- `deployment/web-html5-export/SKILL.md` — HTML5-specific traps
-- `deployment/steam-uploader/SKILL.md` — `steamcmd` + GodotSteam (when shipped)
-- `deployment/itch-uploader/SKILL.md` — `butler` workflow (when shipped)
-- `deployment/mobile-export/SKILL.md` — iOS / Android specifics (when shipped)
-- `asset-pipeline/attribution-and-licensing/SKILL.md` — community asset attribution
-- `performance/tune-performance/SKILL.md` — pre-ship performance pass
+- `headless-scripting` — the headless CLI pattern the export command follows
+- `tune-performance` — pre-ship performance pass

package/library/skills/fabricating-assets/SKILL.md

@@ -24,7 +24,7 @@ Three facts shape every use:
 | Blockout / placeholder | `scene-scripting` primitives or CSG | fabricate | Must be instant and in-scene; no process spawn is justified |
 | Generic hard-surface prop ("a barrel") | `summer_search_assets` → `summer_import_asset` (`prop-model`) | `summer_generate_3d` | The free library plus `target_size` beats paid generation and a 2-minute wait, in a consistent style |
 | Bespoke prop ("the artifact from our GDD") | `summer_generate_3d` | fabricate | Image-to-3D is exactly what generation is for; fabricate when exact dimensions or parametric variants matter |
-| **Modular kit** (walls, pipes, fences, rails that snap) | **fabricate** | library kit (`environment-kit`) | Generation cannot hold dimensions and style across 30 pieces; array + boolean + bevel + one material is the classic kit workflow |
+| **Modular kit** (walls, pipes, fences, rails that snap) | **fabricate** | generated kit (`environment-kit`) | Generation cannot hold dimensions and style across 30 pieces; array + boolean + bevel + one material is the classic kit workflow |
 | Characters (rigged, animated) | `summer_generate_3d` (`character-model`) | library | Scripted organic modelling is the documented failure mode; fabrication has no path to competitive organics blind |
 | Environments / terrain | in-engine terrain + library set dressing | generation for landmarks | Terrain wants interactive tools; dressing wants scatter |
 | Materials / textures / skies | library (`summer_import_hdri`, texture packs) | generation | Fabricate only to bake a procedural material to images |

package/library/skills/facial-and-lipsync/SKILL.md

@@ -13,10 +13,10 @@ paths: ["**/*.gd", "**/*.tscn", "**/*.tres"]
 
 Half generative, half authored. The *generative* half: an audio file (TTS via `summer_generate_audio` with `capability: "text_to_speech"`) goes through a phoneme-extraction tool (Summer does NOT wrap one — you run it externally), out comes a viseme timeline — a list of `{ phoneme, start_time, duration }` triples. The *authored* half: the character's face mesh must have BlendShapes named for the standard viseme set, or the timeline has nothing to drive. Without both halves, you get a talking robot.
 
-The 2026 production stack:
+The pipeline:
 
 1. **Audio in** — `.wav`/`.mp3` from `summer_generate_audio({capability: "text_to_speech", ...})` or imported VO.
-2. **Phoneme extraction** — done OUTSIDE Summer. Recommended: **Rhubarb Lip Sync** (open source, the industry standard for game-dev lipsync; outputs JSON with mouth-shape cues over time). Alternatives: gentle, allosaurus, or a Whisper-phoneme model on Replicate / Hugging Face. There is no `summer_*` MCP for this in the current engine.
+2. **Phoneme extraction** — done OUTSIDE Summer. Recommended: **Rhubarb Lip Sync** (open source, widely used for game lipsync; outputs JSON with mouth-shape cues over time). Alternatives: gentle, allosaurus, or a Whisper-phoneme model on Replicate / Hugging Face. There is no `summer_*` MCP for this in the current engine.
 3. **Viseme mapping** — phonemes / Rhubarb cues → Oculus / Apple ARKit viseme set (15 standard shapes covers English).
 4. **BlendShape driver** — at runtime, lerp the mesh's BlendShape weights along the timeline, synced to audio playback.
 5. **Optional emotional layer** — separate BlendShape track for `smile`, `brow_raise`, `eye_squint` etc., authored in code or at clip-edit time.
@@ -122,7 +122,7 @@ Rhubarb mouth-shape → ARKit viseme cheat sheet (apply during the bake step):
 
 **Cloud fallback:** a Whisper-phoneme model on Replicate or a Hugging Face inference endpoint will emit ARPAbet phonemes with timestamps. Then map ARPAbet → ARKit visemes via the table in the Reference card section. More accurate than Rhubarb on noisy audio; slower and costs cents per minute.
 
-Cost: Rhubarb is free + ~5s CPU per 30s clip locally. Cloud fallback ~$0.02 / minute, ~5s wall-clock for a 30s clip.
+Rhubarb is free and takes ~5s of local CPU per 30s clip. The cloud fallback is billed per minute by its provider and takes ~5s for a 30s clip.
 
 ### 4. Persist the viseme track as an AnimationLibrary entry
 
@@ -254,7 +254,7 @@ Driven from gameplay events; orthogonal to the lipsync layer.
 
 ### Phoneme → viseme mapping (for hand-rolled extraction)
 
-If the user has a CMUDict-style phoneme list and wants to map manually, this is the table to apply.
+If the user has a CMUDict-style phoneme list, map it with the ARPAbet column of the table above.
 
 ### Pitfalls
 
@@ -300,7 +300,7 @@ production speech recognition or photoreal lip sync.
 - For dialogue scripts and conversation flow, `design-npc`.
 - For the AnimationTree this layer composes into, `animation-tree`.
 - For idle blinks, saccades, and head-tracking that complement lipsync, `procedural-animation`.
-- For full performance capture (face + body together), out of scope — see Meshy's mocap docs or external pipelines.
+- Full performance capture (face and body together) is out of scope; use an external capture pipeline.
 
 ## See also
 

package/library/skills/fps-controller/SKILL.md

@@ -5,14 +5,14 @@ license: MIT
 compatibility: [Cursor, Claude Code, Windsurf, Codex]
 category: character-controllers
 user-invocable: false
-template-id: template-3d-fps
+template-id: template-3d-fps-old-school
 allowed-tools: Read Grep summer_get_scene_tree summer_add_node summer_set_prop summer_set_resource_property summer_input_map_bind summer_save_scene summer_get_script_errors
 paths: ["**/*.gd", "**/*.tscn"]
 ---
 
 # FPS Controller for Summer Engine
 
-The canonical first-person controller. Coyote time, jump buffering, air control, external-velocity, the works. This is the production minimum for an FPS that doesn't feel like a Unity tutorial — it follows the shipping FPS standard for movement (gravity, grace timers, separate ground/air acceleration, external force accumulator) so the player never says "this feels stiff" or "I jumped right at the edge and died unfairly".
+The canonical first-person controller: coyote time, jump buffering, air control and external velocity. It follows the standard shipping FPS movement model (asymmetric gravity, grace timers, separate ground/air acceleration, an external force accumulator), so the player never says "this feels stiff" or "I jumped right at the edge and died unfairly".
 
 ## Scene Structure
 
@@ -24,7 +24,7 @@ Player (CharacterBody3D)
 └── (optional) RayCast3D      # ground / interaction probe
 ```
 
-The Head/Camera split is the industry-standard movement model: yaw rotates the body, pitch rotates only the head. Don't pitch the body or you get tilted capsules and slope-collision bugs.
+The Head/Camera split is the standard: yaw rotates the body, pitch rotates only the head. Don't pitch the body or you get tilted capsules and slope-collision bugs.
 
 ## Step-by-Step Setup via MCP
 
@@ -48,7 +48,7 @@ summer_set_resource_property(scenePath="res://main.tscn", nodePath="./World/Play
 summer_set_resource_property(scenePath="res://main.tscn", nodePath="./World/Player/Collision", resourceProperty="shape", subProperty="height", value="1.8")
 ```
 
-Two things the older version of this skill got wrong:
+Two rules for these calls:
 
 - **`scenePath` is required** on `summer_add_node`, `summer_set_prop`,
   `summer_set_resource_property` and `summer_save_scene`. Omit it and the call
@@ -61,7 +61,7 @@ Two things the older version of this skill got wrong:
   and external `.tres` resources take the same path. Structural failures are
   explicit — `node not found`, `property is not a resource`, or `resource is
   null` when the property was never assigned — but a bad value shape is silent
-  on current engines: a JSON object instead of a Godot literal string, a
+  on current engines: a JSON object instead of an engine variant string, a
   misspelled `key`/`subProperty`, or a wrong-typed value returns `ok:true` yet
   no-ops or coerces destructively. Assign the resource first, pass class names
   and `Vector3(...)`/`Color(...)` strings, and confirm in the saved `.tscn`,
@@ -234,18 +234,18 @@ func add_external_velocity(impulse: Vector3) -> void:
 | `fall_gravity_multiplier` | `1.4` | Snappier descent than ascent (variable-jump-feel staple). |
 | `ground_accel` / `ground_friction` | `80 / 90` | Crisp start, near-instant stop. |
 | `air_accel` / `air_friction` | `25 / 5` | Reduced air control + minimal air drag. |
-| `coyote_time` | `0.1` | Standard 0.08–0.15s grace — invisible to players, fixes 60% of "unfair death" complaints. |
+| `coyote_time` | `0.1` | Standard 0.08–0.15s grace — invisible to players, removes most "unfair death" complaints. |
 | `jump_buffer_time` | `0.1` | Same window the other direction. |
 | `mouse_sensitivity` | `0.002` | Default raw multiplier; expose via settings. |
 | `external_damping` | `8.0` | Knockback decays over ~0.5s. |
 
 ## Why Each Feature Matters
 
-**Coyote time (~0.1s)** — Players judge ledges by what they see, not by frame-perfect collision. A small grace period after walking off a ledge where jump still works fixes the "I jumped right at the edge and died unfairly" complaint that breaks 60% of new players' tutorials. Cost: 3 lines. Industry-standard window is 0.08–0.15s — short enough to be invisible, long enough to mask the imprecision of human reaction time.
+**Coyote time (~0.1s)** — Players judge ledges by what they see, not by frame-perfect collision. A small grace period after walking off a ledge where jump still works fixes the "I jumped right at the edge and died unfairly" complaint. Cost: 3 lines. The usual window is 0.08–0.15s — short enough to be invisible, long enough to mask the imprecision of human reaction time.
 
 **Jump buffering (~0.1s)** — Pressing jump 50ms before landing should not be punished. Buffer the input for ~0.1s and fire on touchdown. Without this, fast-moving players feel like the controller "ate their input" — they pressed jump, they saw nothing happen, they blame the game. With it, every "near-miss" jump becomes a successful one. Cost: 4 lines.
 
-**Air control with reduced acceleration (~30% of ground)** — Zero air control feels like ice; the player commits to a direction at jump-takeoff and can't course-correct. Full air control feels like a Unity tutorial; momentum is meaningless and a strafe-jump cancels itself. The shipping FPS standard sits around 25–30% of ground accel: enough to course-correct mid-jump, not enough to cancel realistic momentum. The `move_toward` formulation lets designers tune this with one number — `air_accel` — without forking code.
+**Air control with reduced acceleration (~30% of ground)** — Zero air control feels like ice; the player commits to a direction at jump-takeoff and can't course-correct. Full air control feels weightless; momentum is meaningless and a strafe-jump cancels itself. The shipping FPS standard sits around 25–30% of ground accel: enough to course-correct mid-jump, not enough to cancel realistic momentum. The `move_toward` formulation lets designers tune this with one number — `air_accel` — without forking code.
 
 **External velocity accumulator** — Knockback, explosions, jump pads, conveyor belts, wind volumes, and grapple-yanks must not fight player input. Storing them in a separate `external_velocity`, applying once per frame, and decaying via `move_toward(0, damping * delta)` means an explosion shoves the player and then control returns smoothly — no "stuck at terminal velocity" or "input cancels the punch" bugs. The subtract-previous-contribution trick (line 1 of `_physics_process`) is the production fix that prevents accumulation when the player is also sprinting; it's the kind of detail you only learn by shipping multiplayer. Public API (`add_external_velocity`) means any system — AOE attack, jump pad scene, grapple ability — can shove the player with one call, no coupling.
 
@@ -255,7 +255,7 @@ func add_external_velocity(impulse: Vector3) -> void:
 
 Once the skeleton is in, designers tune by feel. Common targets:
 
-**Snappy military shooter (industry-standard FPS feel):**
+**Snappy military shooter:**
 - `walk_speed = 5.5`, `sprint_speed = 8.0`
 - `ground_accel = 90`, `ground_friction = 100`
 - `air_accel = 20`, `air_friction = 4`
@@ -284,14 +284,14 @@ The skeleton doesn't change — only the `@export` defaults. That's the point of
 - **Pressing jump just before landing does nothing** — `_jump_buffer_timer` is being decremented to zero before the player touches floor. The buffer must NOT be cleared by anything except a successful jump.
 - **Knockback compounds forever** — `_prev_external_applied` isn't being subtracted. Step 1 of `_physics_process` MUST run before gravity, or external impulses pile up frame after frame.
 - **Knockback decays too fast / too slow** — tune `external_damping`. `8.0` decays a 5 m/s impulse to near-zero in ~0.6s. Lower = longer hangtime.
-- **Air control feels like ice OR like a Unity tutorial** — `air_accel` is the only knob. Industry-standard is 20–30% of `ground_accel`. Zero = ice. Equal = arcade-y. The shipping FPS standard sits around 25.
+- **Air control feels like ice OR weightless** — `air_accel` is the only knob. The usual range is 20–30% of `ground_accel`. Zero = ice. Equal = arcade-y.
 - **Camera tilts on slopes** — pitch is on the body instead of the Head. Pitch only on `Head`; yaw only on `Player`.
 - **Camera rolls when looking around** — you're calling `rotate_x` on something that's already rotated on Y. Fix: only ever rotate Y on Player and X on Head, never combine.
 - **Mouse look doesn't work** — `Input.mouse_mode` isn't set to `MOUSE_MODE_CAPTURED`, or another node is consuming `_input` before this script. Use `_unhandled_input` to be a good citizen.
 - **Mouse look feels laggy at low FPS** — sensitivity is being applied in `_physics_process`. Mouse-motion handling MUST stay in `_input` or `_unhandled_input` — those fire per-event, not per-physics-tick.
 - **Falling through floor** — floor needs a StaticBody3D + CollisionShape3D on the same physics layer as the player.
 - **Camera clipping geometry** — push `Camera.near` to ~0.05 or shrink the capsule radius slightly.
-- **Player jitters on slopes / stairs** — enable `floor_snap_length = 0.5` and `floor_max_angle = 0.785` (~45°) on the CharacterBody3D. Out of scope for this skeleton; see the character-body-tuning skill when it ships.
+- **Player jitters on slopes / stairs** — enable `floor_snap_length = 0.5` and `floor_max_angle = 0.785` (~45°) on the CharacterBody3D. Out of scope for this skeleton.
 
 ## Networking Note
 
@@ -312,8 +312,8 @@ The skeleton is intentionally ~90 lines. When you outgrow it, add features by *l
 - **Crouch.** Lerp the capsule height (e.g., 1.8 → 1.0) and the Head Y (1.6 → 0.9) over ~0.15s. Halve `walk_speed` while crouched. Block standing if a short upward shapecast hits ceiling.
 - **Sprint FOV punch.** Tween `Camera.fov` from 75 → 82 over 0.2s when sprint starts, back when it ends. The single cheapest "feel of speed" effect available.
 - **Slide.** When sprint + crouch are pressed together with horizontal speed above a threshold, lock direction to current velocity, set a `slide_timer`, and skip the wish-direction step. Apply slide-specific friction. Restore on timer expiry, ceiling clearance, or speed-below-threshold.
-- **Wallrun, dash, double-jump.** Each is its own override state. Build a state machine (see `scripting-patterns/state-machine-patterns/SKILL.md`) and let each state run its own `_physics_process` branch with an early `move_and_slide()` return. Don't pile them as `if/elif` in a single function.
-- **Camera shake.** Add a `trauma` float on the camera, accumulate via `add_trauma(amount)`, decay each frame, apply a randomized rotation offset proportional to `trauma * trauma`. Subtract the previous frame's shake offset before applying the new one to prevent drift. See the post-processing/screen-shake skill.
+- **Wallrun, dash, double-jump.** Each is its own override state. Build a state machine (see `gdscript-patterns`) and let each state run its own `_physics_process` branch with an early `move_and_slide()` return. Don't pile them as `if/elif` in a single function.
+- **Camera shake.** Add a `trauma` float on the camera, accumulate via `add_trauma(amount)`, decay each frame, apply a randomized rotation offset proportional to `trauma * trauma`. Subtract the previous frame's shake offset before applying the new one to prevent drift. See `game-feel`.
 
 Each of these is a separate skill or a separate function, not a fork of this script.
 
@@ -349,9 +349,10 @@ Then patch `project.godot` with the InputMap actions (`input/move_forward = { ..
 
 This skill writes scene nodes, an InputMap, and a `.gd` script. Always ask before applying. Group writes per phase: "May I add the Player + Collision + Head + Camera, bind WASD/jump/sprint, and attach `player_controller.gd`?"
 
-If the user asks for a "third-person FPS", flag the contradiction: FPS = first-person. Either clarify, or hand off to the `tps-controller` skill when it ships.
+If the user asks for a "third-person FPS", flag the contradiction: FPS = first-person. Either clarify, or hand off to `character-movement`, which has the third-person controller.
 
 ## See Also
 
-- `scripting-patterns/state-machine-patterns/SKILL.md` — once movement grows past this skeleton (slide, grapple, hover), refactor into a state machine instead of stuffing more branches into `_physics_process`.
-- `physics/character-body-tuning/SKILL.md` (when shipped) — slope handling, step-up, floor-snap.
+- `gdscript-patterns` — once movement grows past this skeleton (slide, grapple, hover), refactor into a state machine instead of stuffing more branches into `_physics_process`.
+- `character-movement` — 2D and third-person controllers.
+- `game-feel` — camera shake and hit feedback.

package/library/skills/fps-controller/resource.yaml

@@ -20,8 +20,6 @@ related:
   skills:
     - skill/character-movement
     - skill/camera-rigs
-  # Legacy frontmatter declared template-id: template-3d-fps (no such repo exists);
-  # mapped to the real repo template-3d-fps-old-school.
   templates:
     - template/3d-fps-old-school
 source: official

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

@@ -9,7 +9,7 @@ allowed-tools: Read Grep Edit Write summer_write_file summer_read_file summer_ge
 paths: ["**/*.gd", "**/*.tscn", "**/*.tres"]
 ---
 
-# /vfx — The Trio That Makes Games Feel Punchy
+# Game Feel — The Trio That Makes Hits Land
 
 Particles do not make a game feel good. Screen shake alone does not either.
 What makes a hit land is three systems firing on the same frame: a sub-frame
@@ -327,7 +327,7 @@ summer_connect_signal(scenePath="res://levels/world.tscn", emitter="./World/Enem
 
 ## Step 8 — Scaling intensity per hit weight
 
-The trio's whole magic is that the same code makes a glancing parry feel different from a critical hit. Calibrate the curve once:
+The same code makes a glancing parry feel different from a critical hit. Calibrate the curve once:
 
 | Hit type | `damage` (HP) | trauma | duck amount |
 |---|---|---|---|
@@ -343,7 +343,7 @@ Because trauma is squared inside the camera, the *felt* difference between 0.35
 
 ```
 summer_save_scene(scenePath="res://levels/world.tscn")
-summer_get_script_errors          # all three scripts parsed?
+summer_get_script_errors(path="res://scripts/vfx/hit_flash.gd")   # repeat for each of the three scripts
 summer_play
 # user reproduces a hit
 summer_get_debugger_errors        # runtime errors from the tweens / bus lookups
@@ -391,7 +391,6 @@ This skill writes 3 GDScript files and adds 1 node + 1 autoload entry. Always as
   version-sensitive API notes
 - `../../references/collaborative-protocol/collaborative-protocol.md` — "May I write" pattern
 - `../../references/gd-style/gd-style.md` — typed GDScript conventions
-- `audio/audio-direction/SKILL.md` — bus layout setup (prerequisite for ducking)
-- `post-processing/screen-shake/SKILL.md` — deeper trauma variants (Perlin noise, stacked sources)
-- `visual-effects/gpuparticles-3d-basics/SKILL.md` — particles to layer on top of the trio
-- `visual-effects/hit-impact-flashes/SKILL.md` — flash material variations beyond white pulse
+- `audio-direction` — bus layout setup (prerequisite for ducking)
+- `vfx-hit-spark` — particles to layer on top of the trio
+- `debugging-game-feel` — when the trio is installed and it still feels wrong

package/library/skills/gameskill/SKILL.md

@@ -15,9 +15,9 @@ You are being invoked at the end (or middle) of a game-development session. Turn
 
 Summer resolves skills in this order: the game project, then the user's agent skills directory, then the skills bundled with the Summer package. Pick the narrowest home that fits:
 
-1. **The game project** (default). Write `SKILL.md` into the project-scoped skills directory of the agent you are running in: `.claude/skills/<slug>/` for Claude Code, `.agents/skills/<slug>/` for Codex, `.cursor/rules/` for Cursor, `.windsurfrules` for Windsurf. `summer skills install --scope project` shows the exact path for the current agent. Commit it with the game.
+1. **The game project** (default). Write `SKILL.md` into the project-scoped skills directory of the agent you are running in: `.claude/skills/<slug>/` for Claude Code, `.agents/skills/<slug>/` for Codex, Cursor, Devin Desktop and the other agents that read the shared folder. `summer skills install --scope project` shows the exact path for the current agent. Commit it with the game.
 2. **The user's agent skills directory** when the lesson applies to every project on this machine (`~/.claude/skills/<slug>/`, `~/.agents/skills/<slug>/`). Do not edit skills that Summer installed there; they are overwritten on the next `summer setup`.
-3. **The Summer library** when the lesson is general enough for every Summer user. Only possible inside a checkout of the summer-engine agent repository: add `library/skills/<slug>/resource.yaml` and `library/skills/<slug>/SKILL.md` (flat slugs, no category folders), then run `npm run generate:registry` and `npm run validate:library`. Everything under `registry/generated/` and every plugin manifest is generated from `library/`; never hand-edit them. Outside that checkout, send the lesson through `summer_library_feedback` (or `summer tool library-feedback`) with the id of the closest existing skill so the maintainers can fold it in.
+3. **The Summer library** when the lesson is general enough for every Summer user. Only possible inside a checkout of the `summerengine/summer` repository: add `library/skills/<slug>/resource.yaml` and `library/skills/<slug>/SKILL.md` (flat slugs, no category folders), then run `npm run generate:registry` and `npm run validate:library`. Everything under `registry/generated/` and every plugin manifest is generated from `library/`; never hand-edit them. Outside that checkout, send the lesson through `summer_library_feedback` (or `summer tool library-feedback`) with the id of the closest existing skill so the maintainers can fold it in.
 
 Read the current project as ground truth. Working code from the real project beats invented examples.
 
@@ -32,7 +32,7 @@ Read the current project as ground truth. Working code from the real project bea
    - A GDScript idiom that beat the obvious approach
    - A UI layout that survived the design pass
    - A bug, its root cause and the fix that was not in any docs
-   - A Godot 4.x quirk (type inference, signal gotchas, plugin configuration)
+   - An engine quirk (type inference, signal gotchas, plugin configuration)
    - A spawning, AI or enemy pattern that worked
    - A performance fix with measured before and after
    - An asset workflow that beat the alternatives

package/library/skills/gdscript-patterns/SKILL.md

@@ -11,7 +11,7 @@ paths: ["**/*.gd"]
 
 # GDScript Patterns for Summer Engine
 
-When writing GDScript for Summer Engine projects, follow these patterns. They align with Godot 4.x conventions and work well with MCP scene operations.
+When writing GDScript for Summer Engine projects, follow these patterns. They match the engine's GDScript 4 conventions and work well with MCP scene operations.
 
 ## Type Hints
 
@@ -92,7 +92,7 @@ For health systems, input handling, and state machines, see [reference.md](refer
 
 ## Anti-patterns — introspection traps
 
-Godot's introspection API has Object-instance methods that look like they should work on script-class references. They don't. Calling them on a `const ScriptName = preload(...)` reference is a parse error, not a runtime no-op.
+The engine's introspection API has Object-instance methods that look like they should work on script-class references. They don't. Calling them on a `const ScriptName = preload(...)` reference is a parse error, not a runtime no-op.
 
 | Wrong | Right | Why |
 |---|---|---|
@@ -106,7 +106,7 @@ Godot's introspection API has Object-instance methods that look like they should
 
 ## Anti-pattern — `@onready var = $Path` on nodes that don't exist on every variant
 
-Godot resolves `$Path` (the `get_node` shorthand) at `@implicit_ready` time. If the node is missing from the current scene, you get `Node not found: "X" (relative to "Y")` errors before any of your `_ready()` runtime guards can run.
+The engine resolves `$Path` (the `get_node` shorthand) at `@implicit_ready` time. If the node is missing from the current scene, you get `Node not found: "X" (relative to "Y")` errors before any of your `_ready()` runtime guards can run.
 
 Common case: a script is shared by multiple scene variants where some variants have an optional child. Even if every code path that touches the variable has a `if inventory_ui:` guard, the `@onready` line itself errors at scene load.
 

package/library/skills/generate-motion/SKILL.md

@@ -11,7 +11,7 @@ paths: ["**/*.tscn", "**/*.tres", "**/*.gd"]
 
 # Generate Motion — Curated Meshy Library
 
-Picks a clip from a **curated mocap library** by name and wires it onto a Meshy-rigged humanoid. Fast (~30s) and cheap (~$0.10) and looks great because it's real mocap. The five short aliases that always work are `idle`, `walk`, `run`, `jump`, `attack`; anything else must be an exact library name — see the Reference card before you invent one.
+Picks a clip from a **curated mocap library** by name and wires it onto a Meshy-rigged humanoid. Fast (~30s), and it looks good because it is real mocap. The five short aliases that always work are `idle`, `walk`, `run`, `jump`, `attack`; anything else must be an exact library name — see the Reference card before you invent one.
 
 The target must be a **Meshy-rigged humanoid** — a `rigAssetId` from a prior `summer_generate_3d({ kind: "image-to-3d", imageUrl: "...", options: { rig: true } })` call. The result job includes `rigAssetId`. If the user points at a non-rigged mesh, stop and route to `asset-strategy` (or directly call `summer_generate_3d` with `options.rig: true`) before generating motion.
 
@@ -20,22 +20,6 @@ The target must be a **Meshy-rigged humanoid** — a `rigAssetId` from a prior `
 > (`backend: "text-to-motion"`) when the server has it enabled; otherwise fall
 > back to hand-authoring in Summer Engine or importing from Mixamo.
 
-## Web Chat / Public Orchestrator Equivalent
-
-In PublicSummerEngine chat, the equivalent direct tools are:
-
-```
-rigModel({ modelAssetId })
-generateAnimation({ rigAssetId, animationName })
-meshyJobStatus({ jobId })
-```
-
-If the character came from `createCharacter`, it may already be rigged and have `metadata.meshyRigTaskId`; generate animations directly against that rig asset. Verified animation names from the recovered production flow are `idle`, `walk`, `run`, `jump`, and `attack`. `fall` returned `invalid_animation`, so do not present it as a default.
-
-Before generating clips in PublicSummerEngine chat, confirm the rig asset listing/status exposes `hasMeshyRigTask` or `animationsReady:true`. If `generateAnimation` returns `animations_preparing`, wait, poll/list the rig again, and retry; this is the post-rig setup catching up, not a reason to send the user to Studio.
-
-After animation jobs complete, import the rig plus child animation assets together and wire them through `import-character`. Do not hand off to Studio unless the user asked for Studio/manual control or the direct chat tools fail.
-
 ## When to use this skill
 
 - "Add a walk animation to the goblin."
@@ -64,7 +48,7 @@ The result must include `rigAssetId: <id>` on a Meshy rig. If it shows `rigAsset
 
 ### 2. Confirm with the user before spending
 
-> I'm about to generate a "run" animation on `goblin_rigged` via meshy-library — about 30s, ~$0.10. OK?
+> I'm about to generate a "run" animation on `goblin_rigged` via meshy-library — about 30s, and it uses credits. OK?
 
 ### 3. Call the tool
 
@@ -107,7 +91,7 @@ If the character will use multiple clips, leave the AnimationPlayer in place —
 
 ## Confirmation gates
 
-- **Before generation:** state the motion name and est. cost (~$0.10). Wait for OK.
+- **Before generation:** state the motion name and that it uses credits. Wait for OK.
 - **Before attaching:** state which AnimationPlayer and which library slot. Wait for OK.
 - **After generation:** if the user hasn't seen the preview, link `previewUrl` and ask "land or regenerate?" before wiring it into the scene.
 
@@ -129,9 +113,8 @@ nothing like a tidy snake_case scheme — real names look like `Walking_Woman`,
 Plausible-looking names that do **not** resolve, verified against the resolver:
 `attack_sword`, `hit_react`, `death`, `sprint`, `block`, `dodge_left`,
 `crouch_idle`, `walk_back`, `run_strafe_left`, `jump_land`, `idle_combat`,
-`wave`, `dance`, `sit_idle`. They return `null` and the call errors. The tool's
-own description uses `attack_sword` as an example — that example is wrong; use
-`attack`.
+`wave`, `dance`, `sit_idle`. They return `null` and the call errors. For a sword
+attack, use `attack`.
 
 So: if the user asks for something outside the five aliases, do not guess a
 snake_case name. Either use one of the five, quote an exact raw library name you