summer-engine 1.3.1 → 1.4.0

package/skills/_tests/specs/brainstorm-game.md

@@ -0,0 +1,99 @@
+# Skill Spec: /brainstorm-game
+
+## Fixture
+
+- Empty Godot 4.5 / Summer Engine project, `project.godot` exists, no `.summer/` folder yet.
+- Summer MCP available.
+- Host file tools available (Read, Write, Edit).
+
+## Case 1: Happy Path — fresh idea, full brainstorm
+
+**Input:** "I want to make a game but I don't know what."
+
+**Expected behavior:**
+
+1. Skill asks the one opening question: "One sentence — what kind of game do you want to make?"
+2. (Simulated user reply: "Something like Hades, but cozy.")
+3. Skill recognizes Action-Combat anchor + cozy modifier, picks Action-Combat branch, but flags the tension: "Hades is tense, cozy is calm — let's pin which side wins."
+4. Skill walks: core loop candidate → user refinement → three mechanics (push back if user lists more) → one-phrase art direction → scope (recommend vertical slice).
+5. Skill drafts the 1-page brief inline, shows it to the user.
+6. Skill asks: "May I create `.summer/GameSoul.md` with this brief?"
+7. On yes, calls `Write .summer/GameSoul.md`.
+8. Skill ends with the routing question pointing to `/summer:design-mechanic` or similar.
+
+**Assertions:**
+
+- [ ] Skill asks ONLY the opening question first, no menu of options.
+- [ ] Skill picks ONE branch, not multiple; doesn't ask 6 questions in parallel.
+- [ ] Skill enforces the three-mechanic limit (pushes back if user lists more).
+- [ ] Brief includes all 8 fields: Pitch, Core loop, Three mechanics, Art direction, Scope, Win condition, "One thing this is NOT", Inspirations, Parked for later.
+- [ ] Skill asks "May I create `.summer/GameSoul.md`?" before writing.
+- [ ] Brief is shown inline before being written so the user can react.
+- [ ] Skill ends with a routing question to a next `/summer:` step.
+- [ ] Skill defaults to "vertical slice" scope when the user is unsure.
+
+## Case 2: Failure Path — `.summer/GameSoul.md` already exists
+
+**Fixture:** Same as Case 1, except `.summer/GameSoul.md` already exists with a previous game's brief.
+
+**Input:** "I want to brainstorm a new game."
+
+**Expected behavior:**
+
+- Skill reads the existing `.summer/GameSoul.md` first via `Read`.
+- Skill walks the brainstorm normally.
+- Before writing, skill detects the file exists and asks: "`.summer/GameSoul.md` already exists. May I overwrite it, or merge into a 'Revision 2' section below the existing brief?"
+- Does NOT silently overwrite.
+
+**Assertions:**
+
+- [ ] Skill reads existing `.summer/GameSoul.md` before drafting the new brief.
+- [ ] Skill shows the user what would change before writing.
+- [ ] Skill explicitly offers overwrite vs. merge — does not default-pick.
+- [ ] No `Write` call happens until the user answers.
+
+## Case 3: Edge Case — user pitches a multiplayer 4-player co-op horror RPG with crafting
+
+**Fixture:** Same as Case 1.
+
+**Input:** "I want a 4-player online co-op horror RPG with crafting, base-building, dialogue trees, and procedural worlds, kind of like Valheim meets Phasmophobia meets Disco Elysium."
+
+**Expected behavior:**
+
+- Skill catches the multiplayer flag (4-player co-op = scope explosion) and surfaces it explicitly: "Multiplayer is its own scope category — it roughly 3x's everything. Confirm: is multiplayer non-negotiable, or could a great single-player version land first and multiplayer come later?"
+- Skill enforces the three-mechanic constraint hard. Names which mechanics from the user's pitch are content vs. mechanics, e.g.: "crafting + base-building are systems, not mechanics; dialogue is a mechanic if choices change outcomes."
+- Skill states a sanity-check concern: "Procedural worlds + horror + RPG depth + multiplayer at vertical-slice scope is unrealistic. Suggest scoping to one of those four pillars."
+- Skill does NOT just write the brief with all five things in it.
+- Skill asks the user to pick the cut.
+
+**Assertions:**
+
+- [ ] Skill flags multiplayer explicitly and asks about negotiability before continuing.
+- [ ] Skill distinguishes "system/feature" from "mechanic" out loud.
+- [ ] Skill names a scope concern instead of writing the brief verbatim from the pitch.
+- [ ] Skill never writes a brief with more than three mechanics.
+- [ ] Skill offers a clear cut, not a vague "scope down" platitude.
+
+## Case 4: No Summer MCP / no host file write — fallback path
+
+**Fixture:** Same as Case 1, except the host has no file-write tool (read-only agent in a constrained environment).
+
+**Input:** "Help me brainstorm a game."
+
+**Expected behavior:**
+
+- Skill detects no write tool is available.
+- Walks the brainstorm normally.
+- Instead of asking "May I create `.summer/GameSoul.md`?", prints the full brief to the user with explicit save instruction: "Save this as `.summer/GameSoul.md` in your project root. Every Summer skill reads it."
+- Still ends with the routing question.
+
+**Assertions:**
+
+- [ ] Skill does NOT call a file-write tool that doesn't exist.
+- [ ] Skill prints the brief inline as a self-contained block.
+- [ ] Skill includes the explicit save instruction with the canonical path.
+- [ ] Skill still asks the user the brainstorm questions and the routing question.
+
+---
+
+This spec runs via `/skill-test brainstorm-game spec` (see `_meta/skill-test/SKILL.md`).

package/skills/_tests/specs/design-level.md

@@ -0,0 +1,113 @@
+# Skill Spec: /design-level
+
+## Fixture
+
+- Godot 4.5 / Summer Engine project, main scene already has a `World/Player` (CharacterBody3D) with FPS controller wired.
+- `.summer/GameSoul.md` exists; brief: "Action-combat game, three mechanics: dash, parry, double-jump. Vertical slice scope."
+- `.summer/mechanics/parry.md` exists.
+- No `levels/` folder yet.
+- Summer MCP available.
+
+## Case 1: Happy Path — design level 1, a combat encounter
+
+**Input:** "Design level 1, a 5-minute combat encounter that teaches parry."
+
+**Expected MCP tool sequence (in order):**
+
+1. `Read .summer/GameSoul.md` — anchor to the brief
+2. (Optional: `Read .summer/mechanics/parry.md` — anchor to the mechanic being taught)
+3. (Skill walks: type → teaching goal → pacing curve (5 beats with intensity numbers) → encounters list → secrets list → reward gating → spaces list)
+4. (Skill shows the node-tree skeleton inline)
+5. (Skill asks: "May I create `levels/level_01.tscn` with this skeleton?")
+6. `summer_create_scene(path="res://levels/level_01.tscn", root_type="Node3D", root_name="World")`
+7. `summer_add_node(parent="./World", type="Node3D", name="Geometry")` and children
+8. `summer_add_node(parent="./World", type="Node3D", name="Spawns")` and children
+9. `summer_add_node(parent="./World", type="Node3D", name="Triggers")` and Area3D children
+10. `summer_add_node(parent="./World", type="Node3D", name="Pickups")`
+11. `summer_add_node(parent="./World", type="Node3D", name="Secrets")`
+12. `summer_add_node(parent="./World", type="Node3D", name="Lighting")` with WorldEnvironment + DirectionalLight3D
+13. `summer_save_scene`
+14. (Skill asks: "May I create `.summer/levels/level_01.md` with the design doc?")
+15. `Write .summer/levels/level_01.md`
+16. `summer_get_script_errors`
+
+**Assertions:**
+
+- [ ] Skill reads `.summer/GameSoul.md` to anchor.
+- [ ] Skill reads the relevant `.summer/mechanics/<name>.md` if the level teaches an existing mechanic.
+- [ ] Skill states a concrete teaching goal — not a vague "fun encounter".
+- [ ] Skill draws a 5-beat pacing curve with intensity numbers (Intro / Build / Peak / Release / Hook).
+- [ ] Skill lists 4 encounters with timing + space mapping.
+- [ ] Skill lists 3 secrets with which beat each lives in.
+- [ ] Skill lists reward gating, gates rewards behind tests.
+- [ ] Skill enforces 4-6 distinct spaces (does not produce 12 micro-rooms).
+- [ ] Skill asks "May I create ..." before `summer_create_scene`.
+- [ ] Skeleton is markers + Area3Ds, NOT meshes / enemy scripts (those come later).
+- [ ] Skill writes the design doc to `.summer/levels/<name>.md`.
+- [ ] Skill never calls `summer_set_resource_property` on an inline sub_resource.
+- [ ] Final step is `summer_save_scene` then `summer_get_script_errors`.
+
+## Case 2: Failure Path — user blends three level types
+
+**Fixture:** Same as Case 1.
+
+**Input:** "Design a stealth level with a puzzle in the middle and a boss at the end."
+
+**Expected behavior:**
+
+- Skill recognizes blended types: stealth + puzzle + boss.
+- Skill pushes back: "That's three level types. Pick one as the primary; the other two become flavor or get split into sequential levels."
+- Skill names the trade-off: "Stealth + boss in the same level kills both — stealth wants tension that releases at the encounter, boss wants tension that builds *to* the encounter. They're opposite shapes."
+- Skill does NOT silently pick one or design all three at once.
+
+**Assertions:**
+
+- [ ] Skill identifies the blend explicitly.
+- [ ] Skill explains the design tension between the blended types.
+- [ ] Skill asks the user to pick one primary type before designing.
+- [ ] No `summer_create_scene` call until user picks.
+
+## Case 3: Edge Case — no `.summer/GameSoul.md` exists
+
+**Fixture:** Same as Case 1, but `.summer/GameSoul.md` does NOT exist.
+
+**Input:** "Design level 1 of my game."
+
+**Expected behavior:**
+
+- Skill detects no brief exists.
+- Skill suggests: "No `.summer/GameSoul.md` yet — without a brief, this level has no game to serve. Run `/summer:brainstorm-game` first, or give me the core loop + mechanics inline so I can anchor the design."
+- Skill does NOT design a generic level in a vacuum.
+
+**Assertions:**
+
+- [ ] Skill checks for `.summer/GameSoul.md` early (before designing).
+- [ ] Skill explicitly recommends `/summer:brainstorm-game` if absent.
+- [ ] Skill offers the inline-anchor alternative as a fallback.
+- [ ] No design happens without anchoring information.
+
+## Case 4: No Summer MCP — file-edit fallback
+
+**Fixture:** Same as Case 1, but Summer MCP is unavailable.
+
+**Input:** "Design level 1 — a 5-minute combat encounter."
+
+**Expected behavior:**
+
+- Skill detects no MCP.
+- Walks the design beats normally.
+- Instead of `summer_create_scene` + `summer_add_node`, prints the full `.tscn` file contents for the user to save manually at `levels/level_01.tscn`.
+- Generated `.tscn` is syntactically valid Godot 4 scene format with the marker/Area3D skeleton (no meshes).
+- Still writes the design doc to `.summer/levels/level_01.md` via host `Write`.
+- Asks "May I write ..." before each file write.
+
+**Assertions:**
+
+- [ ] Skill identifies that MCP is unavailable; does not blindly call `summer_*`.
+- [ ] Generated `.tscn` is parseable Godot 4 scene file.
+- [ ] Skeleton in the `.tscn` matches the spaces / spawns / triggers structure from the design doc.
+- [ ] Skill still writes `.summer/levels/<name>.md`.
+
+---
+
+This spec runs via `/skill-test design-level spec` (see `_meta/skill-test/SKILL.md`).

package/skills/_tests/specs/design-mechanic.md

@@ -0,0 +1,112 @@
+# Skill Spec: /design-mechanic
+
+## Fixture
+
+- Godot 4.5 / Summer Engine project with `World/Player` (CharacterBody3D + CollisionShape3D + Camera3D) already in the main scene.
+- A `scripts/player_controller.gd` exists with single-jump logic.
+- `.summer/GameSoul.md` exists, brief says: "core loop is precise platforming, three mechanics: dash, double-jump, parry".
+- Summer MCP available.
+
+## Case 1: Happy Path — design double-jump
+
+**Input:** "Design the double-jump mechanic."
+
+**Expected MCP tool sequence (in order):**
+
+1. (Skill asks one clarifying question if any — e.g., "Tap or hold-and-release?" — and waits.)
+2. `Read .summer/GameSoul.md` — anchor to the brief
+3. (Skill walks the five layers: input, response, feedback (visual/audio/mechanical), failure modes, depth)
+4. (Skill names tunables as `@export` vars)
+5. (Skill sketches the node-graph plan and asks "May I add `DoubleJumpFX` and `JumpAudio` to `./World/Player`?")
+6. `summer_get_scene_tree` — confirm Player exists
+7. `summer_add_node(parent="./World/Player", type="GPUParticles3D", name="DoubleJumpFX")`
+8. `summer_set_prop("./World/Player/DoubleJumpFX", "emitting", "false")`
+9. `summer_add_node(parent="./World/Player", type="AudioStreamPlayer3D", name="JumpAudio")`
+10. `summer_input_map_bind(name="jump", events=[{type:"key", key:"Space"}])` (idempotent)
+11. (Skill asks "May I modify `scripts/player_controller.gd` to add double-jump logic?")
+12. `Edit scripts/player_controller.gd` — merge double-jump logic
+13. (Skill asks "May I create `.summer/mechanics/double-jump.md` with the design doc?")
+14. `Write .summer/mechanics/double-jump.md`
+15. `summer_save_scene`
+16. `summer_get_script_errors`
+
+**Assertions:**
+
+- [ ] Skill reads `.summer/GameSoul.md` to anchor the design to the brief.
+- [ ] Skill walks all five layers (input, response, feedback, failure modes, depth) before scaffolding.
+- [ ] Skill enforces all THREE feedback channels (visual, audio, mechanical) — pushes back if user only names two.
+- [ ] Skill lists 3-7 tunables as `@export` vars (not `const`).
+- [ ] Skill asks "May I add ..." before scene mutations.
+- [ ] Skill asks "May I modify ..." before script edits.
+- [ ] Skill writes the design doc to `.summer/mechanics/<name>.md`.
+- [ ] Skill never calls `summer_set_resource_property` on an inline sub_resource (silent-fail trap).
+- [ ] Generated GDScript uses typed vars, `@export`, `class_name`, `@onready`, signals (matches `_shared/gd-style.md`).
+- [ ] Final step is `summer_save_scene` then `summer_get_script_errors`.
+
+## Case 2: Failure Path — user names a system, not a mechanic
+
+**Fixture:** Same as Case 1.
+
+**Input:** "Design the inventory."
+
+**Expected behavior:**
+
+- Skill recognizes "inventory" is a system, not a mechanic.
+- Skill pushes back: "Inventory is a system. The mechanics inside it are pickup, equip, drop, use, swap. Which one?"
+- Does NOT start designing a generic "inventory mechanic".
+- Waits for the user to pick a verb.
+
+**Assertions:**
+
+- [ ] Skill explicitly distinguishes system vs. mechanic.
+- [ ] Skill asks the user to pick a verb before walking the five layers.
+- [ ] No scene mutations or file writes happen until the user picks.
+
+## Case 3: Edge Case — user can't articulate depth
+
+**Fixture:** Same as Case 1.
+
+**Input:** "Design the double-jump."
+
+**During step 3, on Layer 5 (depth):**
+
+User says: "Players will use it strategically."
+
+**Expected behavior:**
+
+- Skill rejects the hand-wave: "That's not depth — name the choice the player makes."
+- Skill offers a concrete frame: "Depth = the resource is finite or has a cost, and level design forces a choice between using it now or saving it. If neither is true, this is just a higher-jumping single-jump."
+- Skill asks the user to either (a) name the cost / choice, or (b) cut the mechanic.
+- Skill does NOT scaffold a depth-less mechanic.
+
+**Assertions:**
+
+- [ ] Skill does not accept "strategically" / "for skilled play" / "it's interesting" as depth.
+- [ ] Skill names a concrete depth-vector (cost, resource, choice).
+- [ ] Skill explicitly offers "cut the mechanic" as a valid outcome.
+- [ ] No scaffolding happens until depth is articulated.
+
+## Case 4: No Summer MCP — file-edit fallback
+
+**Fixture:** Same as Case 1, but Summer MCP is unavailable (engine not connected).
+
+**Input:** "Design the double-jump mechanic."
+
+**Expected behavior:**
+
+- Skill detects no MCP and falls back to file edits.
+- Walks the five layers normally.
+- Instead of `summer_add_node`, prints the `.tscn` snippet for `DoubleJumpFX` and `JumpAudio` nodes for the user to paste into the scene file (or asks the user which `.tscn` to edit).
+- Asks before each file write.
+- Still writes the GDScript stub via `Edit` and the design doc via `Write`.
+
+**Assertions:**
+
+- [ ] Skill identifies that MCP is unavailable; does not blindly call `summer_*` tools.
+- [ ] Generated `.tscn` snippet is syntactically valid Godot 4 scene format.
+- [ ] Skill still asks "May I write ..." before each file write.
+- [ ] Skill still produces both the GDScript stub AND the design doc at `.summer/mechanics/<name>.md`.
+
+---
+
+This spec runs via `/skill-test design-mechanic spec` (see `_meta/skill-test/SKILL.md`).

package/skills/_tests/specs/design-npc.md

@@ -0,0 +1,112 @@
+# Skill Spec: /design-npc
+
+## Fixture
+
+- Godot 4.5 / Summer Engine project, main scene with `World/Player` (CharacterBody3D in `player` group) and an empty `World/Enemies` parent.
+- Summer MCP tools available.
+- Host file tools available (Read, Edit, Write).
+
+## Case 1: Happy Path — basic patrol-and-chase enemy
+
+**Input:** "Add a basic enemy that chases the player when it sees them."
+
+**Expected MCP tool sequence (in order):**
+
+1. (Skill asks the archetype question and waits.)
+2. User confirms "basic enemy".
+3. `summer_get_scene_tree`
+4. `summer_inspect_node "./World/Player"` — confirms it's in `player` group
+5. (Skill proposes the bundle: scene tree + script + states + telegraph + loot hook + "May I create?")
+6. After user OK:
+   - `summer_add_node(parent="./World/Enemies", type="CharacterBody3D", name="Enemy")`
+   - `summer_add_node(parent="./World/Enemies/Enemy", type="CollisionShape3D", name="Body")`
+   - `summer_add_node(parent="./World/Enemies/Enemy", type="MeshInstance3D", name="Mesh")`
+   - `summer_add_node(parent="./World/Enemies/Enemy", type="Area3D", name="Vision")`
+   - `summer_add_node(parent="./World/Enemies/Enemy/Vision", type="CollisionShape3D", name="VisionShape")`
+   - `summer_add_node(parent="./World/Enemies/Enemy", type="RayCast3D", name="Sight")`
+   - (Vision SphereShape3D saved as standalone `.tres`, NOT inline)
+   - `summer_set_prop` on Sight: `enabled = true`
+   - `Write scripts/enemy_ai.gd`
+   - `summer_connect_signal(from="./World/Enemies/Enemy/Vision", signal="body_entered", to="./World/Enemies/Enemy", method="_on_body_entered")`
+   - `summer_save_scene`
+   - `summer_get_script_errors`
+
+**Assertions:**
+
+- [ ] Skill asks the archetype question before any tool call.
+- [ ] Scene has BOTH a Vision Area3D AND a Sight RayCast3D (the two-step perception pattern).
+- [ ] Vision shape is saved as a standalone `.tres`, NOT inline sub_resource (silent-fail trap).
+- [ ] Script defines an `enum State` with at least 4 states (idle / alert / attack / dead).
+- [ ] Script has an attack `telegraph` parameter in 0.3–0.7 sec range.
+- [ ] Script emits a `died` signal.
+- [ ] Script uses `distance_squared_to` (NOT `distance_to`) for range comparisons.
+- [ ] Script uses typed GDScript per `_shared/gd-style.md`.
+- [ ] Skill asks "May I create / write …" before each user-visible mutation.
+- [ ] Final step is `summer_save_scene` then `summer_get_script_errors`.
+
+## Case 2: Failure Path — wave-mob archetype but user asks for full FSM
+
+**Fixture:** User wants 100+ enemies on screen at once.
+
+**Input:** "Spawn 100 enemies that chase the player. Each one should perceive, decide, telegraph attacks, and drop loot."
+
+**Expected behavior:**
+
+- Skill recognizes the scale conflict.
+- Says: "100 enemies with full FSM + LOS perception will eat your frame budget. For wave mobs at this scale, the right archetype is the wave-mob (2 states, no LOS, direct line to player). Want me to build that instead?"
+- Does NOT silently build 100 expensive enemies.
+- Offers the trade-off explicitly.
+
+**Assertions:**
+
+- [ ] Skill names the performance trade-off, not just "this is hard".
+- [ ] Skill points to the wave-mob archetype as the right answer.
+- [ ] Skill does NOT proceed without confirmation.
+- [ ] Skill never starts spawning 100 expensive nodes.
+
+## Case 3: Edge Case — boss with phases
+
+**Fixture:** Same as Case 1.
+
+**Input:** "Design a 3-phase boss for the dungeon room."
+
+**Expected behavior:**
+
+- Skill picks the **boss** archetype (different complexity budget).
+- Calls out: "Boss complexity (6–10 states, scripted phases) is at the threshold where a behavior tree might pay off, but I recommend a hand-coded FSM with phase enum first since you're a single dev."
+- Walks the four pillars but at boss scale: more tells per state, telegraph 0.5–0.7 sec, distinct mechanics per phase (cap at 4–6 total mechanics).
+- Defers to `ai-and-npcs/boss-patterns/SKILL.md` for the deeper phase-transition patterns.
+- Does NOT just scale up the basic-enemy stub.
+
+**Assertions:**
+
+- [ ] Skill recognizes "boss" requires a different design.
+- [ ] Skill caps at 4–6 distinct mechanics across phases.
+- [ ] Skill mentions phase enum as the FSM extension.
+- [ ] Skill defers to boss-patterns for deeper detail rather than trying to one-shot it.
+
+## Case 4: No Summer MCP — fallback path
+
+**Fixture:** Same as Case 1, but Summer MCP unavailable.
+
+**Input:** "Add a basic enemy that chases the player."
+
+**Expected behavior:**
+
+- Skill detects MCP unavailable.
+- Asks user to paste the existing scene tree (or the relevant `.tscn` snippet) so node paths are right.
+- Generates a `.tscn` snippet (Enemy + Vision + Sight + Mesh + CollisionShape) with valid Godot 4 scene syntax.
+- Writes `scripts/enemy_ai.gd` directly.
+- Provides manual editor instructions for connecting the `body_entered` signal (or a connection block in the `.tscn`).
+- Still asks "May I write …" before each file write.
+
+**Assertions:**
+
+- [ ] Skill does not blindly call `summer_*` tools and fail.
+- [ ] Generated `.tscn` is valid Godot 4 syntax (parseable).
+- [ ] Generated GDScript has the same FSM structure (states / telegraph / died signal).
+- [ ] Skill still asks "May I" on writes.
+
+---
+
+This spec runs via `/skill-test design-npc spec` (see `_meta/skill-test/SKILL.md`).

package/skills/_tests/specs/export-and-ship.md

@@ -0,0 +1,114 @@
+# Skill Spec: /export-and-ship
+
+## Fixture
+
+- Godot 4.5 / Summer Engine project, complete game with main scene set, no script errors, basic icon at `icon.png` (256×256).
+- Existing `export_presets.cfg` with Windows/Mac/Linux presets, all `debug = true` (development defaults).
+- No `LICENSE` file at repo root.
+- No `attribution.md`.
+- Two CC-BY 4.0 assets imported from public sources (used in scene).
+- Summer MCP tools available.
+
+## Case 1: Happy Path — Steam (Windows + Mac + Linux)
+
+**Input:** "I'm ready to ship to Steam. Build me Windows, Mac, and Linux releases."
+
+**Expected MCP tool sequence (in order):**
+
+1. (Skill asks the destination question and waits — confirms Steam, Win/Mac/Linux.)
+2. Pre-flight:
+   - `summer_get_diagnostics` — clean
+   - `summer_get_console` — clean
+   - Read `project.godot` — main scene set, no version, no name
+   - Read `LICENSE` — does not exist
+   - Read `attribution.md` — does not exist
+   - Read `export_presets.cfg` — `debug = true` on all presets
+   - Grep for hardcoded paths
+3. (Skill lists the pre-flight failures: missing LICENSE, missing attribution.md, missing version, missing game name, debug=true on release presets, missing Steam-required assets like trailer + capsules.)
+4. Skill asks: "Pre-flight failed on N items: <list>. Want me to walk these one by one?"
+5. (Does NOT proceed to build.)
+
+**Assertions:**
+
+- [ ] Skill asks the destination question first.
+- [ ] Skill runs the FULL pre-flight checklist before any build.
+- [ ] Skill detects missing LICENSE and missing `attribution.md`.
+- [ ] Skill detects `debug = true` and flags it as a blocker for release.
+- [ ] Skill detects missing Steam-specific assets (capsules, trailer) and lists them.
+- [ ] Skill does NOT produce a build until the user fixes the blockers OR explicitly waives them.
+- [ ] Skill never auto-uploads to Steam Pipe — only points at the upload command.
+
+## Case 2: Failure Path — pre-flight passes, but iOS targeted without Apple Developer setup
+
+**Fixture:** Project is clean (LICENSE present, no script errors, version + name set).
+
+**Input:** "Ship to iOS App Store."
+
+**Expected behavior:**
+
+- Skill runs pre-flight — clean.
+- Skill walks iOS-specific requirements: 1024×1024 icon, screenshots at 6.5" iPhone resolution, App Store description, privacy policy URL, support URL, bundle ID, Apple Developer cert + provisioning profile.
+- Skill asks: "iOS submission requires (a) Apple Developer account ($99/yr), (b) Bundle ID configured in Apple Developer portal, (c) distribution certificate + provisioning profile, (d) macOS machine with Xcode for the final archive step. Do you have these set up? If not, those are the prerequisites — I can help with the build config but not the Apple Developer side."
+- Does NOT silently produce an unsigned `.ipa` that can't be submitted.
+
+**Assertions:**
+
+- [ ] Skill names the iOS prerequisites that aren't satisfiable from inside Godot.
+- [ ] Skill names the bundle-ID convention (`com.<org>.<game>`).
+- [ ] Skill mentions TestFlight before App Store review.
+- [ ] Skill does NOT pretend to do code signing it can't actually do.
+- [ ] Skill names AAB-vs-APK if the user mistakenly says "Android APK" (different ticket but related anti-pattern).
+
+## Case 3: Edge Case — multi-platform, web HTML5 included
+
+**Fixture:** Same as Case 1 but post-fix (LICENSE added, attribution.md added, presets `debug = false`, version = "1.0.0", screenshots ready, trailer recorded).
+
+**Input:** "Ship to Steam + itch + web."
+
+**Expected behavior:**
+
+- Pre-flight clean.
+- Skill walks each platform's requirements separately.
+- For web: explicitly flags the multiplayer transport (ENet doesn't work in browser), the audio autoplay block (Chrome blocks until first user click), and the file-size matters trap.
+- Web export preset configured: encryption disabled, no JS eval, GLES3 fallback to GLES2 on if old browsers targeted.
+- Skill asks: "May I produce 5 builds (Win + Mac + Linux + itch packages + web)?"
+- Produces builds via `godot --headless --export-release` invocations after user OK.
+- Verifies each build size and lists post-build warnings (e.g. "Web build is 180 MB — consider stripping unused textures").
+- Points at upload commands for each: `steamcmd`, `butler push`, manual itch web upload.
+
+**Assertions:**
+
+- [ ] Skill walks per-platform requirements separately, NOT a generic checklist.
+- [ ] For web: skill flags the autoplay + multiplayer + file-size traps explicitly.
+- [ ] Skill produces builds in correct order (build, then verify, then point at upload — never auto-upload).
+- [ ] Skill provides per-platform upload commands (steamcmd / butler / etc).
+- [ ] Skill does NOT execute uploads itself.
+
+## Case 4: No Summer MCP — fallback path
+
+**Fixture:** Same as Case 1, MCP unavailable.
+
+**Input:** "I want to ship to Steam."
+
+**Expected behavior:**
+
+- Skill detects MCP unavailable.
+- Asks user to confirm via the editor: main scene set, no errors in Output panel, no errors in Debugger panel.
+- Asks user to paste contents of `project.godot` and `export_presets.cfg`.
+- Walks the pre-flight checklist by reasoning over the pasted text.
+- Provides per-platform asset list and config recommendations.
+- Provides build commands the user can run manually (`godot --headless --export-release ...`).
+- Provides upload commands the user can run manually (`steamcmd ...`).
+- Still applies "May I write" before any file edit (e.g. `LICENSE` creation).
+
+**Assertions:**
+
+- [ ] Skill does not blindly call `summer_*` tools and fail.
+- [ ] Skill asks for the specific files it needs (project.godot, export_presets.cfg).
+- [ ] Skill still runs the full pre-flight check via reading.
+- [ ] Skill names the same blockers (LICENSE, debug=true, missing trailer).
+- [ ] Skill asks "May I write" before creating LICENSE / attribution.md / etc.
+
+---
+
+This spec runs via `/skill-test export-and-ship spec` (see `_meta/skill-test/SKILL.md`).

package/skills/_tests/specs/fps-controller.md

@@ -20,11 +20,11 @@
 5. `summer_set_prop("./World/Player/Collision", "shape", "CapsuleShape3D")` (creates standalone, NOT inline sub-resource)
 6. `summer_set_resource_property("./World/Player/Collision", "shape.height", "1.8")` (only after the shape is standalone)
 7. `summer_set_prop("./World/Player/Camera", "position", "Vector3(0, 1.6, 0)")`
-8. `summer_input_map_bind("move_forward", "key:W")`
-9. `summer_input_map_bind("move_back", "key:S")`
-10. `summer_input_map_bind("move_left", "key:A")`
-11. `summer_input_map_bind("move_right", "key:D")`
-12. `summer_input_map_bind("jump", "key:Space")`
+8. `summer_input_map_bind(name="move_forward", events=[{type:"key", key:"W"}])`
+9. `summer_input_map_bind(name="move_back", events=[{type:"key", key:"S"}])`
+10. `summer_input_map_bind(name="move_left", events=[{type:"key", key:"A"}])`
+11. `summer_input_map_bind(name="move_right", events=[{type:"key", key:"D"}])`
+12. `summer_input_map_bind(name="jump", events=[{type:"key", key:"Space"}])`
 13. (User-side write) `Write` script file `scripts/player_controller.gd` after the agent asks "May I attach the controller script to ./World/Player?"
 14. `summer_save_scene`
 15. `summer_get_script_errors`