summer-engine 2.8.2 → 3.0.0

package/library/skills/world-building-3d/tests/spec.md

@@ -0,0 +1,48 @@
+# Skill Spec: /world-building-3d
+
+## Fixture
+
+- A 3D scene contains props, flat and sloped supports, a perspective camera,
+  colliders, and a synchronized navigation map.
+- All four Summer spatial tools and ordinary inspection/screenshot tools are
+  available.
+
+## Case 1: Ground mixed props
+
+**Input:** "Seat these crates on the floor, shelf, and ramp without collisions."
+
+**Expected MCP tool sequence (in order):**
+
+1. `summer_get_scene_tree`
+2. `summer_inspect_node` for subjects and supports
+3. `summer_test_placement` for uncertain candidate poses
+4. `summer_snap_to_surface` per subject
+5. `summer_test_placement` at each saved pose
+6. `summer_screenshot`
+
+**Assertions:**
+
+- [ ] Exact scene and node paths are used.
+- [ ] `fits: null` is not treated as proof of clearance.
+- [ ] Slope alignment requires physics evidence, resolved contact, the expected
+  support, plausible slope, saved-basis inspection, and an independent heading
+  or rendered check.
+- [ ] Ambiguous support choices are confirmed before mutation.
+
+## Case 2: Arrange a navigable encounter
+
+**Input:** "Evenly space these stalls and make sure each merchant is reachable
+from spawn."
+
+**Expected MCP tool sequence (in order):**
+
+1. `summer_align_distribute_3d`
+2. `summer_test_placement` for dense-spacing clearance
+3. `summer_navigation_probe` for each final merchant position
+4. `summer_screenshot` or `summer_play`
+
+**Assertions:**
+
+- [ ] Subject ordering and world axis are explicit.
+- [ ] Reachability requires `ready: true` and an acceptable snap distance.
+- [ ] Every mutation is followed by a saved-pose query or rendered check.

package/{skills/workflow → library/skills}/writing-plans/SKILL.md

@@ -15,7 +15,7 @@ Assume they are a skilled developer, but know almost nothing about our toolset o
 
 **Context:** If the work needs isolation from the current checkout, create a git worktree for it before execution starts.
 
-**Save plans to:** `docs/superpowers/plans/YYYY-MM-DD-<feature-name>.md`
+**Save plans to:** `.summer/plans/YYYY-MM-DD-<feature-name>.md` in the game project
 - (User preferences for plan location override this default)
 
 ## Scope Check
@@ -49,7 +49,7 @@ This structure informs the task decomposition. Each task should produce self-con
 ```markdown
 # [Feature Name] Implementation Plan
 
-> **For agentic workers:** implement this plan task-by-task, in order, checking off each step as it lands. Steps use checkbox (`- [ ]`) syntax for tracking. Dispatch a fresh subagent per task where the tasks are independent (see summer:dispatching-parallel-agents), otherwise execute inline with a review checkpoint after each task.
+> **For agentic workers:** implement this plan task-by-task, in order, checking off each step as it lands. Steps use checkbox (`- [ ]`) syntax for tracking. Dispatch a fresh subagent per task where the tasks are independent (see dispatching-parallel-agents), otherwise execute inline with a review checkpoint after each task.
 
 **Goal:** [One sentence describing what this builds]
 
@@ -72,27 +72,32 @@ This structure informs the task decomposition. Each task should produce self-con
 
 - [ ] **Step 1: Write the failing test**
 
-```python
-def test_specific_behavior():
-    result = function(input)
-    assert result == expected
+```gdscript
+# tests/unit/test_health.gd (GUT or gdUnit4 style)
+func test_damage_reduces_health():
+    var health := Health.new()
+    health.apply_damage(30)
+    assert_eq(health.current, 70)
 ```
 
 - [ ] **Step 2: Run test to verify it fails**
 
-Run: `pytest tests/path/test.py::test_name -v`
-Expected: FAIL with "function not defined"
+Run: the project's test command (for GUT: `<engine> --headless -s addons/gut/gut_cmdln.gd -gtest=res://tests/unit/test_health.gd`)
+Expected: FAIL because `apply_damage` does not exist yet
 
 - [ ] **Step 3: Write minimal implementation**
 
-```python
-def function(input):
-    return expected
+```gdscript
+# scripts/health.gd
+class_name Health
+var current := 100
+func apply_damage(amount: int) -> void:
+    current -= amount
 ```
 
 - [ ] **Step 4: Run test to verify it passes**
 
-Run: `pytest tests/path/test.py::test_name -v`
+Run: the same test command
 Expected: PASS
 
 - [ ] **Step 5: Commit**
@@ -135,7 +140,7 @@ If you find issues, fix them inline. No need to re-review — just fix and move
 
 After saving the plan, offer execution choice:
 
-**"Plan complete and saved to `docs/superpowers/plans/<filename>.md`. Two execution options:**
+**"Plan complete and saved to `.summer/plans/<filename>.md`. Two execution options:**
 
 **1. Subagent-Driven (recommended)** - I dispatch a fresh subagent per task, review between tasks, fast iteration
 
@@ -144,7 +149,7 @@ After saving the plan, offer execution choice:
 **Which approach?"**
 
 **If Subagent-Driven chosen:**
-- One fresh subagent per task, each given the task's full text and nothing else from this session's history. See `summer:dispatching-parallel-agents` for prompt structure and when parallelism is safe.
+- One fresh subagent per task, each given the task's full text and nothing else from this session's history. See `dispatching-parallel-agents` for prompt structure and when parallelism is safe.
 - Two-stage review: read the subagent's summary, then verify the diff yourself before starting the next task.
 
 **If Inline Execution chosen:**

package/library/skills/writing-plans/resource.yaml

@@ -0,0 +1,23 @@
+id: skill/writing-plans
+kind: skill
+version: 1.0.3
+summary: Turn a spec or requirements for a multi-step task into a written implementation plan before touching code.
+use_when:
+  - you have a spec or requirements for a multi-step task, before touching code
+  - a task spans several files or steps and needs an ordered, reviewable plan before implementation starts
+facets:
+  lifecycle:
+    - build
+  domains:
+    - agent-workflow
+    - meta
+  modalities:
+    - docs
+compatibility:
+  engine: ">=4.6"
+source: official
+license: MIT
+status: stable
+recommended: false
+aliases:
+  - skills/workflow/writing-plans

package/{skills/workflow → library/skills}/writing-skills/SKILL.md

@@ -17,7 +17,7 @@ You write test cases (pressure scenarios with subagents), watch them fail (basel
 
 **REQUIRED BACKGROUND:** This skill adapts the RED-GREEN-REFACTOR cycle to documentation. The cycle: write the test first and watch it FAIL for the reason you expect (red), make the smallest change that passes it (green), then clean up without changing behaviour (refactor). A test you never saw fail proves nothing.
 
-**Official guidance:** For Anthropic's official skill authoring best practices, see anthropic-best-practices.md. This document provides additional patterns and guidelines that complement the TDD-focused approach in this skill.
+**Official guidance:** For Anthropic's official skill authoring best practices, see https://platform.claude.com/docs/en/agents-and-tools/agent-skills/best-practices. That document provides additional patterns and guidelines that complement the TDD-focused approach in this skill.
 
 ## What is a Skill?
 
@@ -158,16 +158,16 @@ When the description was changed to just "Use when executing implementation plan
 **The trap:** Descriptions that summarize workflow create a shortcut Claude will take. The skill body becomes documentation Claude skips.
 
 ```yaml
-# ❌ BAD: Summarizes workflow - Claude may follow this instead of reading skill
+# BAD: Summarizes workflow - Claude may follow this instead of reading skill
 description: Use when executing plans - dispatches subagent per task with code review between tasks
 
-# ❌ BAD: Too much process detail
+# BAD: Too much process detail
 description: Use for TDD - write test first, watch it fail, write minimal code, refactor
 
-# ✅ GOOD: Just triggering conditions, no workflow summary
+# GOOD: Just triggering conditions, no workflow summary
 description: Use when executing implementation plans with independent tasks in the current session
 
-# ✅ GOOD: Triggering conditions only
+# GOOD: Triggering conditions only
 description: Use when implementing any feature or bugfix, before writing implementation code
 ```
 
@@ -180,20 +180,20 @@ description: Use when implementing any feature or bugfix, before writing impleme
 - **NEVER summarize the skill's process or workflow**
 
 ```yaml
-# ❌ BAD: Too abstract, vague, doesn't include when to use
+# BAD: Too abstract, vague, doesn't include when to use
 description: For async testing
 
-# ❌ BAD: First person
+# BAD: First person
 description: I can help you with async tests when they're flaky
 
-# ❌ BAD: Mentions technology but skill isn't specific to it
+# BAD: Mentions technology but skill isn't specific to it
 description: Use when tests use setTimeout/sleep and are flaky
 
-# ✅ GOOD: Starts with "Use when", describes problem, no workflow
+# GOOD: Starts with "Use when", describes problem, no workflow
 description: Use when tests have race conditions, timing dependencies, or pass/fail inconsistently
 
-# ✅ GOOD: Technology-specific skill with explicit trigger
-description: Use when using React Router and handling authentication redirects
+# GOOD: Technology-specific skill with explicit trigger
+description: Use when wiring a CharacterBody3D controller and handling slope or stair movement
 ```
 
 ### 2. Keyword Coverage
@@ -207,8 +207,8 @@ Use words Claude would search for:
 ### 3. Descriptive Naming
 
 **Use active voice, verb-first:**
-- ✅ `creating-skills` not `skill-creation`
-- ✅ `condition-based-waiting` not `async-test-helpers`
+- Good: `creating-skills` not `skill-creation`
+- Good: `condition-based-waiting` not `async-test-helpers`
 
 ### 4. Token Efficiency (Critical)
 
@@ -223,32 +223,32 @@ Use words Claude would search for:
 
 **Move details to tool help:**
 ```bash
-# ❌ BAD: Document all flags in SKILL.md
+# BAD: Document all flags in SKILL.md
 search-conversations supports --text, --both, --after DATE, --before DATE, --limit N
 
-# ✅ GOOD: Reference --help
+# GOOD: Reference --help
 search-conversations supports multiple modes and filters. Run --help for details.
 ```
 
 **Use cross-references:**
 ```markdown
-# ❌ BAD: Repeat workflow details
+# BAD: Repeat workflow details
 When searching, dispatch subagent with template...
 [20 lines of repeated instructions]
 
-# ✅ GOOD: Reference other skill
+# GOOD: Reference other skill
 Always use subagents (50-100x context savings). REQUIRED: Use [other-skill-name] for workflow.
 ```
 
 **Compress examples:**
 ```markdown
-# ❌ BAD: Verbose example (42 words)
-the user: "How did we handle authentication errors in React Router before?"
-You: I'll search past conversations for React Router authentication patterns.
-[Dispatch subagent with search query: "React Router authentication error handling 401"]
+# BAD: Verbose example (42 words)
+the user: "How did we handle the camera clipping through walls in the last project?"
+You: I'll search past conversations for camera collision patterns.
+[Dispatch subagent with search query: "SpringArm3D camera collision clipping"]
 
-# ✅ GOOD: Minimal example (20 words)
-Partner: "How did we handle auth errors in React Router?"
+# GOOD: Minimal example (20 words)
+Partner: "How did we stop the camera clipping through walls?"
 You: Searching...
 [Dispatch subagent → synthesis]
 ```
@@ -266,10 +266,10 @@ wc -w skills/path/SKILL.md
 ```
 
 **Name by what you DO or core insight:**
-- ✅ `condition-based-waiting` > `async-test-helpers`
-- ✅ `using-skills` not `skill-usage`
-- ✅ `flatten-with-flags` > `data-structure-refactoring`
-- ✅ `root-cause-tracing` > `debugging-techniques`
+- Good: `condition-based-waiting` > `async-test-helpers`
+- Good: `using-skills` not `skill-usage`
+- Good: `flatten-with-flags` > `data-structure-refactoring`
+- Good: `root-cause-tracing` > `debugging-techniques`
 
 **Gerunds (-ing) work well for processes:**
 - `creating-skills`, `testing-skills`, `debugging-with-logs`
@@ -280,12 +280,12 @@ wc -w skills/path/SKILL.md
 **When writing documentation that references other skills:**
 
 Use skill name only, with explicit requirement markers:
-- ✅ Good: `**REQUIRED SUB-SKILL:** Use summer:verification-before-completion`
-- ✅ Good: `**REQUIRED BACKGROUND:** You MUST understand summer:investigating-bugs`
-- ❌ Bad: `See skills/debugging/debug` (unclear if required)
-- ❌ Bad: `@skills/debugging/debug/SKILL.md` (force-loads, burns context)
+- Good: `**REQUIRED SUB-SKILL:** Use verification-before-completion`
+- Good: `**REQUIRED BACKGROUND:** You MUST understand investigating-bugs`
+- Bad: `See library/skills/debug` (unclear if required)
+- Bad: `@library/skills/debug/SKILL.md` (force-loads, burns context)
 
-**Check the skill exists before you point at it.** The registry of shipped skills is the `SKILL_REGISTRY` array in `src/lib/skills-registry.ts` and the `skills:` array in `.claude-plugin/plugin.json`. A `REQUIRED SUB-SKILL` pointing at a skill that was never shipped is worse than no cross-reference: the reader stops and looks for something that does not exist.
+**Check the skill exists before you point at it.** The registry of shipped skills is `registry/generated/skills-registry.json` (generated from `library/skills/`); `summer skills list` prints it. A `REQUIRED SUB-SKILL` pointing at a skill that was never shipped is worse than no cross-reference: the reader stops and looks for something that does not exist.
 
 **Why no @ links:** `@` syntax force-loads files immediately, consuming 200k+ context before you need them.
 
@@ -315,13 +315,7 @@ digraph when_flowchart {
 - Linear instructions → Numbered lists
 - Labels without semantic meaning (step1, helper2)
 
-See @graphviz-conventions.dot for graphviz style rules.
-
-**Visualizing for the user:** Use `render-graphs.js` in this directory to render a skill's flowcharts to SVG:
-```bash
-./render-graphs.js ../some-skill           # Each diagram separately
-./render-graphs.js ../some-skill --combine # All diagrams in one SVG
-```
+Keep graphviz blocks small: one decision per diamond, verbs on edges, no more than a dozen nodes.
 
 ## Code Examples
 
@@ -462,7 +456,7 @@ Different skill types need different test approaches:
 
 Skills that enforce discipline (like TDD) need to resist rationalization. Agents are smart and will find loopholes when under pressure.
 
-**Psychology note:** Understanding WHY persuasion techniques work helps you apply them systematically. See persuasion-principles.md for research foundation (Cialdini, 2021; Meincke et al., 2025) on authority, commitment, scarcity, social proof, and unity principles.
+**Why this works:** explicit authority ("MUST", "NEVER"), commitment (announce the skill before acting), and closing each loophole by name are what make a discipline skill hold under pressure; vague encouragement does not.
 
 ### Close Every Loophole Explicitly
 
@@ -563,22 +557,22 @@ Agent found new rationalization? Add explicit counter. Re-test until bulletproof
 
 ## Anti-Patterns
 
-### ❌ Narrative Example
+### Bad: Narrative Example
 "In session 2025-10-03, we found empty projectDir caused..."
 **Why bad:** Too specific, not reusable
 
-### ❌ Multi-Language Dilution
+### Bad: Multi-Language Dilution
 example-js.js, example-py.py, example-go.go
 **Why bad:** Mediocre quality, maintenance burden
 
-### ❌ Code in Flowcharts
+### Bad: Code in Flowcharts
 ```dot
 step1 [label="import fs"];
 step2 [label="read file"];
 ```
 **Why bad:** Can't copy-paste, hard to read
 
-### ❌ Generic Labels
+### Bad: Generic Labels
 helper1, helper2, step3, pattern4
 **Why bad:** Labels should have semantic meaning
 

package/library/skills/writing-skills/resource.yaml

@@ -0,0 +1,29 @@
+id: skill/writing-skills
+kind: skill
+version: 1.0.3
+summary: Create, edit, and verify agent skills — format, structure, testing with subagents, and best practices.
+use_when:
+  - creating new skills, editing existing skills, or verifying skills work before deployment
+  - reviewing a SKILL.md for format, structure, and trigger quality, or testing whether it fires with a subagent
+facets:
+  lifecycle:
+    - build
+  domains:
+    - agent-workflow
+    - meta
+  modalities:
+    - docs
+compatibility:
+  engine: ">=4.6"
+related:
+  skills:
+    - skill/debug
+source: official
+license: MIT
+status: stable
+recommended: false
+aliases:
+  - skills/workflow/writing-skills
+lint_exceptions:
+  - url-allowlist
+lint_exception_reason: Links to platform.claude.com — Anthropic's canonical, read-only skill-authoring best-practices documentation, replacing a previously vendored copy of the same doc.

package/{skills/workflow → library/skills}/writing-skills/testing-skills-with-subagents.md

@@ -12,7 +12,6 @@ You run scenarios without the skill (RED - watch agent fail), write skill addres
 
 **REQUIRED BACKGROUND:** the RED-GREEN-REFACTOR cycle as stated just above. This reference supplies the skill-specific test formats on top of it (pressure scenarios, rationalization tables).
 
-**Complete worked example:** See examples/CLAUDE_MD_TESTING.md for a full test campaign testing CLAUDE.md documentation variants.
 
 ## When to Use
 
@@ -139,7 +138,7 @@ Forces explicit choice.
 
 **Best tests combine 3+ pressures.**
 
-**Why this works:** See persuasion-principles.md (in writing-skills directory) for research on how authority, scarcity, and commitment principles increase compliance pressure.
+**Why this works:** authority, scarcity and commitment pressures stack; a scenario that combines them exposes whether the skill holds or the agent rationalizes.
 
 ### Key Elements of Good Scenarios
 
@@ -331,29 +330,29 @@ Before deploying skill, verify you followed RED-GREEN-REFACTOR:
 
 ## Common Mistakes (Same as TDD)
 
-**❌ Writing skill before testing (skipping RED)**
+**Bad: Writing skill before testing (skipping RED)**
 Reveals what YOU think needs preventing, not what ACTUALLY needs preventing.
-✅ Fix: Always run baseline scenarios first.
+Fix: Always run baseline scenarios first.
 
-**❌ Not watching test fail properly**
+**Not watching test fail properly**
 Running only academic tests, not real pressure scenarios.
-✅ Fix: Use pressure scenarios that make agent WANT to violate.
+Fix: Use pressure scenarios that make agent WANT to violate.
 
-**❌ Weak test cases (single pressure)**
+**Bad: Weak test cases (single pressure)**
 Agents resist single pressure, break under multiple.
-✅ Fix: Combine 3+ pressures (time + sunk cost + exhaustion).
+Fix: Combine 3+ pressures (time + sunk cost + exhaustion).
 
-**❌ Not capturing exact failures**
+**Not capturing exact failures**
 "Agent was wrong" doesn't tell you what to prevent.
-✅ Fix: Document exact rationalizations verbatim.
+Fix: Document exact rationalizations verbatim.
 
-**❌ Vague fixes (adding generic counters)**
+**Vague fixes (adding generic counters)**
 "Don't cheat" doesn't work. "Don't keep as reference" does.
-✅ Fix: Add explicit negations for each specific rationalization.
+Fix: Add explicit negations for each specific rationalization.
 
-**❌ Stopping after first pass**
+**Bad: Stopping after first pass**
 Tests pass once ≠ bulletproof.
-✅ Fix: Continue REFACTOR cycle until no new rationalizations.
+Fix: Continue REFACTOR cycle until no new rationalizations.
 
 ## Quick Reference (TDD Cycle)
 

package/library/templates/2d-brario-platformer/resource.yaml

@@ -0,0 +1,21 @@
+id: template/2d-brario-platformer
+kind: template
+version: 1.1.3
+summary: Classic side-scrolling 2D platformer starter (Platform Quest) — stomp combat, hazards, a boss, and levels authored as ASCII text files.
+use_when:
+  - starting a classic run-and-jump platformer with enemies and pickups
+facets:
+  lifecycle: [build]
+  domains: [2d, platformer]
+compatibility:
+  engine: ">=4.6"
+source: official
+license: MIT
+status: stable
+aliases:
+  - template-2d-brario-platformer
+repo: https://github.com/SummerEngine/template-2d-brario-platformer
+commit: cf7426cdd48f243e501396530ccaf8549c4951ad
+tree_digest: 32307330f7ac96eb979c9ba47d714eddfdfbcd2a15babe52b2adb0d82a919e4b
+default_branch: main
+systems: [character-controller, enemies, levels]

package/library/templates/2d-dungeon-roguelike/resource.yaml

@@ -0,0 +1,23 @@
+id: template/2d-dungeon-roguelike
+kind: template
+version: 1.0.1
+summary: Room-based dungeon-crawl roguelike starter — ASCII room tables, melee combat, procedural floors.
+use_when:
+  - starting a room-based dungeon crawler with procedural floors
+facets:
+  lifecycle: [build]
+  domains: [2d, roguelike, dungeon-crawler]
+compatibility:
+  engine: ">=4.6"
+source: official
+license: MIT
+status: preview
+do_not_use_when:
+  - the repository is private; not installable from the public CLI until it is published
+aliases:
+  - template-2d-dungeon-roguelike
+repo: https://github.com/SummerEngine/template-2d-dungeon-roguelike
+commit: 6d88c704c4ed77c4c67bc16f8ec887133418ee7a
+tree_digest: ce0bcea0cb4b7196a7a248b1522cd5b8d724cddd8a9cb2296228af2e9557f14a
+default_branch: master
+systems: [procedural-floors, melee-combat, rooms]

package/library/templates/2d-grid-puzzle/resource.yaml

@@ -0,0 +1,21 @@
+id: template/2d-grid-puzzle
+kind: template
+version: 1.0.4
+summary: "Grid-based top-down puzzle starter (GridKit), a 3D scene of unshaded textured quads: ASCII-map levels, crates, plates, keys, doors, a chasing enemy."
+use_when:
+  - starting a match/slide/sokoban-style grid puzzle game
+facets:
+  lifecycle: [build]
+  domains: [3d, puzzle]
+compatibility:
+  engine: ">=4.6"
+source: official
+license: MIT
+status: stable
+aliases:
+  - template-2d-grid-puzzle
+repo: https://github.com/SummerEngine/template-2d-grid-puzzle
+commit: f8433fddeb63f2e62db05fd84cf0516cea49431d
+tree_digest: 2871da30fcadd242ddf98713571fce602379688856cce296bc232fadefc1a261
+default_branch: main
+systems: [grid-logic, input]

package/library/templates/2d-plants-and-zombies-tower-defense/resource.yaml

@@ -0,0 +1,21 @@
+id: template/2d-plants-and-zombies-tower-defense
+kind: template
+version: 1.0.5
+summary: Lane tower-defense starter in the Plants vs. Zombies style — placeable defenders, waves of lane attackers.
+use_when:
+  - starting a lane-based tower defense game
+facets:
+  lifecycle: [build]
+  domains: [2d, tower-defense]
+compatibility:
+  engine: ">=4.6"
+source: official
+license: MIT
+status: stable
+aliases:
+  - template-2d-plants-and-zombies-tower-defense
+repo: https://github.com/SummerEngine/template-2d-plants-and-zombies-tower-defense
+commit: 83e79fa573986973aef590cebed290f097de339e
+tree_digest: 5fbe178381095805e31935ba1cc1cba36203fae81def064d58bd9861aee8684b
+default_branch: main
+systems: [lanes, spawning, placement, waves]

package/library/templates/2d-platformer/resource.yaml

@@ -0,0 +1,24 @@
+id: template/2d-platformer
+kind: template
+version: 1.0.2
+summary: Hollow Knight-style 2D Metroidvania starter with CharacterBody2D combat platforming across 7 door-linked rooms, ability pickups, NPCs, quests and a boss.
+use_when:
+  - starting a 2D side-scrolling Metroidvania or action platformer with interconnected rooms
+  - needing a working room-transition, ability-pickup, NPC-dialogue, quest and JSON-save baseline
+do_not_use_when:
+  - you want a minimal run-and-jump platformer with a few linear levels; this ships 9 autoloads, 7 rooms, quests, saves and a boss (see 2d-brario-platformer)
+facets:
+  lifecycle: [build]
+  domains: [2d, platformer, character-controller, npc]
+compatibility:
+  engine: ">=4.6"
+source: official
+license: MIT
+status: stable
+aliases:
+  - template-2d-platformer
+repo: https://github.com/SummerEngine/template-2d-platformer
+commit: ad9d630499c9ec79bff73eec41d24d108b4ce2be
+tree_digest: 23814259bb7ae9ee260d5cf66b4cc903369219888bd511ce3f21a5a5864c1fac
+default_branch: main
+systems: [room-transitions, character-controller, melee-combat, ability-pickups, npc-dialogue, quests, boss-fight, save-system, parallax]

package/library/templates/2d-rpg/resource.yaml

@@ -0,0 +1,21 @@
+id: template/2d-rpg
+kind: template
+version: 1.0.3
+summary: 2D top-down RPG starter built on GDQuest's open-source work — movement, interactions, and world structure.
+use_when:
+  - starting a top-down 2D RPG or adventure game
+facets:
+  lifecycle: [build]
+  domains: [2d, rpg]
+compatibility:
+  engine: ">=4.6"
+source: official
+license: MIT
+status: stable
+aliases:
+  - template-2d-rpg
+repo: https://github.com/SummerEngine/template-2d-rpg
+commit: 7253cf527fc260824c1b10854f7e68e36995396c
+tree_digest: eb0acd5aa30aceebe8de2f7f0cb14a72877b8f47e5cc6993d5f0a208ae8f1493
+default_branch: main
+systems: [top-down-movement, interactions, world]

package/library/templates/2d-vampire-survivor-roguelike/resource.yaml

@@ -0,0 +1,21 @@
+id: template/2d-vampire-survivor-roguelike
+kind: template
+version: 1.0.5
+summary: Survivors-like roguelike starter — auto-attacking hero, swarming enemies, run-based upgrades.
+use_when:
+  - starting a Vampire Survivors-style horde roguelike
+facets:
+  lifecycle: [build]
+  domains: [2d, roguelike, survivors-like]
+compatibility:
+  engine: ">=4.6"
+source: official
+license: MIT
+status: stable
+aliases:
+  - template-2d-vampire-survivor-roguelike
+repo: https://github.com/SummerEngine/template-2d-vampire-survivor-roguelike
+commit: 53197b89710d2212a3b9e117e59cfe897db1e2af
+tree_digest: 8e205a0259ddfd5d53c83221f305dbd219c03c9b3215f16ef34769ec3b1cd324
+default_branch: main
+systems: [auto-attack, enemy-swarms, upgrades]

package/library/templates/3d-basic/resource.yaml

@@ -0,0 +1,16 @@
+id: template/3d-basic
+kind: template
+version: 1.1.0
+summary: "Built-in: 3D scene with camera, light, and floor — generated locally by summer create, no download."
+use_when:
+  - starting a minimal 3D scene with camera, light, and floor already wired
+facets:
+  lifecycle: [build]
+  domains: [3d, builtin]
+compatibility:
+  engine: ">=4.6"
+source: official
+license: MIT
+status: stable
+builtin: true
+systems: [project-scaffold, basic-scene]

package/library/templates/3d-city-kit/resource.yaml

@@ -0,0 +1,24 @@
+id: template/3d-city-kit
+kind: template
+version: 1.0.2
+summary: Construction starter for importing and navigating large 3D city kits in Summer Engine.
+use_when:
+  - building a game on a large imported 3D city kit
+facets:
+  lifecycle: [ build ]
+  domains:
+    - 3d
+    - world-building
+    - asset-import
+compatibility:
+  engine: ">=4.6"
+source: official
+license: MIT
+status: stable
+aliases:
+  - template-3d-city-kit
+repo: https://github.com/SummerEngine/template-3d-city-kit
+commit: 2635fc8372435940e6b7415934fe0c2896c8c967
+tree_digest: 24f7f044e86a8d5505898584125c3046fa15e665f5b60965d4776152b6f0cc2c
+default_branch: codex/importable-template
+systems: [ kit-import, navigation, world ]

package/library/templates/3d-fps-old-school/resource.yaml

@@ -0,0 +1,21 @@
+id: template/3d-fps-old-school
+kind: template
+version: 1.0.2
+summary: Retro first-person shooter starter in the old-school boomer-shooter style.
+use_when:
+  - starting a retro/old-school FPS
+facets:
+  lifecycle: [build]
+  domains: [3d, fps]
+compatibility:
+  engine: ">=4.6"
+source: official
+license: MIT
+status: stable
+aliases:
+  - template-3d-fps-old-school
+repo: https://github.com/SummerEngine/template-3d-fps-old-school
+commit: 5a1ef4b86a900f72607cfa755fb38afc3163bcc6
+tree_digest: ff370b858c0a0c6ee7305d422f240ca9cec9f7e8a34218b0f23a1c38be9abab7
+default_branch: bror-templates
+systems: [fps-controller, weapons, enemies]