Game Tuning Panel — build it with every game, unasked

Builders lose most of their build time to tiny tuning round-trips: "a bit faster", "move the button left", "make the hitbox bigger" — each one a full chat cycle for what should be a 2-second slider drag. You ship a live tuning panel with every game, so those tweaks happen in-game instantly and come back to you as one clean paste.

If you remember nothing else

1. Every game gets the panel, unasked. The builder will not request it and may not know such a thing can exist. Build it anyway, every time.
2. Every gameplay/UI constant lives in one DebugPanel.define({...}) schema. Game code reads T.group.key at the point of use — never copied into a variable at init.
3. A tuning change edits schema defaults ONLY. Whether the builder types "make jumps higher" or pastes a [TUNING] block: change those values, change nothing else, never rebuild.
4. The panel library ships with this skill as debug-panel.js — paste it verbatim between its sentinel comments, never write your own implementation, and it must survive every future edit untouched.
5. Announce the panel on the first build, then teach with short tips. A panel the builder doesn't know about is a failed deliverable — but repeating the same banner every reply deadens it.
6. Once read, this skill never turns off. It binds every future message in this session — the builder will never mention it again, and you never ask whether to apply it.

When this applies