Getting it into your agent
It runs from inside its repository, so the clone comes first — what it calls does not travel with the file alone.
git clone --depth 1 https://github.com/echoo19/hearthnpx agentmods add skills/echoo19/hearth/hearth-buildWrote 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/echoo19/hearth/hearth-build)<a href="https://agentmods.dev/skills/echoo19/hearth/hearth-build"><img src="https://agentmods.dev/badge/skills/echoo19/hearth/hearth-build.svg" alt="Measured on agentmods" 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.00075 | $0.03043 |
| Opus 5 | $0.00037 | $0.01522 |
| Sonnet 5 | $0.00015 | $0.00609 |
| Haiku 4.5 | $0.00007 | $0.00304 |
Grade A, and why
hearth-build 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 6d 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 — 234 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Structuring a Hearth game's world
This skill covers structure — what exists in the game world: scenes,
entities, components, tilemaps, prefabs, state machines, input bindings.
Behavior lives in the hearth-code skill, art/tile sourcing in hearth-art,
and the operating loop (inspect → validate → playtest) in the core hearth skill.
Scenes, entities, components
Create entities with their components inline; set properties by dot-path.
hearth create scene "Level 2"
hearth create entity "Level 1" Coin \
--position 620,300 --tags pickup \
--components '{"SpriteRenderer":{"shape":"circle","color":"#f1c40f","width":20,"height":20},"Collider":{"shape":"circle","radius":12,"isTrigger":true}}'
hearth set "Level 1" Coin Transform.position.x 200
hearth set-many "Level 1" Coin --properties '{"Transform.position.y":140,"SpriteRenderer.width":24}'
hearth add component "Level 1" Coin AudioSource --properties '{"assetId":"pickup"}'
hearth remove component "Level 1" Coin AudioSource
hearth duplicate entity "Level 1" Coin
hearth move entity "Level 1" Coin --position 300,140
hearth rename entity "Level 1" Coin Gem
set/set-many validate the full dot-path against the component's real schema
and suggest a fix on a typo. Collider polygons must be convex with ≥3 points —
split concave shapes across entities. All 23 component types:
docs/components.md.
Gameplay primitives: reach for these before writing a controller
Movement, hit points, respawning, checkpoints, and HUD labels are components, not scripts. Configure them, then use scripts for the feel on top. Each one has a real "don't use this" case — read it before adding the component.
# Input-driven movement. Needs a PhysicsBody to write velocity into.
hearth add component "Level 1" Player PhysicsBody --properties '{"bodyType":"dynamic"}'
hearth add component "Level 1" Player CharacterController --properties '{"mode":"platformer","speed":220,"jumpHeight":90,"coyoteFrames":6,"jumpBufferFrames":6,"maxFallSpeed":900}'
# Hit points. Emits damaged/healed/died; deathAction defaults to event-only.
hearth add component "Level 1" Player Health --properties '{"max":3,"invulnerableFrames":45}'
# Respawn point + a checkpoint that moves it. Checkpoint needs a TRIGGER collider.
hearth add component "Level 1" Player Respawn
hearth add component "Level 1" Flag Collider --properties '{"shape":"box","width":24,"height":48,"isTrigger":true}'
hearth add component "Level 1" Flag Checkpoint --properties '{"target":"tag:player","once":true}'
# A HUD label the engine keeps current, with no script writing it.
hearth set-settings --game-state '{"score":{"type":"number","initial":0}}'
hearth add component "Level 1" ScoreLabel Text --properties '{"binding":{"key":"score","format":"Score: {value}"}}'
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.
- 6d ago First seen · 234 lines · 75 tokens per session scan A 5667c05ce284
hearth-build is a skill published in the GitHub repository echoo19/hearth (62 stars, last pushed 1mo ago), licensed MIT. It adds 75 tokens to every session and 3,043 once invoked, about $0.0004 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
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.
artist-self-evolve
Distill stable art-generation patterns from a completed project, so future projects produce comparable assets without re-discovering the prompts. Lead-dispatched only — orchestrator invokes this skill from its self-evolve flow with a game-slug message; do not self-trigger.
vibegame-build
Run VibeGame's standard end-to-end game development workflow with reviewer gates. Use when the user wants to create a game from zero or evolve an existing game across multiple stages.
vibegame-start
Resume a VibeGame orchestrator session after vibegame start. Use at the beginning of a Claude or Codex session to inspect team runtime state, repair missing persistent members, load goal and GDD context, inspect tasks, and ask the user what to do next.
design-npc
Use when the user wants to design an enemy, NPC, boss, companion, civilian, or wave-spawned mob's behavior. Walks perception, personality knobs, intent layer, action state machine, telegraphs, defeat handling, and group emergence — outputs a state-machine GDScript stub plus the recommended node tree. Trigger on…
headless-scripting
Use when a Summer project needs an operation no MCP tool exposes, such as baking a navmesh, generating collision shapes, authoring an Animation, building a TileSet, re-importing assets after file changes, or preparing a supported local export. Runs a GDScript file against Summer Engine from the shell. Also use when a…