Help us improve
Share bugs, ideas, or general feedback.
From summer
Captures game-development session learnings into a durable skill library so future sessions start smarter. Invoke at session end to turn ad-hoc fixes into reusable expertise.
npx claudepluginhub summerengine/summer-engine-agent --plugin summerHow this skill is triggered — by the user, by Claude, or both
Slash command
/summer:gameskillThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
You're being invoked at the end (or middle) of a game-development session. Your job is to turn what you just figured out into a durable skill update so future agents and Summer users get to start where you ended.
Sets up the Summer Engine skill ecosystem: how to load skills and use MCP tools. Must be loaded at conversation start in any Summer Engine project.
Guide for creating effective skills. This skill should be used when users want to create a new skill (or update an existing skill) that extends OpenCode's capabilities with specialized knowledge, workflows, or tool integrations.
Extracts reusable skills from work sessions for non-obvious problems, patterns, workarounds, or debugging techniques. Manual invocation via /skill-extractor.
Share bugs, ideas, or general feedback.
You're being invoked at the end (or middle) of a game-development session. Your job is to turn what you just figured out into a durable skill update so future agents and Summer users get to start where you ended.
This is the meta-skill: the loop that turns ad-hoc fixes into reusable expertise.
Three repos, one ecosystem:
editor/, core/, and the Summer-specific module at modules/1summer_engine/. CLI source: tools/summer-cli/. The CLI ships as npm i -g summer-engine. It does install/login/create/run for the engine, plus summer skills install --agent claude-code which writes a curated subset of skills into ~/.claude/skills/ for any agent to auto-discover.src/lib/ai/skills/bundled/ and public/knowledge/summer/skills/ for the in-browser chat agent. Also has its own consumers of the engine API in src/lib/bridge/direct-executor.ts and src/lib/ai/tools/run-and-verify.ts which call the same engine endpoints the CLI does.~/development/<game-name> (Godot 4.6) or whatever game you were just working on. Real working code in this repo is the gold standard for examples.The skill system is the value flywheel. Every game shipped teaches lessons. Lessons become skills. Next user starts smarter. Your job here is to close that loop for what you just did.
When the lesson is "the engine should expose more / behave differently," the change usually crosses repo boundaries. Map the layers before you edit:
[active game] -> calls MCP / web app
v
[summer-cli MCP server (TypeScript)] -> calls /api/ops + /api/state/* on the engine
v
[Summer Engine binary (C++ in SummerEngine repo)] - source of truth for what the API returns
[PublicSummerEngine web app (TypeScript)] -> also calls the same engine endpoints via direct-executor or Redis bridge
Implications:
SummerEngine/modules/1summer_engine/ or SummerEngine/editor/ reaches everyone (CLI MCP, web app, future tools). Most powerful, also highest blast radius.tools/summer-cli/src/mcp/ only changes what the CLI exposes. The web app has its own TypeScript layer at PublicSummerEngine/src/lib/bridge/. Same engine endpoints, different glue. Don't assume your CLI tool change is web-app-aware.tools/summer-cli/skills/ affects every agent that runs summer skills install. The web app's skill store is separate (PublicSummerEngine/src/lib/ai/skills/bundled/) and currently uses a different format (template wizards, not Markdown discipline guides). Don't try to mirror skills there blindly.When you change an engine endpoint's response shape:
tools/summer-cli/src/ and PublicSummerEngine/src/lib/ for consumers of that endpoint.tools/summer-cli/TOOLING-TODO.md what's now possible that wasn't before.Engine binary changes ship via a rebuild + new release. CLI/web TypeScript changes ship via npm publish or web deploy. State this delivery cost in your report so the user knows what they get today vs after a release.
~/development/SummerEngine/tools/summer-cli/skills/. Single source of truth. Domains: ui-and-ux, gameplay-mechanics, character-controllers, scripting-patterns, visual-effects, debugging, rendering-and-lighting, scene-and-project, level-design, audio, ai-and-npcs, asset-pipeline, performance, deployment, multiplayer-and-networking, plus workflow for process skills. The skills: array in .claude-plugin/plugin.json is the registry. Sibling references live at top-level references/ and tests/.~/.claude/skills/. Where summer skills install --agent claude-code writes copies. Auto-discovered by Claude Code in any session.PublicSummerEngine/src/lib/ai/skills/bundled/ (template wizards, different format) and PublicSummerEngine/public/knowledge/summer/skills/ (JSON knowledge files). Mirror only when the lesson genuinely fits their format. Most discipline-guide skills don't.One short sentence to the user. "Capturing learnings from this session into the skill library." That's it. No plan dump.
Probe the stores. Glob each path above. Note what exists and what's empty. Print a tight summary.
Recap the session. Look back over the conversation. Pull out learnings that are non-obvious AND general — things a future agent or user would benefit from but couldn't derive from reading the codebase. Examples that count:
visual-effectsscripting-patternsui-and-uxdebuggingscripting-patternsai-and-npcs or gameplay-mechanicsperformanceasset-pipelinetools/summer-cli/TOOLING-TODO.md AND the relevant skillExamples that DON'T count: one-off code with no general lesson, things already documented in CLAUDE.md or an existing skill, personal preferences without reasoning, anything you have to manufacture to fill space.
Decide placement. For each learning:
One tight pause for the user. Five-to-ten lines max: what files you'll touch, what each one captures, what gets left out. Wait for OK or redirect. Don't ask multiple questions.
Apply.
.md files under tools/summer-cli/skills/<domain>/..claude-plugin/plugin.json (and sibling .codex-plugin/, .cursor-plugin/ manifests) AND in src/lib/skills-registry.ts SKILL_REGISTRY array. Both are required — plugin-manifests.test.ts fails the build if either is missing.~/.claude/skills/<name>/ so it's live in the current session. Tell the user to consider adding it to the CLI's default install set.PublicSummerEngine skill stores too.git status in the SummerEngine repo (and PublicSummerEngine if touched) so the diff is visible.Report. One short message. Files changed, the future-agent payoff in one sentence per skill, and what (if anything) is still uncaptured.
.md skill content.[SUMMER] markers on core Godot engine file edits in C++ changes. Skill .md files don't need them.It's totally fine to come back with "session was tactical, no durable learnings worth a skill update." Don't manufacture skills from thin air. Better to ship nothing than ship noise.