Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
git clone --depth 1 https://github.com/HermeticOrmus/LibreGameDev-Claude-CodeWrote 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/commands/hermeticormus/libregamedev-claude-code/input-system)<a href="https://agentmods.dev/commands/hermeticormus/libregamedev-claude-code/input-system"><img src="https://agentmods.dev/badge/commands/hermeticormus/libregamedev-claude-code/input-system/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/commands/hermeticormus/libregamedev-claude-code/input-system"><img src="https://agentmods.dev/badge/commands/hermeticormus/libregamedev-claude-code/input-system.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.00013 | $0.00754 |
| Opus 5.5 | $0.00005 | $0.00302 |
| Sonnet 5.5 | $0.00003 | $0.00151 |
| Haiku 4.5 | $0.00001 | $0.00075 |
Grade A, and why
input-system 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 15d 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.
This is a copy
100% identical to input-system — 0 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.
How it starts
The opening of the file, as written. The whole thing — 103 lines — stays where its author put it; the contents beside it link to each section on GitHub.
/input-system
Input mapping, deadzone configuration, rebinding, input buffering, and multi-platform input support.
Trigger
/input-system [action] [target]
Actions
configure
Set up InputMap actions with keyboard and gamepad bindings.
/input-system configure "third-person action game: move, jump, attack, dodge, interact, camera"
/input-system configure "RTS: select, multi-select, move, attack-move, camera pan/zoom"
/input-system configure "menu navigation with keyboard and gamepad d-pad"
Output: InputMap action list, default keyboard and gamepad bindings, GDScript configuration code.
rebind
Implement input rebinding UI and serialization.
/input-system rebind "in-game keybinding menu with conflict detection"
/input-system rebind "save and load custom bindings to user:// directory"
/input-system rebind "reset to defaults button"
Output: InputRebinder GDScript, serialization format, conflict detection logic.
test
Input buffering and game feel improvements.
/input-system test "jump feels unresponsive on controller"
/input-system test "attack combo drops inputs at high animation speed"
/input-system test "movement feels floaty on gamepad analog stick"
Output: Root cause analysis, buffer/coyote implementation, deadzone correction.
polish
Platform-specific input polish: rumble, prompts, mobile touch.
/input-system polish "show correct button prompts for connected device (keyboard vs controller)"
/input-system polish "haptic rumble for player damage and attacks"
/input-system polish "mobile virtual joystick for movement"
Output: Device detection code, prompt switching system, rumble pattern library, or VirtualJoystick Control.
Examples
Implementing jump buffer + coyote time:
/input-system test "platformer jump feels inconsistent on gamepad"
Produces: PlatformerInput node with 8-frame jump buffer and 6-frame coyote time, consume_jump() interface for CharacterBody3D.
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.
- 15d ago First seen · 103 lines · 13 tokens per session scan A 86f3e384e7f7
input-system is a command published in the GitHub repository HermeticOrmus/LibreGameDev-Claude-Code (5 stars, last pushed 15d ago), licensed MIT. It adds 13 tokens to every session and 754 once invoked, about $0.0001 per session on Opus 5.5. A static security scan graded it A with 0 findings. It is 100% identical to input-system, differing in 0 lines, and is treated as a copy.
Other commands, from other repositories
build-and-compilation
These commands drive the build/compile/test dev loop, plus build configuration: triggering Player builds and reading the resulting BuildReport, switching the active build target, enumerating targets, reading/writing EditorUserBuildSettings, and listing Build Profiles. Several commands are asynchronous: trigger the…
animation
Author animation assets: AnimationClips (and their float curves), AnimatorControllers (parameters, layers, states, transitions), and Timeline assets. Create commands write under the authoring root and follow the shared confirm/dryrun convention.
assets-and-files
Commands for creating, importing, moving, copying, renaming, deleting and finding project assets, plus folder and text-file operations. Every agent-supplied path is funnelled through the authoring-root sandbox (it rejects ../ and out-of-project writes); destructive or overwriting operations require confirm=true and…
gameobjects-and-components
Commands for creating GameObjects, querying the scene hierarchy, mutating the core GameObject/Transform surface, and adding/removing components and editing their serialized properties. Scene mutations are wrapped in Unity's Undo system (so a multi-step action reverts as one collapsible step) and are blocked during…
project-settings
Read and change a representative slice of Unity's project-wide settings (Audio, Graphics, Input, Physics, Player, Quality, Tags & Layers, Time). get commands read a group's current values into a ProjectSettingsResponse; set commands mutate them through the shared confirm/dryrun convention, so confirm=true is required…
baking
Bake and clear precomputed scene data: lightmaps, NavMesh, and occlusion culling. Each bake runs asynchronously (returns immediately) — poll the matching bakestatus until completed. The clear commands are destructive and require confirm=true. The getsettings / setsettings pairs read and tune the bake parameters.