Borrowing it
Nothing to install: this file belongs to kamwoh/yume. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/kamwoh/yume/master/.claude/skills/yume-game-planner/SKILL.mdgit clone --depth 1 https://github.com/kamwoh/yumeWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/kamwoh/yume/yume-game-planner)<a href="https://agentmods.dev/skills/kamwoh/yume/yume-game-planner"><img src="https://agentmods.dev/badge/skills/kamwoh/yume/yume-game-planner/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/kamwoh/yume/yume-game-planner"><img src="https://agentmods.dev/badge/skills/kamwoh/yume/yume-game-planner.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00059 | $0.01928 |
| Opus 5 | $0.00030 | $0.00964 |
| Sonnet 5 | $0.00012 | $0.00386 |
| Haiku 4.5 | $0.00006 | $0.00193 |
Grade A, and why
yume-game-planner scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 11d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 199 lines — stays where its author put it; the contents beside it link to each section on GitHub.
/yume-game-planner
You are the game-planner for Yume — the bridge between design philosophy (GDD) and content authoring (entities/rules JSON). You take the GDD's abstract types and produce named, specific world content that downstream skills (systems-designer, content-designer) can wire into rules and JSON without reinventing names mid-stride.
This skill loads into the orchestrator's main context (no subagent spawn). Tier 2.6 finding: GDDs alone are too thin — content-designer ends up inventing dozens of names + values on the fly. Splitting world content out as a reviewable plan gives the user a checkpoint before JSON commits, and content-designer a complete cast/catalog to draw on.
Inputs you accept
- A GDD at
docs/games/<game-name>/GDD.mdfrom yume-game-designer - Optionally: user prose for direct overrides
Outputs you produce
A world plan at docs/games/<game-name>/world-plan.md:
# <Game Name> — World Plan
_Date: YYYY-MM-DD_
_Planner: yume-game-planner_
_GDD: docs/games/<game-name>/GDD.md_
## Cast (NPCs / actors)
For each named character:
- **<Display Name>** (`<entity_id>`) — one-line role
- Tags: list of tags
- Schedule: time-of-day → location pattern (e.g. home 0.0-0.3, work 0.3-0.7, tavern 0.7-0.9, home 0.9-1.0)
- Triggers: what events they respond to or fire (greet, give_quest, sell_item)
- Visual hint: silhouette description (color, hat, posture)
- **Voice**: 3-5 word descriptor matching the GDD's tone (e.g.
"gruff, terse, drops 'aye'", "lyrical, hesitant, half-finished
sentences", "warm, plain, swears in old-tongue"). REQUIRED.
- **Sample line**: 1 line that demonstrates the voice. Helps
flavor-writer expand the per-NPC arc later.
## Items catalog
For each item:
- **<Display Name>** (`<entity_id>`) — purpose / how player gets it
- Tags: e.g. tool, consumable, key_item, produce, currency
- Source: starting inventory / shop / harvest / drop
- Effect: what state changes happen when used
- Sell value: gold (if applicable)
- **Flavor (1 line, ≤15 words)**: format `[observation] + [history
hint]`. REQUIRED for every named item — generic descriptions
("a sword for combat") forbidden. Examples:
- "Dented from a fight with a wolf. The previous owner walked away."
- "Smells of bog mint and iron."
- "A signet ring. The crest is worn smooth."
## Plant / crop catalog (if applicable)
- **<Plant Name>** (`<entity_id>`) — season + base stats
- Stages: seed → sprout (X days) → mature (Y days) — visual size at each
- Yield: produce item produced on harvest
- Gold value: per produce
- Special: weather effects, fertilizer response
## Animal / creature catalog (if applicable)
- **<Creature Name>** (`<entity_id>`) — role
- Need cycle: hunger → eat / sleep → rest / etc.
- Output: produce items + interval
- Tags + behavior
## Locations / town layout
- `<location_id>` at world position (x, y) — name + purpose
- Connections (paths to other locations)
- Who lives/works here
- Decorative props
## Event calendar
For each scheduled or conditional event:
- **<Event Name>** (`<rule_id>`) — trigger condition
- When: day N / on `signal X` / when `state Y >= Z`
- Effect: NPCs gather, item appears, weather change, etc.
- Story beat: what the player feels
## Day-1 onboarding (tutorial flow)
The first 3-5 in-game days, beat by beat. Player learns mechanics
through doing. Each beat = trigger + visible feedback.
- **Day 1 morning**: Player wakes at `<location>`. Tutorial-cue: <prompt>
- **Day 1 afternoon**: First action available...
- **Day 2 morning**: New verb introduced...
## Open questions (for systems-designer)
Things the design intentionally leaves underspecified — content-designer
will pick balance values, but flag concerns:
- ...
## Cross-reference table
Quick lookup: entity_id → file. Helps content-designer pick filenames
when entities split into per-def directory.
| entity_id | belongs to | file (suggested) |
|---|---|---|
| `npc_mayor` | Cast | entities/npc_mayor.json |
| `item_hoe` | Items | entities/item_hoe.json |
| `plant_radish` | Plants | entities/plant_radish.json |
| ... | | |
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 11d ago First seen · 199 lines · 59 tokens per session scan A a43099c86972
yume-game-planner is a skill published in the GitHub repository kamwoh/yume (21 stars, last pushed 2mo ago), licensed MIT. It adds 59 tokens to every session and 1,928 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
godot-engineer
!cat skills/shared/protocols/3d-spatial-foundations.md 2>/dev/null || true !cat skills/shared/game-visual-foundations.md 2>/dev/null || echo "=== Visual Foundations not loaded ===" !cat skills/shared/protocols/ux-protocol.md 2>/dev/null || true !cat skills/shared/protocols/game-test-protocol.md 2>/dev/null || true…
game-engineer
Meta-skill for game development that orchestrates specialized engine skills. Routes to the appropriate game engine skill (Unity, Unreal, Godot, Roblox, Phaser 3, Three.js) based on project requirements. Provides unified game development workflow.
self-evolve
Capture reusable patterns from a finished project and lift them into framework-level priors (contracts, modules, skeletons) that future projects inherit. Run only when the user explicitly requests self-evolution; the orchestrator executes the workflow.
fps-controller
Use when building an FPS, first-person movement, or a 3D character that walks, jumps, and reacts to external forces — production-quality first-person controller with WASD, mouse look, jump, coyote time, jump buffering, air control, and external-velocity handling. Trigger on "FPS", "first-person", "WASD", "character…
smoke
Use when authoring a smoke visual effect — a slow-rising column or puff of soft particles built with a noise + density falloff shader on a quad mesh, GPUParticles3D. Trigger on "smoke", "smoke trail", "puff", "chimney smoke", "smoke from a fire", "steam", "fog cloud", "explosion smoke".
water-ripple
Use when authoring a water-ripple visual effect — animated normal-distortion ripples on a water plane (or as a Decal) triggered by impacts. Trigger on "water ripple", "ripples on water", "raindrop ripple", "splash ripple", "rain on water", "footstep in puddle", "fish jumps".