メニュー
Use when the user wants in-design controls for toggling variants, swapping colors, editing copy, or flipping feature flags directly inside a design artifact. Adds a Tweaks panel and host handshake.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | make-tweakable |
| description | Use when the user wants in-design controls for toggling variants, swapping colors, editing copy, or flipping feature flags directly inside a design artifact. Adds a Tweaks panel and host handshake. |
Loaded when the user wants in-design controls for toggling variants, swapping colors, editing copy, or flipping feature flags directly inside a design artifact.
A small number of high-impact values. Good candidates: one or two key colors, a layout variant toggle, a feature flag, a headline copy field. Do not over-expose. Every additional control raises the cost of the design and dilutes the point.
If the user does not specify what should be tweakable, pick 2–3 interesting things yourself and explain why in the summary.
A small floating panel anchored bottom-right. Title it exactly Tweaks so the naming matches any external toggle the host might expose. Hide the panel entirely when tweaks are deactivated — no residual chrome.
Keep the control surface tasteful. Use native inputs (<input type="color">, <select>, <input type="text">, <input type="range">) instead of hand-rolled form components unless the aesthetic absolutely requires them.
Order matters. Run these steps in this sequence:
activate and deactivate from the parent frame.If you post availability first, the host's activate message can land before your handler exists and the toggle silently does nothing.
When the user closes the panel from inside the design, post a message to the parent so any external toggle flips off in lockstep. The host and the in-design panel must agree on state at all times.
Persist tweak state somewhere the host can read back on reload. Pick one that fits the artifact:
localStorage keyed by artifact id (for long-lived previews).State the persistence choice in the summary.
Use after any OpenDesign build to serve ./opendesign/ over HTTP and give the user a clickable preview link. Handles duplicate server prevention and python/node runtime detection.
Use when ./opendesign/index.html does not exist in the current project. Initialises the OpenDesign output folder structure, copies the viewer, and writes an empty manifest.
Use when starting any design task — HTML pages, slide decks, interactive prototypes, UI kits, brand systems. Establishes the base designer role, workflow, and taste rules, and routes to specialist skills for the artifact type.
Use when the user asks to produce a reusable design system or UI kit from an existing brand, codebase, or product. Writes to ./opendesign/design-systems/<name>/ so opendesign can auto-discover it in future sessions.
Use when designing without an existing brand system. Pushes for a committed, distinctive aesthetic rather than generic defaults — extreme directions, bold typography, decisive color commitment.
Use when the user asks to hand a finished design off to a developer or a coding agent for implementation in a real codebase. Produces a self-sufficient handoff folder with a spec README, zipped for download.