summer-engine 2.2.0 → 2.5.0

package/skills/_shared/collaborative-protocol.md

@@ -1,50 +0,0 @@
-# Collaborative Protocol — "May I write?"
-
-> Every Summer skill must follow this. The agent works *with* the user, not around them.
-
-## The rule
-
-**Before any user-visible write step, the agent must explicitly state what it is about to do and ask permission to proceed.**
-
-This applies to:
-- Creating files (`.gd`, `.tscn`, `.tres`, JSON, configs)
-- Modifying existing files (especially `.gd` and `.tscn`)
-- Running irreversible operations (deletion, reset, force-overwrite)
-- Setting up project-wide settings (`project.godot`)
-- Installing tools, libraries, or templates
-
-Reading is unconditional. Inspection, scene-tree walks, diagnostics — never need permission.
-
-## Phrasing
-
-Plain, short, action-first. Examples:
-
-> May I create `scenes/player.tscn` and add a CharacterBody3D + Camera3D?
-
-> I'm about to overwrite `levels/level_01.tscn`. The current version has 14 nodes — I'll preserve them and add the new lighting setup. Continue?
-
-> May I attach `scripts/player_controller.gd` to `./World/Player`?
-
-> I'm going to bind `move_forward`, `move_back`, `move_left`, `move_right`, `jump`. OK?
-
-## What this prevents
-
-1. **Silent overwrites.** The agent stomps the user's hand-edited script.
-2. **Cascading scope creep.** A "small fix" turns into a 30-file refactor.
-3. **Unclear state.** The user has no idea what changed when something breaks.
-4. **Trust loss.** One unauthorized edit and the user stops trusting the agent.
-
-## What this is NOT
-
-- Not a confirmation dialog for every property change in a single skill execution. Group related writes into one ask: "I'm about to add the player root, attach the controller script, and bind 5 input actions. OK?"
-- Not a request for design input. The skill should know what to do; the ask is for permission, not direction.
-- Not a stop on simple read-only ops or single-property tweaks the user clearly directed.
-
-## Linter check
-
-The `_meta/skill-test/SKILL.md` static linter looks for the phrases:
-- "May I" / "May I write" / "May I create" / "May I attach"
-- "I'm about to"
-- "Continue?" / "OK?" / "Proceed?"
-
-A skill that mutates files but never says any of these fails the linter.

package/skills/_shared/gd-style.md

@@ -1,121 +0,0 @@
-# GDScript Style — Summer Conventions
-
-> The bar for GDScript in Summer. Skills should produce code that matches this. Where Godot's official style guide is silent, this is the tiebreaker.
-
-## File structure
-
-```gdscript
-class_name PlayerController
-extends CharacterBody3D
-
-# 1. Constants
-const SPEED := 5.0
-const JUMP_VELOCITY := 4.5
-const GRAVITY := 9.8
-
-# 2. Exports (designer-tweakable in inspector)
-@export var move_speed: float = 5.0
-@export var jump_height: float = 1.0
-@export_range(0.1, 10.0) var look_sensitivity: float = 1.0
-
-# 3. Signals (events this node emits)
-signal died
-signal health_changed(new_value: int)
-
-# 4. Onready references (cached node lookups)
-@onready var camera: Camera3D = $Camera3D
-@onready var collision: CollisionShape3D = $CollisionShape3D
-
-# 5. Private state (snake_case, leading underscore optional)
-var _is_grounded: bool = false
-var _velocity := Vector3.ZERO
-
-# 6. Lifecycle (in canonical order)
-func _ready() -> void:
-    pass
-
-func _process(delta: float) -> void:
-    pass
-
-func _physics_process(delta: float) -> void:
-    pass
-
-func _input(event: InputEvent) -> void:
-    pass
-
-# 7. Public API (PascalCase or snake_case methods, snake_case for funcs)
-func take_damage(amount: int) -> void:
-    pass
-
-# 8. Private helpers (leading underscore)
-func _calculate_movement(delta: float) -> Vector3:
-    return Vector3.ZERO
-```
-
-## Type hints
-
-**Always type-hint.** No bare `var x = 5`. Use `:=` for inferred typing or `:` for explicit.
-
-```gdscript
-# RIGHT
-var speed: float = 5.0
-var name := "Player"
-func attack(target: Node3D, amount: int) -> bool:
-    return true
-
-# WRONG
-var speed = 5.0
-func attack(target, amount):
-    return true
-```
-
-## Naming
-
-| Thing | Convention | Example |
-|---|---|---|
-| Class | PascalCase | `class_name PlayerController` |
-| File | snake_case | `player_controller.gd` |
-| Variable, function | snake_case | `move_speed`, `take_damage()` |
-| Constant | SCREAMING_SNAKE_CASE | `const MAX_HEALTH := 100` |
-| Signal | snake_case (past tense for events) | `died`, `health_changed` |
-| Private | leading underscore | `_is_grounded`, `_calculate_movement` |
-| Node in scene | PascalCase | `Player`, `Camera3D`, `CollisionShape3D` |
-
-## Signals
-
-Define with typed args. Connect in `_ready()` or in scene `.tscn` directly.
-
-```gdscript
-signal health_changed(new_value: int, max_value: int)
-
-func _ready() -> void:
-    health_changed.connect(_on_health_changed)
-
-func _on_health_changed(new_value: int, max_value: int) -> void:
-    pass
-```
-
-## Tweens
-
-Use `create_tween()` for animation. Don't manually lerp in `_process` unless you need fine control.
-
-```gdscript
-var tween := create_tween()
-tween.tween_property(self, "modulate", Color.WHITE, 0.3)
-```
-
-## What to avoid
-
-- Bare `var x = something` (no type)
-- `Object` typed parameters (use specific class)
-- `match` for two-branch logic (use `if`)
-- Recreating node lookups in `_process` (cache via `@onready`)
-- Hard-coded strings for node paths in code (use `@onready` + scene-relative paths)
-- Setting `position` in `_process` for physics objects (use `_physics_process` and `velocity`)
-
-## See also
-
-- [Official Godot GDScript style guide](https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_styleguide.html)
-- `scripting-patterns/gdscript-patterns/SKILL.md` — patterns and idioms
-- `scripting-patterns/signal-patterns/SKILL.md` — signal usage
-- `scripting-patterns/state-machine-patterns/SKILL.md` — state machine patterns

package/skills/_shared/godot-version.md

@@ -1,32 +0,0 @@
-# Godot / Summer Engine Version Reference
-
-> Read this **before** writing any code, especially shaders or rendering code. Godot's API is moving; the LLM cutoff date matters per domain.
-
-## Engine fork base
-
-Summer Engine is a fork of **Godot 4.5** (stable). All skills assume Godot 4.x APIs.
-
-## LLM training cutoff vs. Godot release dates
-
-| Domain | Godot 4.x churn | Action |
-|---|---|---|
-| Scripting (GDScript core) | low | Trust your training. Spot-check signatures only when something feels off. |
-| Scene / node tree APIs | low | Trust your training. |
-| Renderer (`RenderingServer`, `Compositor`) | high in 4.4 / 4.5 | Verify before writing. Check `MovieMaker`, `Compositor` effects, `RenderSceneBuffers` — these renamed/added recently. |
-| Shaders (`canvas_item`, `spatial`, `compute`) | medium | Built-in functions stable, but `hint_*` flags shifted. Verify `hint_screen_texture` / `hint_depth_texture` syntax. |
-| Animation (`AnimationTree`, `AnimationMixer`) | high (4.0 → 4.3 rename) | Use `AnimationMixer` for new code, not deprecated `AnimationPlayer`-as-mixer. |
-| Multiplayer (`MultiplayerAPI`) | medium | High-level API stable. `SceneReplicationConfig` settled in 4.0+. |
-| Editor / EditorPlugin | medium | Spot-check. |
-| `Tween` / `SceneTreeTween` | low | Stable since 4.0. |
-
-## Summer-specific deltas from vanilla Godot
-
-- Local API server runs on `localhost:6550` (set per machine via `~/.summer/api-token`).
-- Engine ships a webview module in `modules/1summer_engine/` — do not assume vanilla Godot for editor UI patches.
-- Project root contains `.summer/` for project memory; do not delete it.
-
-## When in doubt
-
-1. Use Summer MCP tools (`summer_inspect_node`, `summer_inspect_resource`) to read live editor state instead of guessing.
-2. Use `summer_get_diagnostics` after every scene change.
-3. Check `_shared/mcp-tools-reference.md` for the canonical tool list.

package/skills/_shared/mcp-tools-reference.md

@@ -1,133 +0,0 @@
-# Summer MCP Tools — Canonical Reference
-
-> Use this as the single source of truth for which Summer MCP tool to call. Skills should reference tool names exactly as written here.
-
-## When to use Summer MCP vs. host file edits
-
-**Use Summer MCP for** anything that needs the live editor or Godot's import pipeline:
-- Scene graph mutation (`.tscn`)
-- Node properties and resources (`.tres`)
-- Project settings (`project.godot`) and InputMap
-- Asset import (Godot's import pipeline must run)
-- Play / stop / runtime state
-- Diagnostics, console, debugger output, script errors
-
-**Use the host agent's file tools for** plain text:
-- `.gd` GDScript files
-- `.cs` C# files
-- `.json`, `.md`, `.txt`, `.yaml`
-- Most simple `.tres` resources where the structure is well-known
-
-**Rule of thumb:** if Godot's importer or the live editor needs to know about it, MCP. Otherwise, file edits.
-
-## Tool surface (37 tools)
-
-### Scene graph (10)
-
-| Tool | Use |
-|---|---|
-| `summer_get_scene_tree` | Read current scene graph. Always do this before mutating. |
-| `summer_open_main_scene` | Open the project's main scene. |
-| `summer_open_scene` | Open a specific `.tscn`. |
-| `summer_create_scene` | Create a new scene. |
-| `summer_inspect_node` | Read a single node's properties. |
-| `summer_add_node` | Add a node to the active scene. |
-| `summer_remove_node` | Remove a node. |
-| `summer_replace_node` | Swap a node's type, preserving children. |
-| `summer_select_node` | Set editor selection (visual feedback for the user). |
-| `summer_save_scene` | Persist changes. **Always save before play.** |
-
-### Properties / resources (4)
-
-| Tool | Use |
-|---|---|
-| `summer_set_prop` | Set a typed property (Vector3, Color, etc.) using Godot's `str_to_var()`. |
-| `summer_set_resource_property` | Set a property on a nested resource (e.g., CollisionShape's `shape.radius`). |
-| `summer_inspect_resource` | Read a resource's properties. |
-| `summer_connect_signal` | Wire a signal between nodes. |
-
-### Project & input (2)
-
-| Tool | Use |
-|---|---|
-| `summer_project_setting` | Modify `project.godot` settings (rendering, physics). |
-| `summer_input_map_bind` | Bind input actions in InputMap. Folds in the legacy `add_action` step. |
-
-### Import pipeline (2)
-
-| Tool | Use |
-|---|---|
-| `summer_import_from_url` | Download a `.glb`/`.png`/etc and run Godot's full import pipeline. |
-| `summer_import_from_url_batch` | Same, batched (single filesystem scan). |
-
-### Play / runtime (3)
-
-| Tool | Use |
-|---|---|
-| `summer_play` | Run the game. |
-| `summer_stop` | Stop the running game. |
-| `summer_is_running` | Check play state before deciding to call `summer_stop`. |
-
-### Diagnostics (5)
-
-| Tool | Use |
-|---|---|
-| `summer_get_diagnostics` | Aggregate error/warning summary. Call after every change. |
-| `summer_get_console` | Engine output panel. |
-| `summer_clear_console` | Clear before a fresh play, so post-run output is clean. |
-| `summer_get_debugger_errors` | Runtime errors with stack traces. |
-| `summer_get_script_errors` | Script compilation errors. |
-
-### Asset library (2)
-
-| Tool | Use |
-|---|---|
-| `summer_search_assets` | Free public asset search (community library + user's own). Sources: `library`, `community`, `my_assets`, `all`. |
-| `summer_import_asset` | Download a found asset and run import. |
-
-### Asset generation (4 — metered)
-
-| Tool | Use |
-|---|---|
-| `summer_generate_image` | AI image gen. |
-| `summer_generate_3d` | Image-to-3D. |
-| `summer_generate_audio` | SFX / music gen. |
-| `summer_generate_video` | Video gen. |
-
-### Job tracking (2)
-
-| Tool | Use |
-|---|---|
-| `summer_check_job` | Poll a generation job. |
-| `summer_batch` | Run multiple ops as a transaction. |
-
-### Meta (2)
-
-| Tool | Use |
-|---|---|
-| `summer_get_project_context` | Project structure summary — call at start of session. |
-| `summer_get_agent_playbook` | Daily operating contract — call at start of session. |
-
-## Common pattern
-
-Every scene-touching skill should follow this loop:
-
-1. `summer_get_project_context` — orient.
-2. `summer_get_agent_playbook` — read the rules.
-3. `summer_get_scene_tree` — see what's there.
-4. (mutations: `summer_add_node`, `summer_set_prop`, `summer_connect_signal`, ...)
-5. `summer_save_scene` — persist.
-6. `summer_get_script_errors` — catch GDScript breakage.
-7. `summer_play` → `summer_get_debugger_errors` → `summer_stop` if verifying runtime.
-
-## Trap: silent-fail on inline sub-resource SetResourceProperty
-
-`summer_set_resource_property` will silently fail if the target resource is an inline `sub_resource` rather than a standalone `.tres`. If you need to set nested properties (mesh size, shape radius, material color), make the resource standalone first:
-
-```
-summer_add_node(... mesh = "BoxMesh" ...)         # creates inline sub_resource
-# WRONG: summer_set_resource_property("./Box", "mesh.size", "Vector3(2,2,2)")  ← silently fails
-# RIGHT: save mesh as .tres, then SetResourceProperty
-```
-
-This is documented in `public/knowledge/asset_pipeline.json`.

package/skills/_shared/summer-folder.md

@@ -1,44 +0,0 @@
-# `.summer/` Folder Convention
-
-> The canonical layout for project-scoped Summer state. Read this if you're authoring a skill that writes durable design output (briefs, art bible, level docs).
-
-## Files at the root of `.summer/`
-
-- `GameSoul.md` — the project brief. Created by `/summer:brainstorm-game`. Contains: name, one-sentence pitch, core loop, 3 mechanics max, art direction summary, scope. Updated whenever the game's high-level direction changes.
-- `art-bible.md` — visual style reference. Created by `/summer:art-direction`. Contains: palette (6–15 hex codes), mood adjectives, lighting plan, post-processing notes, do/don't list, references.
-- `audio-bible.md` — sonic identity. Created by `/summer:audio-direction`. Contains: music style + tempo range, SFX vocabulary (8 classes), dynamic music FSM, bus layout reference.
-
-## Subdirectories
-
-- `mechanics/<mechanic-name>.md` — one file per designed mechanic (e.g., `double-jump.md`, `parry.md`). Created by `/summer:design-mechanic`. Contains: input → response → feedback → failure modes → tunable parameters.
-- `levels/<level-name>.md` — one file per designed level. Created by `/summer:design-level`. Contains: teaching goal, pacing curve (5 beats), encounters, secrets, reward gating.
-- `npcs/<npc-name>.md` — one file per designed NPC. Created by `/summer:design-npc`. Contains: archetype, perception model, decision tree, escalation, defeat sequence.
-
-## Conventions
-
-- All filenames are lowercase, hyphens not underscores.
-- Skills MUST ask "May I write/update `.summer/<file>`?" before any write to this folder.
-- Skills MAY read existing files in `.summer/` without permission to ground their output in prior decisions.
-- The folder lives in the project root (sibling to `project.godot`).
-- Add `.summer/` to `.gitignore` if the user prefers it private; default is to commit it (game design lives with the game).
-
-## Skills that write here
-
-| Skill | Writes |
-|---|---|
-| `/summer:brainstorm-game` | `.summer/GameSoul.md` |
-| `/summer:art-direction` | `.summer/art-bible.md` |
-| `/summer:audio-direction` | `.summer/audio-bible.md` |
-| `/summer:design-mechanic` | `.summer/mechanics/<name>.md` |
-| `/summer:design-level` | `.summer/levels/<name>.md` |
-| `/summer:design-npc` | `.summer/npcs/<name>.md` |
-| `/summer:debug` | does NOT write here |
-| `/summer:play` | does NOT write here |
-| `/summer:vfx` | does NOT write here (VFX edits scenes/scripts) |
-| `/summer:tune-performance` | optionally writes `.summer/perf-notes.md` if user requests |
-| `/summer:setup-multiplayer` | optionally writes `.summer/multiplayer-architecture.md` |
-| `/summer:export-and-ship` | does NOT write here (writes export configs in `project.godot`) |
-
-## Linter check (future)
-
-Once `_meta/skill-test` gains an executable mode, it should validate that any skill writing to `.summer/` is documented in the table above.

package/skills/_shared/template-registry.md

@@ -1,40 +0,0 @@
-# Template Registry
-
-> Skills cross-link to template repos via the `template-id` frontmatter field. This file is the canonical mapping. When a template repo moves, update one entry here.
-
-## Template IDs
-
-| template-id | Description | Repo |
-|---|---|---|
-| `template-3d-fps` | First-person shooter starter (CharacterBody3D, Camera3D, input, sample level) | https://github.com/SummerEngine/FPS-template-Summer-Engine |
-| `template-3d-tps` | Third-person shooter starter | https://github.com/SummerEngine/tps-template |
-| `template-2d-platformer` | 2D platformer starter (TileMap, CharacterBody2D, parallax) | TBD |
-| `template-3d-platformer` | 3D platformer starter (jump, double jump, simple level) | TBD |
-| `template-top-down-rpg` | Top-down ARPG starter | TBD |
-| `template-2d-deckbuilder` | Deck-builder starter (card, deck, draw, discard, energy) | TBD (prototype lives at `templates/template-2d-deckbuilder/`) |
-| `template-tower-defense` | Tower defense starter | TBD |
-| `template-walking-sim` | Walking sim starter | TBD |
-
-## Convention
-
-Each template is its own GitHub repo, MIT licensed, kept small (< 50 MB). Templates ship working code. Skills describe patterns. A skill links to the matching template via:
-
-```markdown
-## Want a working starter?
-
-This skill describes the pattern. For a runnable project, use the template:
-
-→ **template-id**: `template-3d-fps`
-→ **Repo**: https://github.com/SummerEngine/FPS-template-Summer-Engine
-→ **Bootstrap**: `summer template clone template-3d-fps my-fps`
-```
-
-## Linter check
-
-The `_meta/skill-test/SKILL.md` static linter validates that any `template-id:` declared in a skill's frontmatter exists in the table above.
-
-## Adding a template
-
-1. Create a new GitHub repo under `SummerEngine` org, MIT license.
-2. Add the `template-id`, description, and repo URL to the table above.
-3. Reference the `template-id` from any relevant skill.

package/skills/_tests/runner.md

@@ -1,90 +0,0 @@
-# Skill Test Runner
-
-> How `/skill-test` and `/skill-improve` actually work in this repo. Read this if you're authoring a behavioral spec or trying to understand the test pipeline.
-
-## Architecture
-
-```
-skills/
-├── _meta/skill-test/SKILL.md        # the linter + spec runner (3 modes)
-├── _meta/skill-improve/SKILL.md     # the eval harness for iteration
-└── _tests/
-    ├── runner.md                    # this file
-    ├── specs/
-    │   └── <skill-name>.md          # behavioral specs, one per non-_meta skill
-    └── runs/                        # generated, gitignored
-        └── <skill-name>/
-            ├── baseline/
-            └── proposed/
-```
-
-## What a spec looks like
-
-Every spec at `_tests/specs/<skill-name>.md` has:
-
-- A `## Fixture` block describing the starting state and tool availability.
-- One or more `## Case <N>: <Happy | Failure | Edge>` blocks.
-- Each Case has `**Input:**`, `**Expected MCP tool sequence:**`, and `**Assertions:**` (markdown checkboxes).
-
-Reference: `_tests/specs/fps-controller.md` (canonical example).
-
-## Static linter (cheap, every commit)
-
-Run by `/skill-test <name>` in `static` mode. Pure markdown reasoning — no subagents, no tool calls.
-
-The 7 checks live in `_meta/skill-test/SKILL.md` § "Mode: static". Re-read that for the canonical list.
-
-## Spec runner (medium, weekly)
-
-Run by `/skill-test <name>` in `spec` mode. Reads SKILL.md and the matching spec, reasons over the assertions. No execution.
-
-This catches drift between what the skill says and what its spec demands. It does not catch agent variation — for that, use `/skill-improve`.
-
-## Eval harness (expensive, on-demand)
-
-Run by `/skill-improve <name>`. Spawns parallel `Task` subagents with the current SKILL.md vs. proposed SKILL.md. Compares outputs against assertions. Decides which wins. Writes results to `_tests/runs/<name>/`.
-
-Use this when:
-- A skill consistently fails its spec but you can't tell why from reading it.
-- You're rewriting a skill and want a regression baseline.
-- A skill is critical (top of `catalog.yaml` recommended set) and overdue for an audit.
-
-## Authoring a spec
-
-Five-minute job per skill. Copy this template:
-
-```markdown
-# Skill Spec: /<skill-name>
-
-## Fixture
-- <starting state of the project / scene>
-- Available tools: Summer MCP <yes|no>, host file edits <yes|no>
-
-## Case 1: Happy Path
-**Input:** "<the most common user prompt that should trigger this skill>"
-
-**Expected MCP tool sequence (in order):**
-1. summer_<tool>(...)
-2. summer_<tool>(...)
-
-**Assertions:**
-- [ ] <observable outcome 1>
-- [ ] <skill asks "May I" before any user-visible write>
-- [ ] <skill never calls the silent-fail anti-pattern>
-
-## Case 2: Failure Path
-**Fixture:** <something missing or already present that should change behavior>
-**Input:** "<edge prompt>"
-**Expected:** <how the skill should adapt — clarify, defer, fail-safe>
-
-## Case 3: Edge Case
-**Fixture:** ...
-**Input:** "<unusual prompt>"
-**Expected:** ...
-```
-
-Aim for 2–4 cases per skill. More than 4 = the skill is doing too much and should be split.
-
-## Catalog last-tested
-
-Every successful run of `/skill-improve` (or a manual sign-off) should bump `last-tested:` in `catalog.yaml`. The audit mode of `/skill-test` flags skills with stale `last-tested:` fields.

package/skills/_tests/specs/3d-lighting.md

@@ -1,19 +0,0 @@
-# Skill Spec: /3d-lighting
-
-> Stub spec. Expand with Happy / Failure / Edge cases. See `fps-controller.md` for the canonical format.
-
-## Fixture
-
-- TBD
-
-## Case 1: Happy Path
-
-**Input:** "<typical user prompt>"
-
-**Expected MCP tool sequence (in order):**
-
-1. TBD
-
-**Assertions:**
-
-- [ ] TBD

package/skills/_tests/specs/art-direction.md

@@ -1,115 +0,0 @@
-# Skill Spec: /art-direction
-
-## Fixture
-
-- Godot 4.5 / Summer Engine project, main scene with `World/WorldEnvironment` and `World/Sun` (DirectionalLight3D) present.
-- `.summer/GameSoul.md` exists; brief: "Cozy farming sim, vertical slice scope."
-- No `.summer/art-bible.md` yet.
-- Summer MCP available.
-
-## Case 1: Happy Path — define art direction for cozy farming sim
-
-**Input:** "Help me define the art direction. References: Stardew Valley and Sable."
-
-**Expected MCP tool sequence (in order):**
-
-1. `Read .summer/GameSoul.md` — anchor
-2. (Skill notes: brief says "cozy", which forbids harsh contrast / saturated reds)
-3. (Skill walks: technique pick → palette (6-15 hex codes) → mood adjectives → lighting plan → post-processing rules → do/don't list)
-4. (Skill shows the bible inline)
-5. (Skill asks: "May I update `project.godot`'s default clear color to the palette primary, and enable MSAA 2x?")
-6. `summer_project_setting(key="rendering/environment/defaults/default_clear_color", value="Color(...)")`
-7. `summer_project_setting(key="rendering/anti_aliasing/quality/msaa_3d", value="2")`
-8. (Skill asks: "May I dial in the WorldEnvironment + Sun to the lighting plan?")
-9. `summer_inspect_node(path="./World/WorldEnvironment")`
-10. `summer_set_prop(...)` — adjustments + tonemap per the plan
-11. `summer_set_prop(path="./World/Sun", key="light_color", value="Color(...)")`
-12. (Skill asks: "May I create `.summer/art-bible.md` with this bible?")
-13. `Write .summer/art-bible.md`
-
-**Assertions:**
-
-- [ ] Skill reads `.summer/GameSoul.md` to anchor.
-- [ ] Skill enforces 2+ references — does not proceed with single reference.
-- [ ] Skill picks ONE rendering technique (does not allow blending without naming the conflict).
-- [ ] Palette has 6-15 hex codes; uses off-white (e.g., #f4ecdf) and off-black (e.g., #1f1a16) — flags pure #ffffff or #000000 if user pitches them.
-- [ ] Mood adjectives are concrete (e.g., "soft, hand-warmed, golden-hour"), not vague ("cool, atmospheric").
-- [ ] Lighting plan names DirectionalLight3D color, energy, angle; sky colors; ambient; never-rules.
-- [ ] Post-processing has explicit ON/OFF/value calls per item (Glow, SDFGI, SSAO, SSR, Tonemap, Vignette, Chromatic aberration, Film grain) — NOT a list of options.
-- [ ] DO and DON'T lists each have at least 5 specific, enforceable rules.
-- [ ] DON'T list explicitly forbids chromatic aberration, motion blur, lens flare unless mood justifies them.
-- [ ] Skill asks "May I ..." before any `summer_project_setting` or `summer_set_prop` call.
-- [ ] Skill writes `.summer/art-bible.md` only after asking.
-- [ ] Skill never calls `summer_set_resource_property` on an inline sub_resource (silent-fail trap).
-- [ ] Skill ends with routing to `/summer:audio-direction` or similar.
-
-## Case 2: Failure Path — mixed-technique pitch
-
-**Fixture:** Same as Case 1.
-
-**Input:** "I want PBR realistic characters in a toon-shaded world."
-
-**Expected behavior:**
-
-- Skill identifies the conflict explicitly: "Toon characters in a PBR world fight. The lighting that makes PBR read realistic crushes toon shading; the flat shading that makes toon read clean strips PBR's value."
-- Skill offers a hierarchy: "(a) PBR with toon outlines (one technique), (b) full-toon with PBR-feeling fabric (one technique), (c) accept the conflict and pick which side wins on which assets."
-- Skill does NOT silently pick or design two parallel pipelines.
-
-**Assertions:**
-
-- [ ] Skill names the technique conflict out loud.
-- [ ] Skill explains *why* the techniques fight (lighting interaction).
-- [ ] Skill forces the user to pick one primary technique.
-- [ ] No bible written until the technique is locked.
-
-## Case 3: Edge Case — user pitches pure white + pure black palette
-
-**Fixture:** Same as Case 1.
-
-**Input:** "Black-and-white only, super high contrast. Like Limbo."
-
-**Expected behavior:**
-
-- Skill recognizes the intent (high-contrast monochrome) but flags pure values: "Limbo isn't actually pure black — it's #0a0a0a to #f0f0f0 with subtle warm tint. Pure #000 + #fff makes UI text vibrate and reads as unintentional."
-- Skill offers a near-monochrome palette: e.g., #0a0a0a, #2a2a2a, #6e6e6e, #c0c0c0, #f0f0f0 with one accent color (often warm) reserved for a single mechanic-tied use.
-- Skill writes the bible with off-pure values and documents the single-accent rule in the DO list.
-
-**Assertions:**
-
-- [ ] Skill flags pure #000 / #fff as a red flag and corrects to off-pure values.
-- [ ] Bible includes at least one accent color reserved for mechanic-tied use.
-- [ ] Skill explains *why* (UI vibration, "looks unintentional") not just "use these values".
-
-## Case 4: No Summer MCP — file-edit fallback
-
-**Fixture:** Same as Case 1, but Summer MCP is unavailable.
-
-**Input:** "Define the art direction for my farming sim."
-
-**Expected behavior:**
-
-- Skill detects no MCP.
-- Walks the design beats normally.
-- Instead of `summer_project_setting`, prints the `project.godot` snippet for the user to paste:
-
-  ```
-  [rendering]
-  environment/defaults/default_clear_color=Color(0.227, 0.290, 0.227, 1)
-  anti_aliasing/quality/msaa_3d=2
-  ```
-
-- Instead of `summer_set_prop` on WorldEnvironment, prints the `.tscn` snippet for the user to paste into the main scene.
-- Still writes `.summer/art-bible.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 `project.godot` snippet uses correct INI section format.
-- [ ] Generated `.tscn` snippet for WorldEnvironment is parseable Godot 4.
-- [ ] Skill still writes `.summer/art-bible.md`.
-- [ ] Skill still asks "May I write ..." before each write.
-
----
-
-This spec runs via `/skill-test art-direction spec` (see `_meta/skill-test/SKILL.md`).

package/skills/_tests/specs/asset-strategy.md

@@ -1,19 +0,0 @@
-# Skill Spec: /asset-strategy
-
-> Stub spec. Expand with Happy / Failure / Edge cases. See `fps-controller.md` for the canonical format.
-
-## Fixture
-
-- TBD
-
-## Case 1: Happy Path
-
-**Input:** "<typical user prompt>"
-
-**Expected MCP tool sequence (in order):**
-
-1. TBD
-
-**Assertions:**
-
-- [ ] TBD