summer-engine 2.0.0 → 2.3.0

package/skills/2d-assets/character-portrait/SKILL.md

@@ -0,0 +1,196 @@
+---
+name: character-portrait
+description: Use when generating a single, polished bust/portrait of a character for dialogue UI, character-select screens, lore cards, or codex entries. One character, locked composition, VN-style. Trigger on "character portrait", "dialogue portrait", "VN portrait", "character bust", "headshot", "character select image", "lore card art".
+license: MIT
+compatibility: [Cursor, Claude Code, Windsurf, Codex]
+category: 2d-assets
+user-invocable: true
+allowed-tools: Read Grep Glob Write Edit summer_generate_image summer_search_assets summer_import_from_url summer_set_resource_property
+paths: ["assets/**", "art/portraits/**", "ui/portraits/**"]
+---
+
+# character-portrait — Locked Bust for Dialogue UI
+
+This skill produces ONE polished character portrait — bust or shoulders-up framing, neutral or stylized background, designed to drop into a dialogue UI, character-select screen, or lore card. It is the **opposite** of `summer:2d-assets/concept-art`: concept art explores; this skill commits.
+
+The single biggest failure mode is **inconsistency across a cast**. Generating five party members one at a time without a locked anchor produces five images that look like they're from five different games — different lighting, different angle, different palette, different rendering style. This skill makes you write a **locked anchor suffix** the first time and re-use it verbatim for every subsequent portrait.
+
+If the user is still exploring the look, this is the wrong skill — route to `summer:2d-assets/concept-art` first, lock a direction, then come back here. The `summer:asset-pipeline/asset-strategy` meta-router asks **"Quick check — exploring the look (3-4 variants for art direction) or generating a final character portrait for dialogue UI?"** to disambiguate.
+
+## When to use
+
+- "Generate a portrait for the merchant NPC."
+- "I need a character-select image for the four playable heroes."
+- "Make a lore-card image of the king."
+- "Add a VN-style dialogue portrait for Aria."
+- The cast is locked and the visual direction is locked; you're producing finals.
+
+## When NOT to use
+
+- The user is still exploring → `summer:2d-assets/concept-art`.
+- The user wants pixel art → `summer:2d-assets/pixel-art`.
+- The user wants a full-body 3D model → `summer:asset-pipeline/asset-strategy`.
+- The user wants 4+ animated expressions of the same character — generate one base portrait here, then use img2img with the base as `referenceImageUrl` for each expression.
+
+## Steps
+
+### 1. Read or establish the locked anchor
+
+Check `.summer/portrait-anchor.md` first.
+
+```
+Read .summer/portrait-anchor.md
+```
+
+If it doesn't exist, this is the first portrait in the cast — you must define the anchor now. Ask the user (or infer from `.summer/GameSoul.md`):
+
+- **Framing:** bust (chest up) or shoulders-up?
+- **Angle:** straight-on, three-quarter left, three-quarter right?
+- **Lighting:** soft front, dramatic side, rim-lit, golden-hour?
+- **Background:** flat color, soft gradient, painterly blur, in-world environment?
+- **Rendering style:** painterly, anime, semi-realistic, line-art-with-flat-color?
+
+Write the anchor to `.summer/portrait-anchor.md`:
+
+```
+## Portrait anchor (re-use verbatim for every cast member)
+
+framing: bust, shoulders to crown of head visible
+angle: three-quarter view, slight turn to character's left
+lighting: soft warm key from upper right, cool fill from left, gentle rim
+background: muted painterly gradient, dark teal to deep brown, no scene detail
+style: semi-realistic painterly, soft edges, oil-painting feel
+aspect: portrait_4_3
+```
+
+Every subsequent portrait in this cast appends the anchor to the prompt verbatim. **Do not edit the anchor mid-cast** unless the user explicitly says "I want the new ones to look different."
+
+### 2. Search for an existing portrait
+
+```
+summer_search_assets(query="<character name> portrait", filter={ kind: "image" })
+```
+
+Reuse beats regenerate. If the user wants to iterate on an existing one, pull its URL and pass it as `referenceImageUrl` for img2img.
+
+### 3. Build the prompt — character + anchor
+
+Pattern:
+
+```
+<character description>. <anchor framing/angle/lighting/background/style>
+```
+
+The character description should include: identity (age, build, hair, distinctive features), expression, costume/equipment, any signature prop. Keep it under 60 words including the anchor.
+
+### 4. Confirm and call
+
+> Generating Aria the witch portrait — 1 image, ~$0.02, model nano-banana-2, anchor locked from `.summer/portrait-anchor.md`. OK?
+
+```
+summer_generate_image(
+  prompt="Aria, young witch, mid-twenties, pale skin, long black hair with silver streak, sharp green eyes, half-smile, wearing dark indigo robes with silver embroidery, raven on shoulder. <anchor verbatim>",
+  model="nano-banana-2",
+  style="none",
+  options={ image_size: "portrait_4_3" }
+)
+```
+
+`style: "none"` because the anchor's "semi-realistic painterly" already specifies style; the preset would fight it.
+
+### 5. Import and wire into UI
+
+```
+summer_import_from_url(
+  url="<fileUrl from generation>",
+  path="res://ui/portraits/aria.png"
+)
+```
+
+For dialogue UI nodes, wire the texture into a `TextureRect`:
+
+```
+summer_set_resource_property(
+  nodePath="/root/UI/DialogueBox/PortraitRect",
+  resourceProperty="texture",
+  value="res://ui/portraits/aria.png"
+)
+```
+
+For character-select with multiple portraits, name files consistently: `aria.png`, `borin.png`, `cael.png`, `dara.png`. Index-able from code via `"res://ui/portraits/%s.png" % character_id`.
+
+### 6. Iterate (img2img) instead of regenerating from scratch
+
+If the user wants the portrait tweaked ("smaller smile", "darker robes"), use img2img with the existing image as `referenceImageUrl`. Preserves identity and lighting.
+
+```
+summer_generate_image(
+  prompt="<original prompt> with a smaller, more subtle smile",
+  referenceImageUrl="<previous fileUrl>",
+  model="nano-banana-2",
+  style="none"
+)
+```
+
+## Prompt patterns
+
+| Goal | Prompt skeleton (subject part only — append anchor verbatim) | Why |
+|---|---|---|
+| Generic NPC | `<name>, <age> <build>, <hair>, <eyes>, <expression>, wearing <costume>` | Identity-first; no scene context |
+| Hero / protagonist | `<name>, <age> <build>, <hair>, <distinctive feature>, confident <expression>, wearing <signature outfit>, holding <signature prop>` | Adds prop for memorability |
+| Antagonist | `<name>, <imposing detail>, <unsettling expression>, wearing <costume with menacing detail>, <signature scar/mark>` | Antagonists need visual asymmetry |
+| Lore card / king | `<name>, <age>, regal <expression>, wearing <ornate detail>, <crown/insignia>, formal portrait pose` | Formal pose overrides anchor's three-quarter |
+| Expression variant | `<previous prompt> with <new expression: angry / surprised / sad / laughing>` + `referenceImageUrl: <base portrait>` | img2img preserves identity |
+| Younger / older variant | `<character> as a <child / elder>` + `referenceImageUrl: <base>` | For flashback / time-skip portraits |
+
+### Bad prompts (and why)
+
+| Bad | Failure mode |
+|---|---|
+| `cool warrior portrait` | No identity, no anchor. Returns generic stock art. |
+| `the witch but make her sad` (no img2img ref) | Without `referenceImageUrl`, you get a *different* witch who is sad. Identity drift. |
+| Anchor inconsistent across cast | Each portrait looks like a different game. The cast doesn't read as a cast. |
+| `full body portrait` | "Portrait" implies bust. If you want full body, say so explicitly AND switch to `image_size: "portrait_4_3"` framed full-body — but that's a different asset class; consider `concept-art` or 3D pipeline. |
+| `transparent background` for a painterly portrait | Painterly + transparent fails on most models. Use a flat or gradient background, then alpha-cut in an editor if you must. |
+
+## Anti-patterns
+
+- **No anchor file.** Every cast member generated ad-hoc looks unrelated. Define the anchor on portrait #1, re-use for the rest of the cast.
+- **Editing the anchor mid-cast.** If you change lighting from "warm key" to "dramatic side" halfway through, the cast splits visually. Either commit to the change and regenerate everyone, or stick with the anchor.
+- **Regenerating from scratch when img2img would do.** Identity drifts every regen. Iterate via `referenceImageUrl`.
+- **Using the portrait as a 3D reference.** Portraits have dramatic lighting, painterly backgrounds, and cropped framing — all of which corrupt 3D generation. For 3D, generate a separate clean white-bg full-body T-pose via `summer:asset-pipeline/asset-strategy`.
+- **Using `style: "realistic"` or `"cartoon"`** when the anchor already names a style. The preset overrides the anchor.
+
+## Edge cases
+
+- **Character has a non-human silhouette (lizardfolk, demon, robot).** The anchor still applies — framing, lighting, background, rendering style. Only the subject description changes. Verify the model can hold the silhouette under "bust framing" — some models default to humanoid.
+- **Player wants to swap costumes mid-game.** Generate one base portrait per costume (`aria_traveler.png`, `aria_robes.png`, `aria_armored.png`) and switch by index. Use img2img from the base for consistency.
+- **Cast of 12+ characters.** Anchor discipline gets harder as fatigue sets in. Print the anchor as a header in your generation script and don't write any prompt without it.
+- **User wants the portrait to "read at small size" (32×32 in a portrait list).** That's pixel-art territory; route to `summer:2d-assets/pixel-art`.
+
+## Fallback (no MCP)
+
+Print the prompt and the call:
+
+```
+summer_generate_image(prompt="<character + anchor>", model="nano-banana-2", style="none", options={ image_size: "portrait_4_3" })
+```
+
+Tell the user to run via the Summer dashboard, then `summer_import_from_url` the result to `res://ui/portraits/<name>.png`.
+
+## Handoff
+
+After the portrait is wired:
+
+- **More cast members** → re-invoke this skill with the same anchor. Don't redefine.
+- **Expression variants** → re-invoke with `referenceImageUrl` set to the base portrait.
+- **Pixel-art version of the same character** → `summer:2d-assets/pixel-art`.
+- **3D model of the same character** → `summer:asset-pipeline/asset-strategy` (the portrait is NOT a usable 3D reference; generate a separate T-pose).
+- **Dialogue system wiring** → `summer:scene-composition` for the UI hierarchy.
+
+## See also
+
+- `summer:2d-assets/concept-art` — explore the look first if not yet locked.
+- `summer:asset-pipeline/asset-strategy` — meta-router and the 3D pipeline.
+- `summer:scene-composition` — wiring the portrait into a dialogue UI scene.
+- `_shared/mcp-tools-reference.md` — `summer_generate_image` parameter schema.

package/skills/2d-assets/concept-art/SKILL.md

@@ -0,0 +1,152 @@
+---
+name: concept-art
+description: Use when the user is exploring art direction — wants 3-4 rough variants of a character, environment, or prop to pick a vibe before committing to a final asset. Generates a batch of evocative concept images, not finals. Trigger on "concept art", "art direction", "explore the look", "give me some variants", "what could this character look like", "mood board", "rough sketches".
+license: MIT
+compatibility: [Cursor, Claude Code, Windsurf, Codex]
+category: 2d-assets
+user-invocable: true
+allowed-tools: Read Grep Glob Write Edit summer_generate_image summer_search_assets summer_import_from_url
+paths: ["assets/**", "art/**", "concepts/**"]
+---
+
+# concept-art — Batch-of-Variants for Art Direction
+
+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.
+
+## When to use
+
+- "I'm not sure what this character should look like — give me some options."
+- "Show me 3-4 directions for the witch."
+- "I want a mood board for the swamp level."
+- Early-project art direction, before the GameSoul.md visual style is locked.
+- The user describes a vibe ("dark fantasy", "Ghibli-esque", "Mobius") and wants to see it rendered.
+
+## 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).
+
+## Steps
+
+### 1. Confirm exploration vs final
+
+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.
+
+### 2. Search for prior concepts
+
+```
+summer_search_assets(query="<subject> concept", filter={ kind: "image" })
+```
+
+If something already exists, ask if the user wants to riff on it (img2img via `referenceImageUrl`) or start fresh.
+
+### 3. Pick a variant axis
+
+Variants must differ on **one explicit axis**, not noise. Pick one:
+
+| Axis | Use when |
+|---|---|
+| Palette / mood | "Should this feel grim or hopeful?" |
+| Era / setting | "Medieval, sci-fi, modern, post-apoc?" |
+| Stylization | "Painterly, anime, photoreal, Mobius line-art?" |
+| Silhouette / proportions | Character design — slim/bulky/childlike/monstrous |
+| Time of day / lighting | Environment — dawn/noon/dusk/night |
+
+State the axis to the user before generating: "I'll vary on **stylization** — painterly, anime, line-art, photoreal. OK?"
+
+### 4. Generate the batch
+
+Issue 3-4 calls in parallel, one per variant. Use the same subject phrasing across all four; only the style-modifier changes.
+
+```
+summer_generate_image(
+  prompt="<subject>. <axis variant 1>. concept art, evocative, rough painterly, atmospheric lighting",
+  model="nano-banana-2",
+  style="none",
+  options={ image_size: "landscape_16_9" }
+)
+```
+
+`style: "none"` is intentional — concept art doesn't want the default "realistic" or "cartoon" preset overriding the prompt's stylistic direction.
+
+### 5. Present the batch
+
+After all 4 return, show the user the thumbnails (link `thumbnailUrl` for each) and ask:
+
+> Which direction lands? I can generate variants on the chosen one, or hand off to `character-portrait` for a final.
+
+Do NOT import any of these as `res://` assets yet. Concept art is reference, not shipped art. Only import once the user picks a winner — then either it goes to `character-portrait` for a polished version or directly to `summer_import_from_url` if they want to use it as-is as a reference.
+
+## Prompt patterns
+
+The structure: **subject + axis variant + "concept art" + lighting/atmosphere**. Keep prompts under 30 words.
+
+| Goal | Prompt that works | Why |
+|---|---|---|
+| Character — palette axis | `young witch with raven familiar. <warm autumn palette / cold blue moonlit palette / sickly green swamp palette / monochrome ash palette>. concept art, painterly, atmospheric` | Locked subject + four explicit palettes |
+| Character — silhouette axis | `goblin warrior. <slim wiry / hulking brute / childlike imp / multi-limbed mutant>. concept art, full body, rough painterly` | Forces real shape variation |
+| Environment — mood axis | `swamp village at dusk. <hopeful warm lanterns / oppressive fog / abandoned ruins / overgrown nature reclaim>. concept art, wide shot, atmospheric` | Mood drives composition |
+| Environment — stylization axis | `mountain temple. <Studio Ghibli soft painterly / Mobius clean line-art / dark Berserk ink / Hayao detailed wash>. concept art, wide establishing shot` | Names real reference styles the model recognizes |
+| Prop — era axis | `royal sword. <bronze age / medieval / ornate baroque / sci-fi energy>. concept art, three-quarter view, neutral background` | Era as the only varying dimension |
+| Creature — physiology axis | `forest spirit. <deer-like elegant / fungal grotesque / jellyfish floating / branch-and-moss elemental>. concept art, atmospheric, painterly` | Forces real morphological divergence |
+
+### Bad prompts (and why)
+
+| Bad | Failure mode |
+|---|---|
+| `cool fantasy character` | No subject, no axis. All 4 variants will look interchangeable. |
+| `make 4 different witches` | Model doesn't render "4 of"; you must call 4 times. |
+| `epic concept art masterpiece trending on artstation` | Adjective soup. Trending-on-artstation is a 2022 cliche; modern models render it as bland slop. |
+| `same character but different` | "Different" is undefined. Pick an axis and name it. |
+
+## Anti-patterns
+
+- **Generating 4 near-identical variants** because you didn't pick a real axis. The user can't choose between four images that all look like the same painting.
+- **Importing concept art as final assets.** These are exploration. The polished version comes from `character-portrait` after a direction is picked.
+- **Using `style: "realistic"` or `style: "cartoon"`** — the preset fights the prompt's stylistic direction. Use `style: "none"` for concept art.
+- **Skipping the disambiguation question.** If you don't ask, you'll get yelled at when you generate 4 portraits and the user wanted one polished bust.
+- **Generating before the GameSoul.md is written.** If `.summer/GameSoul.md` exists, read it first — its visual-style section narrows the axis.
+
+## Edge cases
+
+- **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. Use `image_size: "landscape_16_9"` and bias toward atmospheric.
+- **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.
+
+## Fallback (no MCP)
+
+Print the 4 prompts and the call for each:
+
+```
+summer_generate_image(prompt="<variant 1>", model="nano-banana-2", style="none", options={ image_size: "landscape_16_9" })
+summer_generate_image(prompt="<variant 2>", ...)
+...
+```
+
+Tell the user to run via the Summer dashboard, then come back and `summer_import_from_url` the winning variant.
+
+## Handoff
+
+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`.
+- **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.
+- `_shared/mcp-tools-reference.md` — `summer_generate_image` parameter schema.

package/skills/2d-assets/pixel-art/SKILL.md

@@ -0,0 +1,180 @@
+---
+name: pixel-art
+description: Use when generating pixel-art assets — sprites, items, tiles, portraits in a pixel style at a specific resolution (32×32, 64×64, 128×128). Pixel-perfect grid, limited palette, retro feel. Trigger on "pixel art", "8-bit art", "16-bit sprite", "pixel sprite", "retro tileset", "pixel icon", "pixel portrait".
+license: MIT
+compatibility: [Cursor, Claude Code, Windsurf, Codex]
+category: 2d-assets
+user-invocable: true
+allowed-tools: Read Grep Glob Write Edit summer_generate_image summer_search_assets summer_import_from_url summer_set_resource_property
+paths: ["assets/**", "art/pixel/**", "sprites/**"]
+---
+
+# pixel-art — Pixel-Perfect Sprites and Tiles
+
+This skill generates pixel-art assets — sprites, items, tiles, icons, portraits — at a target resolution (32×32, 64×64, 128×128, etc.). Pixel art has hard constraints (grid alignment, limited palette, no anti-aliased edges) that diffusion models violate by default. This skill encodes the prompt patterns and post-processing discipline that makes the output actually look like pixel art and not "blurry small image."
+
+**Backing tool:** `summer_generate_image` with `style: "pixel"` and an explicit pixel-art prompt. Pass `options.image_size: "square_hd"` and have the agent enforce pixel-perfect by setting the project's default texture filter to Nearest (and downscaling to the target resolution post-gen). Output is upscaled by the model — you generally request a small generation (or downscale post-gen) to get crisp pixels.
+
+## When to use
+
+- "Generate a 32×32 sword icon for the inventory."
+- "I need a pixel-art portrait of the merchant for the dialogue UI."
+- "Make a 64×64 enemy sprite — a slime monster."
+- "Generate a tileset for a grass / dirt / stone biome at 16×16 per tile."
+- The game has a pixel-art aesthetic and the user wants assets in-style.
+
+## When NOT to use
+
+- The user wants a high-resolution painterly portrait → `summer:2d-assets/character-portrait`.
+- The user wants animated frames (walk cycle, attack) → `summer:2d-assets/sprite-sheet` (pixel art is harder for sprite sheets — read that skill's caveats).
+- The user wants a tileable seamless texture (not pixel art) → `summer:2d-assets/tileable-texture`.
+- The game is 3D / non-pixel — verify the user actually wants pixel before generating.
+
+## Steps
+
+### 1. Lock the resolution and palette
+
+Ask the user (or read `.summer/GameSoul.md`):
+
+- **Resolution per asset:** 16×16, 32×32, 64×64, 128×128 are standard. Sprites usually 32 or 64; portraits 64 or 128; icons 16 or 32.
+- **Palette:** named retro palette (NES 56-color, Game Boy 4-color green, PICO-8 16-color, Sweetie-16) OR custom hex list OR "no palette restriction."
+- **Outline:** hard black outline, colored outline, or no outline?
+
+Write to `.summer/pixel-anchor.md` so the rest of the cast/tileset stays consistent:
+
+```
+## Pixel anchor
+
+base resolution: 32x32 per sprite
+palette: PICO-8 16-color
+outline: hard 1px dark outline (NOT pure black — use the palette's darkest color)
+shading: 3-tone (light, mid, shadow), no gradients, no AA
+```
+
+### 2. Search for existing assets
+
+```
+summer_search_assets(query="<subject> pixel", filter={ kind: "image" })
+```
+
+### 3. Build the prompt
+
+Pattern:
+
+```
+pixel art <subject>, <resolution>, <palette>, <outline rule>, <shading rule>, no anti-aliasing, no blur, sharp pixel edges, transparent background
+```
+
+The model can't actually generate at 32×32 — it generates at 1024×1024 with pixel-art *style*. You then downscale to the target resolution post-import for crisp pixels.
+
+### 4. Generate
+
+```
+summer_generate_image(
+  prompt="pixel art slime monster, 32x32 sprite, PICO-8 palette, hard 1px outline in palette's darkest color, 3-tone shading, no anti-aliasing, no blur, sharp pixel edges, transparent background, front-facing",
+  model="nano-banana-2",
+  style="pixel",
+  options={
+    image_size: "square_hd",
+    negative_prompt: "blurry, smooth gradients, anti-aliasing, photorealistic, 3D render, soft edges"
+  }
+)
+```
+
+`negative_prompt` is critical for pixel art — without it the model smuggles in soft edges and gradients.
+
+### 5. Downscale to target resolution
+
+The generated image is 1024×1024 pixel-style. To get true crisp pixels at 32×32:
+
+- Import to the engine, then in the import dock set `Filter: Nearest` (no smoothing).
+- For a true 32×32 atlas/icon, downscale in an external editor (Aseprite, GIMP "nearest neighbor") to 32×32 before importing. Aseprite's "Sprite > Sprite Size" with Nearest gives the cleanest result.
+- In Godot, set `Project Settings → Rendering → Textures → Default Texture Filter: Nearest` if the entire game is pixel-art. This kills bilinear smoothing project-wide.
+
+### 6. Import and wire
+
+```
+summer_import_from_url(url="<fileUrl>", path="res://sprites/slime.png")
+```
+
+For a `Sprite2D`:
+
+```
+summer_set_resource_property(
+  nodePath="/root/Game/Slime/Sprite2D",
+  resourceProperty="texture",
+  value="res://sprites/slime.png"
+)
+```
+
+Confirm `Filter: Nearest` is set in the import dock OR project-wide.
+
+## Prompt patterns
+
+| Goal | Prompt that works | Why |
+|---|---|---|
+| Item icon (32×32) | `pixel art iron sword icon, 32x32, NES palette, hard outline, 3-tone shading, no AA, sharp edges, transparent background, three-quarter view` | Three-quarter view reads better than pure side at 32px |
+| Character sprite (64×64) | `pixel art knight character sprite, 64x64, PICO-8 palette, hard 1px outline, 3-tone shading, front-facing idle pose, no AA, sharp edges, transparent background` | Specifying "idle pose" prevents action poses that don't tile into a sheet |
+| Pixel portrait (128×128) | `pixel art portrait of a young witch, 128x128, custom muted fantasy palette, hard outline, 4-tone shading, bust framing, looking forward, no AA, no blur, transparent background` | Higher resolution allows 4-tone shading; 32px is too small for that |
+| Tileset (16×16/tile) | `pixel art top-down tileset, grass-to-dirt transition, 16x16 per tile, 3x3 grid layout, NES palette, hard outline between tiles, 3-tone shading, no AA, sharp edges` | Tilesets render best in a labeled grid layout |
+| Background object (64×64) | `pixel art mossy boulder, 64x64, fantasy palette, hard outline, 3-tone shading, no AA, transparent background, three-quarter view` | Background props benefit from three-quarter for depth |
+| GB-style asset (Game Boy) | `pixel art skeleton enemy, 32x32, Game Boy 4-color green palette (#0f380f, #306230, #8bac0f, #9bbc0f), hard 1px outline, 2-tone shading, no AA` | Naming the 4 hex codes locks the palette |
+
+### Bad prompts (and why)
+
+| Bad | Failure mode |
+|---|---|
+| `8-bit sword` | "8-bit" is interpreted loosely. Returns a smooth render of a sword with vague pixel feel. Specify resolution + palette + "no AA" explicitly. |
+| `pixel art knight, photorealistic` | Conflicting directives. Model averages and gives you neither. |
+| `pixel art at 32x32` (no negative_prompt) | Model adds soft edges and gradient shading. Always add negative prompt for AA / blur / gradients. |
+| `pixel sprite walk cycle` | Walk cycles need consistent frames — single-prompt sprite sheets fail. Route to `summer:2d-assets/sprite-sheet`. |
+| `cute pixel art` | "Cute" without subject is undefined. Specify what. |
+
+## Anti-patterns
+
+- **Skipping the downscale.** The model returns a 1024×1024 pixel-style image. If you import that as a 1024 texture, the "pixels" are actually 32-pixel blocks of soft color. Downscale to true target resolution OR set `Filter: Nearest` so the up-rendering doesn't smooth.
+- **No `Filter: Nearest`.** Default Godot texture filtering is bilinear. Pixel art bilinearly filtered looks like garbage. Set it on import or project-wide.
+- **No negative prompt.** Without `blurry, anti-aliasing, gradients, soft edges` in the negative, ~50% of generations are off-style.
+- **Inconsistent palette across the cast.** Pick a named palette (PICO-8, NES, custom hex list) and re-use across every asset in the project. Different palettes = the project doesn't read as one game.
+- **Generating walk-cycle frames as one image.** Sprite sheets via single-prompt are unreliable. Route to `summer:2d-assets/sprite-sheet`.
+
+## Edge cases
+
+- **User wants animated pixel sprites.** Generate base sprite here, then per-frame variants via img2img with the base as `referenceImageUrl`. For more than 2-3 frames, route to `summer:2d-assets/sprite-sheet` (and read its caveats).
+- **User wants the entire game in pixel art.** Set `Project Settings → Rendering → Textures → Default Texture Filter: Nearest` once. Saves you from re-setting it on every import.
+- **User wants a high-res "pixel art" portrait that's not actually pixelated** (faux-pixel-aesthetic at full resolution). That's `summer:2d-assets/character-portrait` with a "pixel art aesthetic" prompt — not this skill.
+- **User specifies a palette like "Sweetie-16" or "Endesga-32" and the model ignores it.** Name the hex codes explicitly. Palette names alone are unreliable below the top 5-10 famous ones.
+- **Tilesets need to tile cleanly.** Pixel-art tile-edge cleanliness from raw generation is poor. Generate the tile grid, then manually fix edge seams in Aseprite. The AI gets you 80% there.
+
+## Fallback (no MCP)
+
+Print the call:
+
+```
+summer_generate_image(
+  prompt="<pixel art prompt with full anchor>",
+  model="nano-banana-2",
+  style="pixel",
+  options={ image_size: "square_hd", negative_prompt: "blurry, smooth gradients, anti-aliasing" }
+)
+```
+
+Tell the user to run via the Summer dashboard, downscale in Aseprite/GIMP to true target resolution with nearest-neighbor, then `summer_import_from_url` (or drop into `res://sprites/`) and set `Filter: Nearest`.
+
+If MCP is offline entirely: open Aseprite or Piskel and hand-author the asset. For pixel art at small resolutions, hand-authoring is often faster than fixing a generation.
+
+## Handoff
+
+After the asset is wired:
+
+- **More assets in the same style** → re-invoke this skill, re-use the pixel anchor.
+- **Animation frames for the sprite** → `summer:2d-assets/sprite-sheet` with the base sprite as anchor.
+- **Pixel UI** → re-invoke with UI subjects (icons, button frames) at appropriate resolution.
+- **Tilemap setup** → `summer:scene-composition` for `TileMap` / `TileMapLayer` wiring.
+
+## See also
+
+- `summer:2d-assets/sprite-sheet` — animated pixel frames.
+- `summer:2d-assets/character-portrait` — high-res counterpart.
+- `summer:asset-pipeline/asset-strategy` — meta-router.
+- `_shared/mcp-tools-reference.md` — `summer_generate_image` schema.