summer-engine 2.8.2 → 3.1.0

package/{skills/2d-assets → library/skills}/concept-art/SKILL.md

@@ -13,7 +13,7 @@ paths: ["assets/**", "art/**", "concepts/**"]
 
 This skill produces **3-4 rough concept images** of the same subject under different stylistic interpretations. The goal is not the final asset — the goal is to give the user something visual to react to so they can lock a direction. Variants are deliberately divergent (different palette, mood, framing, era) so the user has real choices, not four near-identical takes.
 
-If the user wants ONE polished image (a dialogue portrait, a hero card), this is the wrong skill — route to `summer:2d-assets/character-portrait`. The `summer:asset-pipeline/asset-strategy` meta-router uses the disambiguation phrase **"Quick check — exploring the look (3-4 variants for art direction) or generating a final character portrait for dialogue UI?"** to send users to one of the two. If you arrived here without that question being asked, ask it before generating.
+If the user wants ONE polished image (a dialogue portrait, a hero card), this is the wrong skill — route to `character-portrait`. The `asset-strategy` meta-router uses the disambiguation phrase **"Quick check — exploring the look (3-4 variants for art direction) or generating a final character portrait for dialogue UI?"** to send users to one of the two. If you arrived here without that question being asked, ask it before generating.
 
 ## When to use
 
@@ -25,11 +25,11 @@ If the user wants ONE polished image (a dialogue portrait, a hero card), this is
 
 ## When NOT to use
 
-- The user wants a single locked portrait for a dialogue UI → `summer:2d-assets/character-portrait`.
-- The user wants pixel art specifically → `summer:2d-assets/pixel-art`.
-- The user wants a UI icon or HUD element → `summer:2d-assets/ui-graphics`.
-- The user wants a tileable wall/floor texture → `summer:2d-assets/tileable-texture`.
-- The user wants an image-to-3D reference → `summer:asset-pipeline/asset-strategy` (the 3D pipeline has its own prompt suffix).
+- The user wants a single locked portrait for a dialogue UI → `character-portrait`.
+- The user wants pixel art specifically → `pixel-art`.
+- The user wants a UI icon or HUD element → `ui-graphics`.
+- The user wants a tileable wall/floor texture → `tileable-texture`.
+- The user wants an image-to-3D reference → `asset-strategy` (the 3D pipeline has its own prompt suffix).
 
 ## Steps
 
@@ -39,7 +39,7 @@ Before generating, ask once:
 
 > Quick check — exploring the look (3-4 variants for art direction) or generating a final character portrait for dialogue UI?
 
-If "final" → hand off to `summer:2d-assets/character-portrait`. If "explore" → continue.
+If "final" → hand off to `character-portrait`. If "explore" → continue.
 
 ### 2. Search for prior concepts
 
@@ -122,7 +122,7 @@ The structure: **subject + axis variant + "concept art" + lighting/atmosphere**.
 - **User says "just one" after you propose 4.** That's a `character-portrait` job. Hand off.
 - **User wants 8+ variants.** Generate 4 first; if the user wants more on the same axis, generate 4 more. Don't dump 8 at once — overload paralyzes choice.
 - **Subject is a fully described scene, not an asset.** You're producing key art, not asset reference. Ask for wide cinematic framing in the prompt and bias toward atmospheric — you cannot set an aspect ratio over MCP.
-- **User wants the final to be 3D.** After they pick a direction, route to `summer:asset-pipeline/asset-strategy` — concept-art images are not 3D-ready references (they have backgrounds, scene context, dramatic lighting baked in). The 3D pipeline needs its own clean white-background reference.
+- **User wants the final to be 3D.** After they pick a direction, route to `asset-strategy` — concept-art images are not 3D-ready references (they have backgrounds, scene context, dramatic lighting baked in). The 3D pipeline needs its own clean white-background reference.
 
 ## Fallback (no MCP)
 
@@ -140,14 +140,14 @@ Tell the user to run via the Summer dashboard, then come back and `summer_import
 
 Once the user picks a direction:
 
-- **Character / NPC final** → `summer:2d-assets/character-portrait` (use the picked variant as `referenceImageUrl`).
-- **3D model from this concept** → `summer:asset-pipeline/asset-strategy` (regenerate a 3D-ready reference; concept art is not 3D-ready as-is).
-- **Tileable texture from this mood** → `summer:2d-assets/tileable-texture`.
-- **Pixel-art version** → `summer:2d-assets/pixel-art`.
+- **Character / NPC final** → `character-portrait` (use the picked variant as `referenceImageUrl`).
+- **3D model from this concept** → `asset-strategy` (regenerate a 3D-ready reference; concept art is not 3D-ready as-is).
+- **Tileable texture from this mood** → `tileable-texture`.
+- **Pixel-art version** → `pixel-art`.
 - **Lock the visual direction** → write the choice into `.summer/GameSoul.md` under `## Visual style` so future asset skills inherit it.
 
 ## See also
 
-- `summer:asset-pipeline/asset-strategy` — meta-router that delegates here vs other 2d-assets skills.
-- `summer:2d-assets/character-portrait` — the polished single-image counterpart.
-- `../../../references/mcp-tools-reference.md` — `summer_generate_image` parameter schema.
+- `asset-strategy` — meta-router that delegates here vs other 2d-assets skills.
+- `character-portrait` — the polished single-image counterpart.
+- `../../references/mcp-tools-reference/mcp-tools-reference.md` — `summer_generate_image` parameter schema.

package/library/skills/concept-art/resource.yaml

@@ -0,0 +1,34 @@
+id: skill/concept-art
+kind: skill
+version: 1.0.2
+summary: Explore art direction with 3-4 rough concept variants of a character, environment, or prop to pick a vibe before committing to a final asset.
+use_when:
+  - exploring art direction with rough variants before committing to a final asset
+  - the user wants a mood board, rough sketches, or 'what could this look like'
+do_not_use_when:
+  - generating a final polished asset — concepts are evocative drafts, not finals
+facets:
+  lifecycle:
+    - build
+  domains:
+    - 2d
+    - assets
+  modalities:
+    - images
+    - assets
+compatibility:
+  engine: ">=4.6"
+related:
+  skills:
+    - skill/character-portrait
+    - skill/pixel-art
+    - skill/tileable-texture
+    - skill/ui-graphics
+    - skill/asset-strategy
+    - skill/create-asset-sheet
+source: official
+license: MIT
+status: stable
+recommended: true
+aliases:
+  - skills/2d-assets/concept-art

package/{skills/2d-assets → library/skills}/create-asset-sheet/SKILL.md

@@ -35,10 +35,10 @@ Categories the classifier outputs (used to route into downstream pipelines):
 
 ## When NOT to use
 
-- The user wants a **single** asset → `summer:2d-assets/pixel-art` or `summer:2d-assets/character-portrait`.
-- The user wants character **animation** (walk cycle, attack frames) → `summer:2d-assets/sprite-sheet`.
-- The user wants **3D models** of a planned pack → not yet supported in one shot; loop `summer:2d-assets/concept-art` → image-to-3D per item, or use `summer:asset-pipeline/asset-strategy` to pick the right path.
-- The user wants **terrain tiles that connect seamlessly** (auto-tiling / Wang tiles) → `summer:2d-assets/tileable-texture` is the right home for edge logic; this skill produces standalone tiles, not edge variants.
+- The user wants a **single** asset → `pixel-art` or `character-portrait`.
+- The user wants character **animation** (walk cycle, attack frames) → `sprite-sheet`.
+- The user wants **3D models** of a planned pack → not yet supported in one shot; loop `concept-art` → image-to-3D per item, or use `asset-strategy` to pick the right path.
+- The user wants **terrain tiles that connect seamlessly** (auto-tiling / Wang tiles) → `tileable-texture` is the right home for edge logic; this skill produces standalone tiles, not edge variants.
 
 ## The cleanest path: the studio wizard
 
@@ -50,7 +50,7 @@ https://summerengine.com/studio/create-tileset
 
 Direct the user there if they're working in the browser. The wizard:
 
-- Offers a 2D / 3D mode toggle (2D is the slice flow described here; 3D is a soft pointer to `summer:2d-assets/concept-art` + per-asset image-to-3D for now)
+- Offers a 2D / 3D mode toggle (2D is the slice flow described here; 3D is a soft pointer to `concept-art` + per-asset image-to-3D for now)
 - Surfaces six prompt templates (tile sheet, UI kit, menu, character pack, biome, freeform)
 - Lets the user upload an existing sheet if they have one (skip generation)
 - Shows variants in a grid with full-screen lightbox + arrow-key toggling
@@ -147,10 +147,10 @@ now calls the same server-side slicer as the Studio wizard.
 ## What this skill does NOT do (yet)
 
 - Per-asset planning + individual generation (the Codex-style flow where each asset is generated separately at full resolution). The planner endpoint exists (`POST /api/art/plan-asset-pack`) but the per-asset gen loop is not wired into the wizard yet.
-- 3D pack assembly. The 3D mode in the wizard is a placeholder pointer to `summer:2d-assets/concept-art` + image-to-3D for now.
+- 3D pack assembly. The 3D mode in the wizard is a placeholder pointer to `concept-art` + image-to-3D for now.
 - Character animation routing. Once a slice is classified as `character`, the next step (sprite-sheet generation) is a separate skill that the user has to invoke manually. Auto-routing is on the roadmap.
-- Terrain auto-tiling / Wang-tile generation. Use `summer:2d-assets/tileable-texture` for that.
-- Level composition / scene assembly. Use `summer:level-design/design-level`.
+- Terrain auto-tiling / Wang-tile generation. Use `tileable-texture` for that.
+- Level composition / scene assembly. Use `design-level`.
 
 ## Honest cost estimate
 

package/library/skills/create-asset-sheet/resource.yaml

@@ -0,0 +1,33 @@
+id: skill/create-asset-sheet
+kind: skill
+version: 1.0.3
+summary: Generate a pack of 2D game assets from one prompt — tile sheet, UI kit, character pack, or biome set — sliced, classified, and saved as one pack ArtAsset.
+use_when:
+  - generating a pack of 2D game assets from a single prompt — a tile sheet, UI kit, menu screen, character pack, or biome set
+  - many matching sprites, tiles, or UI pieces are needed in one consistent style at once
+facets:
+  lifecycle:
+    - build
+  domains:
+    - 2d
+    - assets
+  modalities:
+    - images
+    - assets
+compatibility:
+  engine: ">=4.6"
+related:
+  skills:
+    - skill/character-portrait
+    - skill/concept-art
+    - skill/pixel-art
+    - skill/sprite-sheet
+    - skill/tileable-texture
+    - skill/asset-strategy
+    - skill/design-level
+source: official
+license: MIT
+status: stable
+recommended: false
+aliases:
+  - skills/2d-assets/create-asset-sheet

package/{skills/debugging → library/skills}/debug/SKILL.md

@@ -40,7 +40,7 @@ Do not skip steps. Do not loop back to "Hypothesize" without re-running the chea
 
 ### 0. Support report mode
 
-If the user asks for `/summer debug`, "send this to Summer", "make a report", or they are stuck in Codex/cloud/another agent environment, create a portable report first:
+If the user asks for `/summer debug`, "send this to Summer", "make a report", or they are stuck in Codex, a cloud sandbox, or another agent environment, create a portable report first:
 
 ```
 summer_create_debug_report({
@@ -143,7 +143,7 @@ Surface the proposed fix in plain language and ask permission. Two patterns:
 
 - For GDScript edits: `Read` the 20–40 lines around the error, `Edit` the exact change. Don't read the whole file. Don't reformat. Don't rename other things.
 - For scene edits: use the appropriate `summer_*` tool (`summer_add_node`, `summer_set_prop`, `summer_replace_node`). Group multi-step changes in `summer_batch` for one undo step.
-- **Trap to avoid:** never call `summer_set_resource_property` against an inline `sub_resource` — the value is silently dropped. If the property is on a nested resource, first call `summer_set_prop` with the resource class name to instantiate a standalone resource, then drill in. See `../../../references/mcp-tools-reference.md`.
+- **Nested resource properties:** `summer_set_resource_property` works against inline `sub_resource` targets too — pass `nodePath`, `resourceProperty`, and `subProperty` (there is no dotted `"mesh.size"` form). Structural failures (`node not found`, `property is not a resource`, `resource is null`) are explicit errors; a bad value shape is not — a JSON object instead of a Godot literal string, a misspelled `key`/`subProperty`, or a wrong-typed value returns `ok:true` yet silently no-ops or coerces destructively on current engines (dict → material cleared; dict → `Color(0,0,0,1)`; newer engines reject these with `unknown_property` / `bad_value_shape` / `type_mismatch`). Pass class names and `Color(...)`/`Vector3(...)` strings, and confirm the fix in the saved `.tscn` or a snapshot diff, never from `ok` alone. See `../../references/mcp-tools-reference/mcp-tools-reference.md`.
 
 ### 6. Verify — re-run the diagnostic that found it
 
@@ -224,7 +224,7 @@ This covers what static diagnostics cannot: pressed input, live scene tree (`dum
 
 ### What still genuinely needs the user
 
-- **Whether it feels right.** Frame counts and reports cannot tell you the jump feels floaty. See `summer:debugging-game-feel`.
+- **Whether it feels right.** Frame counts and reports cannot tell you the jump feels floaty. See `debugging-game-feel`.
 - **Hardware-specific and non-deterministic behaviour.** A bug that only fires on their GPU, their controller, or one run in twenty.
 - **A judgement call on intent.** "Is this the behaviour you wanted?" is a question, not a measurement.
 

package/library/skills/debug/resource.yaml

@@ -0,0 +1,31 @@
+id: skill/debug
+kind: skill
+version: 1.0.4
+summary: Disciplined bug/crash/error loop for Summer projects — script errors, console, debugger, hypothesis, fix, verify — before making code or scene changes.
+use_when:
+  - the user reports a bug, crash, error, or unexpected behavior in a Summer project, before making code or scene changes
+  - the player falls through the floor or clips through walls
+  - the game freezes or nothing happens when I press a key
+  - it crashes when I open the inventory or load a scene
+facets:
+  lifecycle:
+    - build
+  domains:
+    - debug
+    - verification
+  modalities:
+    - scripts
+    - scenes
+compatibility:
+  engine: ">=4.6"
+related:
+  skills:
+    - skill/make-game
+    - skill/scene-composition
+    - skill/gdscript-patterns
+source: official
+license: MIT
+status: stable
+recommended: true
+aliases:
+  - skills/debugging/debug

package/{skills/workflow → library/skills}/debugging-game-feel/SKILL.md

@@ -11,19 +11,19 @@ description: Use when a gameplay feature works correctly but feels wrong — flo
 
 **Core principle:** Game-feel bugs are tuning bugs, not logic bugs. Treat them with discipline — isolate one variable, compare to a reference, measure what you can, feel what you can't.
 
-This skill is for the diagnostic phase. The polish-and-juice layer (screen shake, hit-stop, particles, sound design) is `summer:game-feel` — go there once you've identified WHICH variable is wrong.
+This skill is for the diagnostic phase. The polish-and-juice layer (screen shake, hit-stop, particles, sound design) is `game-feel` — go there once you've identified WHICH variable is wrong.
 
 ## When To Use
 
 - The user says: "feels floaty", "feels mushy", "feels off", "feels sluggish", "doesn't feel right", "lacks impact", "lacks weight", "doesn't feel satisfying".
-- The feature passes `summer:playtesting-a-feature` (no errors, golden path runs) but still doesn't feel right.
+- The feature passes `playtesting-a-feature` (no errors, golden path runs) but still doesn't feel right.
 - You're tuning movement, combat, camera, or any interaction with frame-level timing.
 
 ## When NOT To Use
 
-- The feature has a **concrete reproducible bug** — go to `summer:investigating-bugs`.
-- The feature **crashes or throws** — go to `summer:debug`.
-- The feature **hasn't been built yet** — design it via `summer:brainstorming` first.
+- The feature has a **concrete reproducible bug** — go to `investigating-bugs`.
+- The feature **crashes or throws** — go to `debug`.
+- The feature **hasn't been built yet** — design it via `brainstorming` first.
 
 ## The Iron Law
 
@@ -164,7 +164,7 @@ These are diagnostic tools, not lecture material. When the user says "feels weig
 | "The user said floaty so I'm jacking gravity" | "Floaty" can also mean weak air control, slow terminal velocity, or too-long apex hang. Confirm before tweaking. |
 | Skipping the play step ("I'll just bump the number and trust the feel") | Game feel is felt, not predicted. Play every tweak. |
 | Adding "while I'm here" tweaks to unrelated features | Game feel debugging is a focused activity. Stay on the one feature. |
-| Going to `summer:game-feel` before identifying the broken variable | Juice on top of a broken tuning makes the bug louder. Fix tuning first. |
+| Going to `game-feel` before identifying the broken variable | Juice on top of a broken tuning makes the bug louder. Fix tuning first. |
 | Spending >30 minutes on one variable without progress | The anchor is wrong, or the variable is wrong. Step back, re-anchor. |
 
 ## Rationalization Prevention
@@ -181,14 +181,14 @@ These are diagnostic tools, not lecture material. When the user says "feels weig
 
 After diagnosis pins down which variable(s) are wrong, the tuning is done — but the feature may still want polish. Hand off to:
 
-- `summer:game-feel` — for the screen-shake, hit-stop, particle, sound layer once tuning is locked.
-- `summer:debug` — if mid-debug you discover an actual error (signal not firing, node freed) hiding under the feel issue.
+- `game-feel` — for the screen-shake, hit-stop, particle, sound layer once tuning is locked.
+- `debug` — if mid-debug you discover an actual error (signal not firing, node freed) hiding under the feel issue.
 
 ## The Bottom Line
 
 Feel bugs are tuning bugs. Tuning is a one-variable-at-a-time discipline. Anchor to a reference. Tweak one number. Play it. Decide. Repeat.
 
 **Related skills:**
-- `summer:investigating-bugs` — for logical bugs with concrete repros, not feel.
-- `summer:playtesting-a-feature` — the playtest discipline this skill plugs into.
-- `summer:debug` — when the feel investigation surfaces an actual error.
+- `investigating-bugs` — for logical bugs with concrete repros, not feel.
+- `playtesting-a-feature` — the playtest discipline this skill plugs into.
+- `debug` — when the feel investigation surfaces an actual error.

package/library/skills/debugging-game-feel/resource.yaml

@@ -0,0 +1,25 @@
+id: skill/debugging-game-feel
+kind: skill
+version: 1.0.3
+summary: Debug features that work but feel wrong — floaty jumps, mushy combat, sluggish camera — subjective bugs living in tuning, timing, and feedback layers.
+use_when:
+  - a gameplay feature works correctly but feels wrong — floaty jumps, mushy combat, sluggish camera, weightless impacts
+  - tuning jump height, gravity, camera lag, hit-stop, or impact feedback until controls feel right
+do_not_use_when:
+  - the bug is a logic error rather than subjective feel — use logical bug debugging
+facets:
+  lifecycle:
+    - build
+  domains:
+    - agent-workflow
+    - gameplay
+  modalities:
+    - project
+compatibility:
+  engine: ">=4.6"
+source: official
+license: MIT
+status: stable
+recommended: false
+aliases:
+  - skills/workflow/debugging-game-feel

package/{skills/level-design → library/skills}/design-level/SKILL.md

@@ -239,9 +239,9 @@ Ask:
 End with:
 
 > Skeleton + design doc saved. Next:
-> - `/summer:design-mechanic` to design any mechanics this level requires that aren't designed yet.
-> - `/summer:design-npc` to design the enemies (E1-E4) in detail.
-> - `/summer:art-direction` if the visual style isn't pinned yet.
+> - `/design-mechanic` to design any mechanics this level requires that aren't designed yet.
+> - `/design-npc` to design the enemies (E1-E4) in detail.
+> - `/art-direction` if the visual style isn't pinned yet.
 > - Or open `levels/<level-name>.tscn` and start blocking out geometry.
 
 ## Common mistakes
@@ -266,10 +266,10 @@ This skill creates a new scene file (`.tscn`) and a design doc (`.md`). Group wr
 
 This is a workflow that produces a skeleton scene. For runnable level examples, see:
 
-- `template-id: template-3d-fps` (https://github.com/SummerEngine/FPS-template-Summer-Engine) ships a sample arena.
-- `template-id: template-3d-platformer` (TBD) for jump-based level samples.
+- `summer create 3d-fps-old-school` ships a sample arena.
+- `summer create 3d-third-person-controller` gives a jump-capable character to test level layouts against.
 
-The skeleton this skill produces is meant to be filled in via `/summer:design-mechanic`, gridmap blockout, or a template merge.
+The skeleton this skill produces is meant to be filled in via `/design-mechanic`, gridmap blockout, or a template merge.
 
 ## See also
 

package/library/skills/design-level/resource.yaml

@@ -0,0 +1,31 @@
+id: skill/design-level
+kind: skill
+version: 1.0.3
+summary: Design a single level — layout, pacing, encounters, secrets, reward gating — outputs a level design doc and a node-tree skeleton for summer_create_scene.
+use_when:
+  - designing a single level — layout, pacing, encounters, secrets, reward gating
+  - turning a level idea into a layout with a critical path, encounters, secrets, and pacing beats
+facets:
+  lifecycle:
+    - build
+  domains:
+    - level-design
+    - game-design
+  modalities:
+    - docs
+    - scenes
+compatibility:
+  engine: ">=4.6"
+related:
+  skills:
+    - skill/design-npc
+    - skill/design-mechanic
+    - skill/3d-lighting
+    - skill/art-direction
+    - skill/brainstorm-game
+source: official
+license: MIT
+status: stable
+recommended: true
+aliases:
+  - skills/level-design/design-level

package/{skills/gameplay-mechanics → library/skills}/design-mechanic/SKILL.md

@@ -160,7 +160,7 @@ lifetime = 0.4
 
 ### 7. Write the GDScript stub
 
-Stub only — implementation is the next session. Typed GDScript throughout (see `summer:scripting-patterns/gdscript-patterns`). For double-jump:
+Stub only — implementation is the next session. Typed GDScript throughout (see `gdscript-patterns`). For double-jump:
 
 ```gdscript
 class_name PlayerController
@@ -259,8 +259,8 @@ This skill writes scene nodes and one or more files (`.gd`, `.summer/mechanics/<
 
 For full character mechanics in a runnable starter:
 
-- FPS variant → `template-id: template-3d-fps` (https://github.com/SummerEngine/FPS-template-Summer-Engine)
-- Platformer → `template-id: template-3d-platformer` (TBD)
+- FPS variant → `summer create 3d-fps-old-school`
+- Platformer → `summer create 3d-third-person-controller` (jump-capable character; no dedicated 3D platformer template yet)
 
 This skill is a workflow that designs and scaffolds — the templates are runnable bases the mechanic plugs into.
 

package/library/skills/design-mechanic/resource.yaml

@@ -0,0 +1,31 @@
+id: skill/design-mechanic
+kind: skill
+version: 1.0.2
+summary: Design one game mechanic in detail — input, response, feedback, failure modes, depth, tunables — outputs a design doc, node-graph sketch, GDScript stub.
+use_when:
+  - designing one specific game mechanic in detail — input, response, feedback, failure modes, depth, tunables
+  - add a grappling hook, dash, double jump, wall run, or parry
+facets:
+  lifecycle:
+    - build
+  domains:
+    - gameplay
+    - game-design
+  modalities:
+    - docs
+    - scripts
+compatibility:
+  engine: ">=4.6"
+related:
+  skills:
+    - skill/audio-direction
+    - skill/fps-controller
+    - skill/design-level
+    - skill/brainstorm-game
+    - skill/gdscript-patterns
+source: official
+license: MIT
+status: stable
+recommended: true
+aliases:
+  - skills/gameplay-mechanics/design-mechanic

package/{skills/ai-and-npcs → library/skills}/design-npc/SKILL.md

@@ -209,9 +209,13 @@ summer_set_resource_property(scenePath="res://main.tscn", nodePath="./World/Enem
 `summer_set_resource_property` works against scene-embedded (`[sub_resource]`)
 resources exactly as it does against external `.tres` files — it reads the
 property off the node and writes the sub-property onto whatever Resource is
-there. Its only failures are explicit errors (`node not found`, `property is not
-a resource`, `resource is null`). The order that matters is: assign the resource
-first, then set sub-properties.
+there. Structural failures are explicit errors (`node not found`, `property is
+not a resource`, `resource is null`); a bad value shape is not — a JSON object
+instead of a Godot literal string, a misspelled `subProperty`, or a wrong-typed
+value returns `ok:true` yet silently no-ops or coerces destructively on current
+engines. Pass class names and literal strings (`"12.0"`, `"Color(r, g, b, a)"`)
+and confirm the result in the saved `.tscn`, never from `ok` alone. The order
+that matters is: assign the resource first, then set sub-properties.
 
 Connect signals:
 

package/library/skills/design-npc/resource.yaml

@@ -0,0 +1,29 @@
+id: skill/design-npc
+kind: skill
+version: 1.0.2
+summary: Design enemy/NPC/boss/companion behavior — perception, personality, intent, action state machine, telegraphs — outputs a GDScript stub plus node tree.
+use_when:
+  - designing an enemy, NPC, boss, companion, civilian, or wave-spawned mob's behavior — perception, intent, state machine, telegraphs, defeat handling
+  - enemies that patrol, chase, attack, or flee when they see the player (line of sight)
+facets:
+  lifecycle:
+    - build
+  domains:
+    - ai
+    - npc
+  modalities:
+    - scripts
+    - scenes
+compatibility:
+  engine: ">=4.6"
+related:
+  skills:
+    - skill/game-feel
+    - skill/vfx-dissolve
+    - skill/vfx-hit-spark
+source: official
+license: MIT
+status: stable
+recommended: true
+aliases:
+  - skills/ai-and-npcs/design-npc

package/{skills/workflow → library/skills}/diagnosing-perf-regressions/SKILL.md

@@ -11,7 +11,7 @@ There is a difference between "this game is slow" and "this game got slow." This
 
 **Core principle:** A regression has a cause. The cause is a specific change. Bisect to find the change, then root-cause from there.
 
-This skill is **not** general performance tuning. If the game has always run at 30fps and you want to push it to 60, that is `summer:tune-performance` (the domain skill for budget-driven optimization). This skill is the diagnostic — what broke, where, when.
+This skill is **not** general performance tuning. If the game has always run at 30fps and you want to push it to 60, that is `tune-performance` (the domain skill for budget-driven optimization). This skill is the diagnostic — what broke, where, when.
 
 ## When To Use
 
@@ -22,9 +22,9 @@ This skill is **not** general performance tuning. If the game has always run at
 
 ## When NOT To Use
 
-- "The game has always been slow, help me speed it up." → `summer:tune-performance`.
-- "I want to know if my game is fast enough to ship." → `summer:tune-performance`.
-- "The game crashes." → `summer:debug`.
+- "The game has always been slow, help me speed it up." → `tune-performance`.
+- "I want to know if my game is fast enough to ship." → `tune-performance`.
+- "The game crashes." → `debug`.
 
 ## The Iron Law
 
@@ -154,8 +154,8 @@ State the result with the number: "Reverted the per-frame `get_tree().get_nodes_
 
 | Situation | Go to |
 |---|---|
-| Regression confirmed and root cause known, but the fix is "make the feature cheaper" rather than "undo the change" | `summer:tune-performance` for the optimization pass |
-| The regression turns out to be a crash or error in disguise (the slow path is throwing exceptions in a tight loop) | `summer:debug` |
+| Regression confirmed and root cause known, but the fix is "make the feature cheaper" rather than "undo the change" | `tune-performance` for the optimization pass |
+| The regression turns out to be a crash or error in disguise (the slow path is throwing exceptions in a tight loop) | `debug` |
 | The cause is a Godot version change or engine-side regression | Surface to the user; this is not a project-side fix |
 | Bisect lands on a commit that touches 40 files | Subdivide the commit: check out the commit, revert subsets, re-measure |
 
@@ -209,7 +209,7 @@ A regression is a delta. Diagnose the delta, not the codebase.
 Measure now. Measure last-good. Bisect what changed. Match to a Godot perf cliff. A/B one variable. Re-measure. Done.
 
 **Related skills:**
-- `summer:tune-performance` — for general optimization once the regression is fixed or when no regression exists.
-- `summer:investigating-bugs` — when the slow path turns out to be a logic bug (errors in a tight loop).
-- `summer:debug` — when the perf issue is actually a crash or freeze.
-- `summer:verification-before-completion` — to claim the fix worked, with numbers.
+- `tune-performance` — for general optimization once the regression is fixed or when no regression exists.
+- `investigating-bugs` — when the slow path turns out to be a logic bug (errors in a tight loop).
+- `debug` — when the perf issue is actually a crash or freeze.
+- `verification-before-completion` — to claim the fix worked, with numbers.

package/library/skills/diagnosing-perf-regressions/resource.yaml

@@ -0,0 +1,25 @@
+id: skill/diagnosing-perf-regressions
+kind: skill
+version: 1.0.3
+summary: Find why frame rate, frame time, or load time got worse since a known-good state — regression hunting, not general performance tuning.
+use_when:
+  - frame rate, frame time, or load time has gotten worse since a known-good state — 'it used to run at 60, now it's at 30'
+  - bisecting recent scene, script, or asset changes to find which one slowed frame time or loading
+do_not_use_when:
+  - general performance tuning with no known-good baseline
+facets:
+  lifecycle:
+    - build
+  domains:
+    - agent-workflow
+    - performance
+  modalities:
+    - project
+compatibility:
+  engine: ">=4.6"
+source: official
+license: MIT
+status: stable
+recommended: false
+aliases:
+  - skills/workflow/diagnosing-perf-regressions

package/{skills/workflow → library/skills}/dispatching-parallel-agents/SKILL.md

@@ -111,17 +111,17 @@ Return: Summary of what you found and what you fixed.
 
 ## Common Mistakes
 
-**❌ Too broad:** "Fix all the tests" - agent gets lost
-**✅ Specific:** "Fix agent-tool-abort.test.ts" - focused scope
+**Too broad:** "Fix all the tests" - agent gets lost
+**Good: Specific:** "Fix agent-tool-abort.test.ts" - focused scope
 
-**❌ No context:** "Fix the race condition" - agent doesn't know where
-**✅ Context:** Paste the error messages and test names
+**No context:** "Fix the race condition" - agent doesn't know where
+**Good: Context:** Paste the error messages and test names
 
-**❌ No constraints:** Agent might refactor everything
-**✅ Constraints:** "Do NOT change production code" or "Fix tests only"
+**No constraints:** Agent might refactor everything
+**Good: Constraints:** "Do NOT change production code" or "Fix tests only"
 
-**❌ Vague output:** "Fix it" - you don't know what changed
-**✅ Specific:** "Return summary of root cause and changes"
+**Vague output:** "Fix it" - you don't know what changed
+**Good: Specific:** "Return summary of root cause and changes"
 
 ## When NOT to Use
 

package/library/skills/dispatching-parallel-agents/resource.yaml

@@ -0,0 +1,23 @@
+id: skill/dispatching-parallel-agents
+kind: skill
+version: 1.0.3
+summary: Work 2+ independent tasks in parallel when they share no state and have no sequential dependencies.
+use_when:
+  - facing 2+ independent tasks that can be worked on without shared state or sequential dependencies
+  - a plan has several independent workstreams that can run at the same time
+facets:
+  lifecycle:
+    - build
+  domains:
+    - agent-workflow
+    - meta
+  modalities:
+    - docs
+compatibility:
+  engine: ">=4.6"
+source: official
+license: MIT
+status: stable
+recommended: false
+aliases:
+  - skills/workflow/dispatching-parallel-agents