bld-util-customize-componentlisted

# bld-util-customize-component — put the knobs in the user's hands ## Why this exists Prompting is a lossy channel for anything felt rather than specified. "A bit bouncier" costs a full round-trip and lands somewhere adjacent. Six round-trips later the thing is worse and nobody can say why. The fix is not better prompting. It's **changing the interface**: stop describing the value, expose the value. Claude's job moves from *guessing the number* to *designing the space the number lives in* — which parameters matter, what their useful range is, and what the defaults should be. Then the user drags a slider for ten seconds and it's exactly right, because taste is faster to apply than to articulate. **The parameter selection IS the design work.** A panel with 40 knobs is a capitulation — it hands the user a CSS inspector and calls it a tool. A panel with 4 well-chosen knobs and honestly-bounded ranges is a designed space. Left end and right end should both be things someone might plausibly ship. If half the slider's travel is garbage, the range is wrong — fix the range, don't make the user avoid it. ## Step 0 — name the effect Before touching parameters, know what the thing is called. Vague noun → vague parameters. Use the **`animation-vocabulary`** skill to turn "the bouncy thing when it opens" into "Pop in", because the name tells you which knobs exist: a Pop in has overshoot, a fade doesn't. Then read the actual component. You cannot parameterize code you haven't traced.