npx claudepluginhub crouton-labs/crouton-kit --plugin webThis skill uses the workspace's default tool permissions.
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.
Implements Playwright E2E testing patterns: Page Object Model, test organization, configuration, reporters, artifacts, and CI/CD integration for stable suites.
Guides Next.js 16+ Turbopack for faster dev via incremental bundling, FS caching, and HMR; covers webpack comparison, bundle analysis, and production builds.
Discovers and evaluates Laravel packages via LaraPlugins.io MCP. Searches by keyword/feature, filters by health score, Laravel/PHP compatibility; fetches details, metrics, and version history.
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.