Help us improve
Share bugs, ideas, or general feedback.
From mockup-gallery
Use to create scratch-first HTML mockups, optionally use image generation for visual assets, launch/review mockups, check selections, align mockups to routes/screens, or implement approved designs from the mockup gallery.
npx claudepluginhub tyroneross/mockup-gallery --plugin mockup-galleryHow this skill is triggered — by the user, by Claude, or both
Slash command
/mockup-gallery:mockup-reviewThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Use this skill when the user wants Codex to create, review, select, revise, or implement mockups tracked by mockup-gallery.
Applies 10 pre-set color/font themes or generates custom ones for slides, documents, reports, and HTML landing pages.
Share bugs, ideas, or general feedback.
Use this skill when the user wants Codex to create, review, select, revise, or implement mockups tracked by mockup-gallery.
COMMON.md and AGENTS.md for shared mockup format and implementation rules.mockup-gallery/ JSON state for selections, ratings, saved items, archive state, and workflow preferencesDESIGN.md at the project root for the design-system (visual identity: colors, typography, spacing, elevation, shape) in Google's DESIGN.md format. When present, treat its YAML tokens as canonical and align new mockups to them. Scaffold a starter via POST /design-system/scaffold if absent.mockups/, docs/mockups/, or .claude/mockups/ for HTML mockup filesgallery/gallery.html and server/gallery-server.mjs for the local review surfacecommands/*.md remain Claude-oriented companion assets; in Codex, prefer this skill directlyThe gallery exposes a Lo-fi first toggle in the sidebar that controls whether new review batches default to a low-fidelity wireframe step before any hi-fi HTML variants. The preference is persisted at .mockup-gallery/state.json#preferences.wireframeFirst and defaults to true on a fresh project. Read it before creating new mockups:
wireframeFirst is true (default), begin every new review batch with a low-fidelity black-and-white scratch mockup. Use it to decide big layout, hierarchy, flow, and content changes quickly with fewer tokens before producing higher-fidelity variants. Name it with a prefix such as 00-scratch-, 01-scratch-, lo-fi-, or wireframe- so the gallery sorts it first.wireframeFirst is false, the user has opted out — proceed directly to hi-fi HTML mockups for new batches.The toggle is a default, not a hard block — if the user explicitly asks to skip the scratch step on a specific batch, honor that request without flipping the global toggle.
Read the live preference value from the running gallery via GET http://localhost:<port>/preferences, or directly from .mockup-gallery/state.json when the server is not running. Treat a missing preferences block as wireframeFirst: true.
mockups/.data-component="ComponentName" to each distinct section.v2, v3, etc. Do not overwrite prior reviewed mockups.Scratch mockups should be monochrome, rough, direct, and focused on layout, hierarchy, flow, and content decisions.
Higher-fidelity mockups should only follow once the structure is clear. Match the product's existing visual language when available; otherwise keep the design restrained and reviewable rather than decorative.
Use image generation only when a bitmap asset would materially improve review quality, such as product imagery, a realistic hero background, avatars, empty-state artwork, or visual references that cannot be represented well with simple HTML.
Rules:
mockups/assets/ or the relevant session assets directory.node server/gallery-server.mjs..mockup-gallery/state.json first if present, then session state or legacy flat state.When the user selects a page via the gallery (POST /selected), the server emits one structured Markdown file per route to .mockup-gallery/handoff/<route-slug>.md (or the session-scoped equivalent under .mockup-gallery/sessions/<slug>/handoff/). Each file is the canonical implementation brief for that route — frontmatter (schema, route, source, selectedAt, status, filled) plus body sections (Source, Components, Data Elements, Connectors / APIs, Visualizations, States, Open Questions).
The file ships with placeholders; you (the host coding agent) fill it by reading the source mockup's data-component markup, classifying each element (static / dynamic / computed / userInput / action / unknown), capturing data sources and connector contracts, and listing open questions. Flip filled: true in the frontmatter when complete.
DESIGN.md and the handoff artifacts are deliberately separate:
.mockup-gallery/handoff/<slug>.md — interactions, data, states, connectors per selected page.Existing handoff files are preserved on re-emit so agent-filled content is never clobbered; pass regenerateHandoffs: true on the /selected POST when intentionally regenerating from scratch.
When GET /design-system returns { present: true, hasFrontmatter: false }, a DESIGN.md exists but contains no machine-readable YAML token block. Offer to scaffold over it with POST /design-system/scaffold and force: true, or prompt the user to add the frontmatter manually.
status: "done" selections unless the user explicitly asks.changeNote, implement only that described change.