Skills: the Summer Board skills from PublicSummerEngine main

.claude-plugin/plugin.json

@@ -118,6 +118,7 @@
     "./library/skills/summer-apps/",
     "./library/skills/summer-apps-design/",
     "./library/skills/summer-assets/",
+    "./library/skills/summer-board/",
     "./library/skills/summer-cli/",
     "./library/skills/summer-friends/",
     "./library/skills/summer-leaderboards/",

.codex-plugin/plugin.json

@@ -108,6 +108,7 @@
     "./library/skills/summer-apps/",
     "./library/skills/summer-apps-design/",
     "./library/skills/summer-assets/",
+    "./library/skills/summer-board/",
     "./library/skills/summer-cli/",
     "./library/skills/summer-friends/",
     "./library/skills/summer-leaderboards/",

.cursor-plugin/plugin.json

@@ -121,6 +121,7 @@
     "./library/skills/summer-apps/",
     "./library/skills/summer-apps-design/",
     "./library/skills/summer-assets/",
+    "./library/skills/summer-board/",
     "./library/skills/summer-cli/",
     "./library/skills/summer-friends/",
     "./library/skills/summer-leaderboards/",

.factory-plugin/plugin.json

@@ -105,6 +105,7 @@
     "./library/skills/summer-apps/",
     "./library/skills/summer-apps-design/",
     "./library/skills/summer-assets/",
+    "./library/skills/summer-board/",
     "./library/skills/summer-cli/",
     "./library/skills/summer-friends/",
     "./library/skills/summer-leaderboards/",

CHANGELOG.md

@@ -19,6 +19,7 @@ Games go live on Summer's automatic checks, with Summer's review afterwards: `su
 - **Copy:** the README, `AGENTS.md`, the project `AGENTS.md` block and the `publish-your-game` skill say a game is live once the automatic checks pass, with staff review afterwards, and tell an automatic-check rejection from a staff hold and a take-down.
 - **Windows forms for the release checks.** The `release-readiness`, `multiplayer-publish` and `bounded-engine-runs` skills now give every check a PowerShell form next to the `sh` one: `Expand-Archive` in place of `unzip`, and a small `Run-Summer` helper that bounds a run with `Start-Process` and reads Summer.exe's `--log-file`, in place of `perl` and `grep`.
 - The operations catalog is synced from PublicSummerEngine main: the October 2026 models in `assets.generate_image`, `assets.generate_audio`, `assets.generate_sfx_choices` and `assets.generate_video` (among them `nano-banana-2.1`, `flux-3`, `ideogram-4.5`, `recraft-4.1`, `eleven_v4`, `music_v2_5`, `mirelo-sfx-2.0`, `kling-4` and `vidu-q4`), and 480p video. Also Mathias's frontier list (PublicSummerEngine #1418, #1436): the 3D models `hunyuan3d-v3`, `tripo-p1`, `pixal3d`, `trellis-multi`, `hunyuan3d-v2-multiview(-turbo)`, `rodin-2.5` and `tripo-h3.1`; HeyGen video and voices, Qwen3 TTS, Seed Audio 1.0, Gemini 3.1 Flash TTS, MiniMax Speech 2.8 Turbo, Lyria 2 and MiniMax Music; `assets.generate_video` takes `referenceImageUrls` and `videoUrl` for the reference, video-to-video, motion-transfer and add-sound models (`kling-4-ref`, `minimax-h3-max-reframe`, `kling-video-to-audio`, `thinksound`, ...); and `assets.generate_motion` takes `backend: "hunyuan-custom"` with `hunyuanModel` (Hunyuan Motion or Fast).
+- **The Summer Board skills ship in the library.** `summer-board` (join, wait, tasks, claims, file handoff, pings, the canvas, and section 7b: one frame per topic, a numbered grid of cards, a summary note with the next step at the top) installs with setup. `summer-board-types`, `summer-board-modeling` and `summer-board-to-game` are in the library (`summer_docs_read`), routed from `summer-board`. Synced from PublicSummerEngine main. To fit the installed-description budget, the `summer-store`, `concept-to-level` and `summer-cli` descriptions are shorter.
 
 ## [4.8.0] - 2026-10-24
 

evals/routing/baseline.json

@@ -1,21 +1,21 @@
 {
-  "generated_at": "2026-10-24",
+  "generated_at": "2026-10-25",
   "corpus_source": "registry/generated/index.json",
-  "corpus_size": 292,
-  "query_count": 152,
+  "corpus_size": 296,
+  "query_count": 154,
   "gap_count": 11,
   "mean_recall_at_5": 1,
-  "mean_recall_at_1": 0.8279,
-  "mrr_at_5": 0.9397,
+  "mean_recall_at_1": 0.8366,
+  "mrr_at_5": 0.9418,
   "per_kind": {
     "reference": {
       "expected": 1,
       "hit": 1,
       "recall_at_5": 1
     },
     "skill": {
-      "expected": 132,
-      "hit": 132,
+      "expected": 134,
+      "hit": 134,
       "recall_at_5": 1
     },
     "tool": {
@@ -24,7 +24,7 @@
       "recall_at_5": 1
     }
   },
-  "hijacked_queries": 16,
+  "hijacked_queries": 15,
   "per_query": {
     "make me a cozy 2D village game where I can walk into the houses": 1,
     "I want a top-down 2.5D RPG that looks hand painted": 1,
@@ -83,6 +83,8 @@
     "how much will 50 props cost with the summer api, then run them all as a batch": 1,
     "add a talking shopkeeper NPC players can chat with in my multiplayer game": 1,
     "my guard should answer what the player types and open the gate when convinced": 1,
+    "join my teammate's board and put 10 character concepts on it": 1,
+    "what is everyone working on, coordinate with Marcus's agent on the board": 1,
     "add a save and load system": 1,
     "add health and damage so my sword can hit enemies": 1,
     "add a multiplayer lobby": 1,

evals/routing/queries.yaml

@@ -149,6 +149,11 @@ queries:
     expected: [skill/summer-router]
   - query: "my guard should answer what the player types and open the gate when convinced"
     expected: [skill/summer-router]
+  # ── Summer Board ───────────────────────────────────────────────────────
+  - query: "join my teammate's board and put 10 character concepts on it"
+    expected: [skill/summer-board]
+  - query: "what is everyone working on, coordinate with Marcus's agent on the board"
+    expected: [skill/summer-board]
   # ── Gameplay systems ───────────────────────────────────────────────────
   - query: "add a save and load system"
     expected: [skill/save-load]

gemini-extension.json

@@ -110,6 +110,7 @@
     "./library/skills/summer-apps/",
     "./library/skills/summer-apps-design/",
     "./library/skills/summer-assets/",
+    "./library/skills/summer-board/",
     "./library/skills/summer-cli/",
     "./library/skills/summer-friends/",
     "./library/skills/summer-leaderboards/",

library/skills/README.md

@@ -1,6 +1,6 @@
 # Summer skills
 
-> 133 skills, grouped by their primary domain. **Generated** by `npm run generate:registry` from each skill's `resource.yaml`; `--check` fails when this file and the library disagree. Do not edit by hand.
+> 137 skills, grouped by their primary domain. **Generated** by `npm run generate:registry` from each skill's `resource.yaml`; `--check` fails when this file and the library disagree. Do not edit by hand.
 
 The folder is flat on purpose (`docs/design/DECISIONS.md`, D3): a skill usually belongs to several domains, so categories live in each skill's `facets.domains` and this index is rendered from them. The first domain listed is the primary one. `summer skills list --by-domain` prints the same grouping; `summer skills info <slug>` shows one skill.
 
@@ -10,7 +10,7 @@ Status: **stable** unless marked; *preview* = not yet exercised in-engine by the
 
 - [2d](#2d) (11)
 - [3d](#3d) (6)
-- [agent-workflow](#agent-workflow) (19)
+- [agent-workflow](#agent-workflow) (23)
 - [ai](#ai) (2)
 - [animation](#animation) (7)
 - [assets](#assets) (5)
@@ -79,7 +79,11 @@ Status: **stable** unless marked; *preview* = not yet exercised in-engine by the
 | [skill-create](./skill-create/SKILL.md) (library only) | Bootstrap a new Summer library skill (library/skills/<slug>/ with resource.yaml and SKILL.md), frontmatter, and stub sections. | meta |
 | [skill-improve](./skill-improve/SKILL.md) (library only) | Upgrade an underperforming Summer skill — run it against a behavioral spec with and without changes via a parallel-eval harness; ship the winner. | meta |
 | [skill-test](./skill-test/SKILL.md) (library only) | Lint a Summer skill before commit, audit the whole library, or check a behavioral spec assertion — static structural rules plus behavioral specs. | meta |
-| [*summer-cli*](./summer-cli/SKILL.md) ★ (preview) | Summer as shell commands, no MCP: sign in, find and run operations, follow jobs, save files, drive the engine. | assets, tools |
+| [*summer-board*](./summer-board/SKILL.md) (preview) | Summer Board co-op: tasks, claims, files, card frames. | game-design |
+| [*summer-board-modeling*](./summer-board-modeling/SKILL.md) (preview) (library only) | How granular to model a game on its Summer Board: what earns a type, what stays a note or a field, and starter type sets per genre. | game-design |
+| [*summer-board-to-game*](./summer-board-to-game/SKILL.md) (preview) (library only) | Bring a Summer Board's typed cards into the game as Godot Resources, load them through BoardData, and keep board and game in step. | game-design, gameplay |
+| [*summer-board-types*](./summer-board-types/SKILL.md) (preview) (library only) | Define and reuse types on a Summer Board (Character, Level, Item) so ideas become typed cards: read the board's types first, reuse before you define. | game-design |
+| [*summer-cli*](./summer-cli/SKILL.md) ★ (preview) | Summer as shell commands, no MCP: sign in, run operations, follow jobs, save files, drive the engine. | assets, tools |
 | [using-summer](./using-summer/SKILL.md) | Session bootstrap: how to find and use Summer skills and the summer-engine MCP before any response. | meta |
 | [verification-before-completion](./verification-before-completion/SKILL.md) ★ | Run verification and read its output before claiming work done, fixed or passing: evidence first. | verification |
 | [writing-plans](./writing-plans/SKILL.md) | Turn a spec or requirements for a multi-step task into a written implementation plan before touching code. | meta |
@@ -179,7 +183,7 @@ Status: **stable** unless marked; *preview* = not yet exercised in-engine by the
 
 | skill | when to use | also |
 |---|---|---|
-| [*concept-to-level*](./concept-to-level/SKILL.md) (preview) | Take a 3D map from concept art to a shippable level: questions for the user, owned lanes, render checks, collision kept in step. | 3d, world-building, agent-workflow |
+| [*concept-to-level*](./concept-to-level/SKILL.md) (preview) | 3D map from concept art to a shippable level: user questions, owned lanes, render checks, collision in step. | 3d, world-building, agent-workflow |
 | [design-level](./design-level/SKILL.md) ★ | Design one level (layout, pacing, encounters, secrets) as a design doc plus a node-tree skeleton. | game-design |
 | [scene-to-level](./scene-to-level/SKILL.md) | Turn a reference image or concept art into a playable scene: concept, asset pack, terrain, assembly. | game-design |
 
@@ -200,7 +204,7 @@ Status: **stable** unless marked; *preview* = not yet exercised in-engine by the
 | [*summer-matchmaking*](./summer-matchmaking/SKILL.md) (preview) | Get players into matches with Summer matchmaking: queues, teams, accept prompts, join progress and failures. | ux |
 | [*summer-parties*](./summer-parties/SKILL.md) (preview) | Let a Summer party play together: the leader presses Play, members follow into the same match. Hosted only. | ui |
 | [summer-player-data](./summer-player-data/SKILL.md) | Save a player's progress so it follows them to every match: authority load and commit, autosave, safe retries. | scripting |
-| [*summer-store*](./summer-store/SKILL.md) (preview) | Sell Summer items for Sparks: shop, checkout, item slugs, bundles and sales, owned items, summer.items.json sync, authority checks. | gameplay |
+| [*summer-store*](./summer-store/SKILL.md) (preview) | Sell Summer items for Sparks: shop, checkout, slugs, bundles, sales, owned items, summer.items.json sync. | gameplay |
 | [*summer-world-chat*](./summer-world-chat/SKILL.md) (preview) | Add match chat to a Summer game: one World channel shared by everyone in the match. Hosted only. | ui |
 | [*summer-world-saves*](./summer-world-saves/SKILL.md) (preview) | Keep a persistent Summer World between restarts: checkpoint saves, restore before join, the final save. | scripting |
 

library/skills/concept-to-level/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: concept-to-level
-description: "Take a 3D map from concept art to a shippable level: questions for the user, owned lanes, render checks, collision kept in step."
+description: "3D map from concept art to a shippable level: user questions, owned lanes, render checks, collision in step."
 license: MIT
 compatibility: [Cursor, Claude Code, Windsurf, Codex]
 category: level-design

library/skills/concept-to-level/resource.yaml

@@ -1,7 +1,7 @@
 id: skill/concept-to-level
 kind: skill
 version: 1.0.1
-summary: "Take a 3D map from concept art to a shippable level: questions for the user, owned lanes, render checks, collision kept in step."
+summary: "3D map from concept art to a shippable level: user questions, owned lanes, render checks, collision in step."
 use_when:
   - polishing a 3D map or arena from concept art to shipping quality, with real materials, props, sky and effects
   - reworking a level's theme and art while keeping its gameplay layout, with several agents working on one map

library/skills/summer-board-modeling/SKILL.md

@@ -0,0 +1,95 @@
+---
+name: summer-board-modeling
+description: "How granular to model a game on its Summer Board: what earns a type, what stays a note or a field, and starter type sets per genre."
+license: MIT
+compatibility: [Cursor, Claude Code, Codex, Windsurf, Gemini, OpenCode, Factory, Copilot]
+category: workflow
+user-invocable: true
+allowed-tools: summer_call summer_search
+---
+
+# How granular to model a game
+
+Types are for the things a game has many of and the code reads. Everything else is notes. A board with 6 good types is easy to read; one with 25 thin ones is a mess nobody keeps up to date. When unsure, model less: adding a type later is easy, merging two is work for a person.
+
+Defining them without duplicates: `summer-board-types`.
+
+## 1. Does it earn a type?
+
+A thing earns a type when all three are true:
+1. **There are 3 or more of it,** now or soon. One hook, one pitch, one world are notes.
+2. **They share 2 or more fields people compare.** "Which boss has the most hp?" means hp is a field and Boss things are cards.
+3. **The game will use the data,** or the art and sound work needs it. A list nobody builds from is a note list.
+
+Not a type: the hook, the pitch, the core loop, the mood, the timeline, open questions, playtest notes, references. They stay notes and pictures in frames.
+
+## 2. One type with a choice, or two types?
+
+Start with one type and a choice field. Split only when the kinds need 3 or more different fields.
+
+- Hero, NPC, enemy, boss: one **Character** with `role`. They all have a name, a look and hp.
+- Sword, potion, key: one **Item** with `kind`, until weapons need damage, range and rate and potions need none of them. Then **Weapon** splits off and Item keeps the rest.
+- Forest level, ice level: one **Level** with `biome`. Never a type per level.
+
+A type per instance (a `Dragon` type with one card) is always wrong: that is a card.
+
+## 3. Field or linked type?
+
+- A value: a field. `hp`, `biome`, `price`.
+- A list of plain words: an array of strings. `tags`, `palette`.
+- A thing with its own fields, used in more than one place: its own type, linked with `x-ref`. A boss's drops are Items; a level's boss is a Character.
+- Never nest: if you want an object inside an object, that inner thing is a type.
+
+## 4. Which fields earn a place
+
+Keep a field if it changes play, or someone builds from it:
+- **Play:** hp, damage, speed, cost, cooldown, unlock_level, spawn_rate, duration.
+- **Build:** look (one line for art), palette, size, sound (one line), the links to other cards.
+- **Track:** nothing. Status and owner come from the card's task; do not add `status`, `done` or `assigned_to` fields.
+
+Drop: backstory paragraphs, design rationale, notes to self. Put prose in a note next to the card.
+
+Numbers get units in the description ("metres per second"). Prefer an `enum` over free text when the game branches on it (`role`, `biome`, `rarity`).
+
+Keep types short: 4 to 10 fields. More than 12 usually means two types in one.
+
+## 5. How many types
+
+- **Starting a game:** 3 to 6. See `starter-sets.md` for the genre.
+- **A full game:** rarely more than 12. Over 15, look for types to merge (section 2) and propose it.
+- **A type with 1 or 2 cards** after a while is probably a note or a choice value in another type.
+
+## 6. Grow it when the need is real
+
+- A person keeps writing "hp 30" in notes: time for a field.
+- Three notes describe the same kind of thing: time for a type, and turn the notes into cards.
+- Agents keep asking "which X are left": X should be cards with tasks.
+
+Grow from what is on the board, not from what a game of this genre might have.
+
+## Examples
+
+Too fine:
+```
+Hero, Villain, Goblin, Orc, Shopkeeper, Sword, Axe, HealthPotion, ManaPotion, ForestLevel
+```
+Better:
+```
+Character (role: hero, villain, enemy, npc)   Item (kind: weapon, potion, key)   Level (biome)
+```
+
+Too coarse:
+```
+Thing (kind: character, level, item, sound)
+```
+Better: one type per kind of thing the code treats differently. A level and a sword never share fields.
+
+<!-- shell-commands: generated from the operation catalog by npm run generate:registry; do not edit by hand -->
+## From a shell
+
+No Summer MCP tools in this session? Run each one as a command; when `summer --version` is missing or below 4.0, use `npx -y summer-engine@latest` in place of `summer`. Fields are flags in kebab-case (`--scene-path res://main.tscn`) or one `--input '<json>'`, and `summer ops describe <op>` prints the exact input. The `summer-cli` skill has the rest.
+
+| In this skill | Command |
+|---|---|
+| `summer_search` | `summer ops search "<what you want>"` |
+<!-- /shell-commands -->

library/skills/summer-board-modeling/resource.yaml

@@ -0,0 +1,23 @@
+id: skill/summer-board-modeling
+kind: skill
+version: 1.0.0
+summary: "How granular to model a game on its Summer Board: what earns a type, what stays a note or a field, and starter type sets per genre."
+use_when:
+  - "before defining the first types on a Summer Board, or when a board's types feel too many or too few"
+  - "a person asks how to organise characters, levels or items on the board"
+facets:
+  lifecycle:
+    - build
+  domains:
+    - agent-workflow
+    - game-design
+  modalities:
+    - project
+related:
+  skills:
+    - skill/summer-board
+    - skill/summer-board-types
+source: official
+license: MIT
+status: preview
+bundled: false