← ClaudeAtlas

lablisted

Use when the user explicitly asks to lab or prototype a visual, UI, motion, or game-feel element with live tuning before production implementation.
ryanportfolio/STK · ★ 1 · AI & Automation · score 58
Install: claude install-skill ryanportfolio/STK
# lab — live-tune an element in an isolated sandbox, then port + delete LLMs guess at feel; the human eye knows it. A "lab" is a single throwaway HTML file with live controls that renders the element in isolation, so the **user** dials in the numbers instead of you guessing. Once they're happy, you port the exact values into the real code and throw the lab away. This bridges "looks right in my head" → deterministic, agreed-on values in the actual codebase. Works for **any** visual or feel element — game OR website. ## The contract (read first) A lab is **scratch tooling, never product**: 1. **Self-contained.** One HTML file. Inline vanilla JS + CSS. NO external imports, NO build step, NO framework, NO bundler. It must open and run as a plain file. 2. **Seeded at parity.** Every control starts at the element's CURRENT real value, so the lab opens looking exactly like the live thing. The user tunes *away* from the baseline — they can always see what changed. 3. **1:1 key mapping.** The "Copy Settings" JSON uses keys that match the real constant names, so porting is a paste-map, not a translation. 4. **Never committed.** Do not `git add` the lab file. It does not ship. 5. **Deleted when done.** After porting, delete the lab and verify it's gone. Forgotten labs accumulate into served-folder junk — don't start the pile. ## Workflow ### 1. Scope the knobs Read the real code for the element. List every tunable parameter and its **current value** — these become the lab's contr