菜单
Build interactive HTML mockups that match the project's actual theme for UX exploration and design review. Use when the user wants to visualize a UI concept, compare design options, or prototype a feature before implementing it in the real codebase.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Structure Claude prompts for clarity and better results using roles, explicit instructions, context, positive framing, and strategic organization. Use when crafting prompts for complex tasks, long documents, tool workflows, or code generation.
Pause agent execution to have the human validate decisions, choose between options, answer freetext, or comment on a document — via the `hl` CLI. Every interaction is a kickoff that returns a job handle immediately; collect the human's answer later with `hl job result`. Use for material design decisions, approval gates, picks between meaningful alternatives, and markdown doc review. Not for trivial yes/no confirmations the agent should decide itself.
Validate technical designs against requirements for coverage, feasibility, and architectural soundness. Use after creating a design.
Validate implementation plans against requirements and design. Use after creating a plan to ensure full coverage and no ambiguities.
Validate requirements documents for EARS compliance, completeness, and consistency. Use after creating requirements.
Design CLIs for humans and LLM agents — subcommand shape, output streams, exit codes, JSON modes, TTY-aware color, structured errors, mutation safety. Use when building or refactoring a CLI, adding machine-readable output, writing --help, deciding stdout vs stderr, or making a tool agent-friendly.
| name | frontend-mockup |
| description | Build interactive HTML mockups that match the project's actual theme for UX exploration and design review. Use when the user wants to visualize a UI concept, compare design options, or prototype a feature before implementing it in the real codebase. |
Build self-contained HTML design review documents. One .html file, no dependencies, opens in a browser. The output is for thinking through design — comparing options, evaluating states, making decisions — before any real code is written.
Extract actual CSS variables from the project's theme file (globals.css, tailwind.config.*, etc.). Map them into the mockup's :root block. Don't guess colors, don't use generic grays when the project has a real palette. Include brand/accent colors — even if used sparingly, they make the mockup feel like the real product.
Read 2-3 real components to absorb the project's visual personality — density, font scale, interaction patterns, border radius, depth strategy. The mockup should feel like it belongs to this project.
The mockup is a scrollable design review document. It has its own chrome (navigation, section headers, callouts) that is visually distinct from the UI being mocked inside it.
A fixed nav bar at the top with anchor links to every section. Dark or inverted background to separate document chrome from content. Section names in the nav should describe the option or state, not just "Section 1."
[Option A: Slide Panel] [Option B: Drawer] [Option C: Inline] [Compare]
The reviewer can jump to any option in one click without scrolling. Highlight the current section on scroll via a small JS IntersectionObserver or scroll listener.
Each section wraps in a rounded card on a tinted page background (body at off-white, sections at white). This creates natural separation without heavy dividers. Alternate section backgrounds between #fff and #fafafa for additional rhythm when sections are long.
Every section opens with:
The prose appears above the mockup frame, so the reviewer is primed with intent before evaluating the visual.
Each design option or state is rendered as a full-fidelity app frame — not a component in isolation. Include enough surrounding UI (navigation, header, content area) that the feature being designed is seen in context.
.mock-titlebar) on the frame to signal "this is an app window" — eliminates any "is this the mockup or the document?" confusionDon't just show the happy path. Render:
Label each state with a small-caps state label inside the mockup section ("State 1 — At Rest", "State 2 — Expanded"). The label answers "what triggered this view?" in one line.
The default state is where users spend their first session and where the feature looks broken if you skip it. Always mock it. For every list, table, chart, panel, or container that holds data, show what renders when the data isn't there yet.
Cover these defaults as applicable:
Use opacity: 0.45–0.5 as the single signal for paused/disabled items. Don't hide them — the reviewer needs to see how inactive items coexist with active ones. One CSS rule communicates the semantic without markup clutter.
When comparing 2-4 options, place them in a horizontal grid at equal width. Hold content constant across options — same data, same names, same numbers — so the only variable is the design treatment. Comparison is spatially guaranteed, not left to chance.
Give each option a color-coded tag (blue for A, pink for B, green for C). The color becomes a mnemonic — reviewers can say "the blue one" without remembering names.
When showing a redesign, put the current state and the proposed state side-by-side in a two-column grid with a 1px border divider. The 1px divider is visually neutral — contrast comes from content, not chrome.
For systematic evaluation, include a table at the end with rows for each criterion and columns for each option. Use semantic coloring: green text for strengths, red for weaknesses, muted for neutral. Keep cells to one phrase — the table is for scanning, not reading.
For multi-step journeys, use a horizontal row of numbered cards connected by arrows. Each card has: a numbered circle, a tag showing effort level, a title, and a 1-2 line description. The whole flow is glanceable in one row.
Color-coded boxes with a small-caps label and body text:
These let reviewers scan for problems vs. positives without reading every word.
When annotating a specific part of a mockup, place prose flush to the right of the mock at a fixed width (~320px). The reviewer never has to switch between the UI and the rationale — they're adjacent.
When a design decision removes something, list it explicitly: what was cut and why (a one-line CSS comment like /* REMOVED: confusing, nobody knows what the bars mean */ works too). This preempts "why didn't you include X?" and shows the decision was deliberate.
Use rem throughout — no px for sizing, padding, margins, gaps, or font sizes. This matches Tailwind conventions.
:root block--muted, --muted-fg, --border) so it never competes with the UI being reviewed1px solid subtle border + light box-shadow (0 1px 3px rgba(0,0,0,0.04))Style thin scrollbars (0.3125rem width, transparent track, border-colored thumb) so they don't disrupt the layout.
<style> — all colors, spacing, fonts as named variables/* ═══ OPTION A ═══ */) so the source file is skimmable<!-- ═══ SECTION 2 ═══ -->)Always open the HTML file so the user sees it immediately.