create-mockup-lite

name	create-mockup-lite
description	UIモックアップを作成する「create-mockup」スキルの軽量版です。「モックアップ作りたい」「ページ追加したい」「UIデザインを実装したい」「サイトの画面を作りたい」「LP/トップページを作って」「デザインを実装して」、または英語で "create a mockup"、"make a new page"、"implement a UI design"、"build a site screen"、"create a landing page / top page"、"implement a design" などと言ったときに使用します。サイトタイプ・デザインスタイル・ページタイプを確認してから、このプロジェクトの CLAUDE.md の規約に従って実装します。Figma URL なしで UI を構築するときに特に便利です。

create-mockup-lite — UI Mockup Creation Skill (Lite)

Gathers user requirements and implements UI mockups aligned with the project's tech stack.

Prerequisite: A CLAUDE.md file must exist in the project root before running this skill. If missing, guide the user to run /init first, then stop this skill.

---

Step 0: Detect the Tech Stack

0. Dev Environment Check (always run this first)

Check whether package.json exists. If it does not, stop the skill with this message:

"このディレクトリには開発環境がまだセットアップされていません。

Vite 公式ガイド に従って環境をセットアップしてから、/create-mockup-lite を再実行してください。"

If package.json exists, proceed to the next step.

1. Read package.json

From dependencies / devDependencies, detect the following:

Item	Detection method
Framework	astro present → Astro mode. react present (without astro) → React mode. Neither → HTML mode
Astro integrations	In Astro mode, also read astro.config.mjs. @astrojs/react present → React components (.tsx) available. Tailwind detected via @tailwindcss/vite (in vite.plugins) or @astrojs/tailwind
Router	React mode: any of @tanstack/react-router / react-router-dom / next (none found → "none"). Astro / HTML mode: file-based routing or none
Icons	Any of @lucide/astro (Astro mode preferred) / lucide-react / lucide / @heroicons/react / react-icons (none found → "none")
Style utilities	Presence of class-variance-authority / tailwind-variants / clsx / tailwind-merge
Linter	@biomejs/biome present → run check command available

2. Read the mode-specific reference file

Once the mode is determined, read the matching reference file in this skill's directory. It contains the file placement rules, pre-implementation cleanup steps, implementation rules, and mode-specific pitfalls used in Steps 4–5:

Mode	Reference file
Astro mode	references/astro.md
HTML mode	references/html.md
React mode	references/react.md

Do not read the other modes' files — only the one matching the detected mode.

3. Read CLAUDE.md / DESIGN.md

Read CLAUDE.md and note project-specific conventions (CSS file path, image directory, path aliases, file naming rules, etc.). Use this to supplement any information that could not be confirmed from package.json alone.

Also check whether DESIGN.md exists in the project root. If it does, just note that fact here — whether to use it is asked in Step 0.5.

For items not documented in CLAUDE.md, use these defaults:

Item	React mode	HTML mode	Astro mode
CSS entry	src/index.css	src/style.css	src/styles/global.css
Image directory	src/assets/images/	public/images/	src/assets/images/
Path alias	@/ = src/	none	@/ = src/ (if configured in tsconfig.json)

4. Report the detected stack to the user

Summarize the confirmed settings in a single sentence, for example:

"Tech stack confirmed: React + React Router v6, icons: lucide-react, CSS: src/index.css, images: src/assets/images/."

"Tech stack confirmed: Astro v7 (with React integration), Tailwind CSS v4 (@tailwindcss/vite), CSS: src/styles/global.css, images: src/assets/images/."

Also run the following and store the result as frontendDesignInstalled:

node -e "
const os=require('os'),path=require('path'),fs=require('fs');
const h=os.homedir();
const pm=path.join(h,'.claude','plugins','marketplaces');
let found=fs.existsSync(path.join(h,'.claude','skills','frontend-design'));
if(!found&&fs.existsSync(pm)){
  try{for(const m of fs.readdirSync(pm)){if(fs.existsSync(path.join(pm,m,'plugins','frontend-design'))){found=true;break;}}}catch(e){}
}
process.stdout.write(found?'found':'not found');
"

---

Step 0.5: New Project or Add to Existing

After Step 0 completes, confirm the project situation with a single AskUserQuestion call. Include all applicable questions in the same call:

• Question 1 is always included
• Question 2 only when DESIGN.md was found in Step 0
• Question 3 is always included

Question 1 (always):

"Are you starting a new project from scratch, or adding a page to this existing project?"

1. Start fresh (from zero)
2. Add to the existing project

Question 2 (only when DESIGN.md exists):

"I found a DESIGN.md file. It contains design specifications including colors, typography, and component guidelines. Would you like to use this file's specifications for the mockup?"

1. Yes, follow the DESIGN.md spec
2. No, decide through the requirements gathering

Question 3 (always):

"How much creative direction would you like for the design?"

1. Go all-out — distinctive palette, typography, and a unique look tailored to the content (only shown if frontendDesignInstalled is true)
2. Avoid generic AI look — standard process, but actively steers away from clichéd defaults
3. Keep it simple — straightforward design, fewer tokens

Option 1 is only offered when frontendDesignInstalled is true; when it's false, Question 3 has just options 2 and 3 (renumbered 1–2).

Store the answer as useDesignMode for use in Step 1.5.

If "1. Start fresh" is selected → proceed from Step 1 as normal. If DESIGN.md usage was answered "Yes", apply the DESIGN.md content to the color and style decisions in Step 2. Step 1 (site type) is always asked regardless — DESIGN.md may be reused for a different site type or only its color tokens may be needed.

If "2. Add to existing project" is selected → do the following and skip to Step 3 (Steps 1, 2, and 4 are skipped):

1. Read the @theme block from the CSS entry detected in Step 0 and identify the existing color tokens

2. If DESIGN.md usage was answered "Yes", also read its content and treat it as part of the existing design context

3. Report the findings in one line:

   "Existing theme confirmed: --color-primary: #2C4A7C, --color-accent: #F4A261. Proceeding with this design style."

4. Proceed to Step 3 "Confirm page type"

Steps that are skipped: Step 1 (site type gathering), Step 2 (style decisions and @theme setup), Step 4 (demo content removal and CSS entry initialization)

Step 2.5 (image handling) still applies — if the image policy has not been given, ask it together with Step 3.

Rules that still apply: The page structure rules in the mode reference file still apply as normal (HTML mode: copy index.html <head> for new pages; Astro mode: import <Layout>; React mode: follow router conventions).

---

Step 1: Confirm the Site / App Type

First, ask what they want to build. This is the only question needed here:

"What kind of site or app screen would you like to create? (e.g. e-commerce, corporate site, landing page, blog, portfolio, dashboard, etc.)"

Use the user's answer to understand the purpose, target audience, and rough content direction.

---

Step 1.5: Apply guidance skills (conditional, skipped in "Add to existing" mode)

frontend-design

Use the frontendDesignInstalled and useDesignMode values stored in Steps 0 and 0.5.

If frontendDesignInstalled is true AND useDesignMode is "Go all-out": Invoke the frontend-design:frontend-design skill. This skill is not interactive — it only reshapes Claude's design thinking with no user-facing questions. After invocation, carry its philosophy into the design decisions in Step 2.

If useDesignMode is "Avoid generic AI look": Don't invoke the frontend-design skill. Instead, hold yourself to this constraint for every design decision made in Step 2 onward:

NEVER use generic AI-generated aesthetics like overused font families (Inter, Roboto, Arial, system fonts), cliched color schemes (particularly purple gradients on white or dark backgrounds), predictable layouts and component patterns, and cookie-cutter design that lacks context-specific character. Use unique fonts, cohesive colors and themes, and animations for effects and micro-interactions.

Otherwise ("Keep it simple"): Skip silently. Proceed as normal.

Effect on Step 2: When frontend-design has been invoked and the user answers "leave it to me" or gives a vague response, use the site type from Step 1 as a starting point and follow the brainstorm → critique → distinctive-choice process. Avoid templated defaults (cream background + serif, dark background + acid green, etc.) and instead choose a palette, typography, and signature element that are specific to this brief. The same applies under "Avoid generic AI look", scoped to the constraint above rather than the full frontend-design process.

---

Step 2: Confirm the Design Style

"Tell me about your design vision:

• Colors: Do you have brand colors or preferred colors in mind? (or leave it to me)
• Style: What's the mood — modern, minimal, natural, vivid, classic, etc.?
• Any reference sites or designs you like? (optional)
• Images: Use free stock photos (e.g. Unsplash) or placeholders (solid color only)?"

If the user says "leave it to you", decide colors and style based on the site type from Step 1, briefly explain the choices, and proceed. If images were not mentioned in the answer, the policy is confirmed in Step 2.5 — do not silently default.

Once colors are decided, define them in @theme

Add to the @theme block in the CSS entry detected in Step 0:

@import "tailwindcss";

@theme {
  --color-primary:   /* chosen value */;
  --color-secondary: /* chosen value */;
  --color-accent:    /* chosen value */;
  --color-surface:   /* chosen value — default to white/near-white unless the brief justifies a tint */;
}

This is Tailwind CSS v4 — do not use tailwind.config.js.

When following DESIGN.md (answered "Yes" in Step 0.5, or instructed by an orchestrator): treat DESIGN.md as the source of truth, not inspiration —

• Use the colors token names and hex values as-is (colors.primary → --color-primary: #XXXXXX). Do not rename tokens or shift values
• Read the prose sections, not just the frontmatter. If the body (e.g. the Colors section) specifies additional tokens — such as "Border (#E5E5E5) … define as --color-border in @theme" — define and use them exactly as instructed
• Do not introduce brand or accent colors that are not in DESIGN.md. If you believe an extra brand color is needed, propose it to the user first instead of silently adding it
• Utility neutrals are the one exception: if the page needs a border color, a subtle section background, or a placeholder background and DESIGN.md does not provide one, derive it from the palette, add it as an @theme token (e.g. --color-border, --color-surface-alt), and report the addition in your summary. Never fall back to Tailwind default palette classes instead
• The default-palette ban covers every property — bg-neutral-50, border-neutral-200, and a placeholder's bg-gray-100 are violations just as much as text-neutral-600. Every color in the markup must come from an @theme token
• Apply the Layout section (max-width, horizontal padding, section spacing), Shapes (border radius per element type), Components, and Do's and Don'ts to the implementation
• Border radius values: Tailwind defaults are rounded-sm 4px / rounded-md 6px / rounded-lg 8px / rounded-xl 12px. If DESIGN.md rounded values differ (e.g. lg: 12px), override the matching --radius-* in @theme so the utility classes produce DESIGN.md's values — do not leave a silent mismatch
• If @theme already contains color tokens written by an earlier pipeline step (e.g. tailwind-typescale), reuse them — do not define a second, parallel palette

⚠️ Color naming rules — avoid collisions with built-in Tailwind utilities

Do not use the following as the <name> in --color-<name> — they collide with existing Tailwind utilities:

Avoid	Collides with
base	text-base (font-size: 1rem)
sm / md / lg / xl	Responsive breakpoints
full / auto / none	w-full, m-auto, etc.
inherit / current / transparent	CSS keywords

Alternatives: use semantically clear names like surface, canvas, paper, cream, dark, light.

---

Step 2.5: Confirm Image Handling (always runs)

The image policy must be decided explicitly — never silently fall back to placeholders, and never silently infer it from the initial request. This step applies even when Step 2 was skipped ("Add to existing project"). Always ask (may be combined into the same AskUserQuestion call as Step 3 to save a round-trip):

"Images: Use free stock photos (downloaded from Unsplash to the image directory) or solid-color placeholders?"

• Stock photos → download from Unsplash to the image directory detected in Step 0 and reference with local paths (see the mode reference file for the curl pattern). Choose search terms matching the site type
• Placeholders → solid-color <div> blocks with a text label (e.g. Hero Image)

---

Step 3: Confirm Page Type and Priority

"Which pages would you like to build? If there are multiple, please indicate priority order.

• Top page (hero, features, CTA, multiple sections)
• Product listing / detail pages
• Article listing / detail pages
• Forms (contact, sign-up, etc.)
• Other (specific page instructions, just a header or card component, or any partial page UI)"

When there are multiple pages, implement one at a time and ask about the next after each is complete.

If the user writes out detailed specs in a list or long paragraph, accept them as-is and implement accordingly. Only ask follow-up questions when truly necessary — never ask them to repeat information they already provided.

---

Step 3.5: Propose Sections to Include

Based on the site type from Step 1 and the page type from Step 3, propose relevant sections using a single AskUserQuestion call containing two questions, both with multiSelect: true.

Generate the section lists dynamically — think about what sections are commonly included for this specific site/app type and page combination. Do not use a fixed list; tailor proposals to the context.

AskUserQuestion allows a maximum of 4 options per question. Split sections into two questions within the one call: core sections and optional/supplementary sections.

Example for an e-commerce top page:

Question 1 — Core sections (pick the 4 most fundamental):

"Which core sections would you like to include?"

• Hero / Key visual
• Featured collections / Categories
• New arrivals / Best sellers
• Brand story / About

Question 2 — Optional sections (pick the next 4 most relevant):

"Any optional sections to add?"

• Customer reviews / Testimonials
• Newsletter signup
• Social media links
• FAQ

Example for a SaaS landing page:

Question 1 — Core sections:

• Hero with CTA
• Feature highlights
• How it works / Steps
• Pricing plans

Question 2 — Optional sections:

• Customer logos / Social proof
• Testimonials
• FAQ
• Final CTA / Get started

Rules:

• Always ask both questions (core + optional, 4 options each) in one AskUserQuestion call — never skip this step, even if the user already described sections in their initial request. If sections were already specified, pre-select the matching options as the default selection in each question rather than skipping the call, so the user still sees and confirms the full picture
• Combine the selections from both questions as the confirmed section list
• The confirmed sections directly inform what gets implemented in Step 5

---

Step 4: Pre-Implementation Cleanup

Do not use external skills or commands — read and edit files directly.

Follow the "Pre-Implementation Cleanup" section of the mode reference file read in Step 0 (references/<mode>.md).

---

Step 5: Implement

File placement: follow the "File placement rules" section of the mode reference file. Mode-specific implementation details (component syntax, icons, images, navigation specifics) are also in the reference file.

Rules to always follow (all modes)

• Do not use space-x-* / space-y-* — this project's convention is flex/grid with gap-* (in Tailwind v4 the space-* selector implementation changed and can produce unexpected results)
• Do not use divide-x-* / divide-y-* — put the border on each child element instead (e.g. border-b on the li, or *:border-b on the parent)
• Responsive design is required (use sm:, md:, lg: breakpoints)
• If the project defines @theme color tokens (or its rules ban the default palette), never use Tailwind default palette classes (neutral-*, gray-*, slate-*, …) on any property — backgrounds, borders, and placeholder blocks included. Use or extend the @theme tokens instead
• Use semantic HTML tags (header, main, footer, section, nav, etc.)
• Set meaningful alt text on images (use alt="" for decorative images)

Accessibility rules (required, all modes)

Navigation structure

Navigation must always use the nav > ul > li > a (or Link) structure:

<!-- ❌ Avoid -->
<nav>
  <a href="#about">About</a>
</nav>

<!-- ✅ Correct -->
<nav aria-label="Main navigation">
  <ul class="flex gap-6">
    <li><a href="/about" class="hover:text-primary">About</a></li>
  </ul>
</nav>

Framework-specific navigation examples (router Link components, .html paths, etc.) are in the mode reference file.

Uppercase text

Never write uppercase text directly in HTML — apply uppercase as a style using the uppercase class:

<!-- ❌ Avoid (screen readers spell it out letter by letter) -->
<a href="#concept">CONCEPT</a>

<!-- ✅ Correct -->
<a href="#concept" class="uppercase">Concept</a>

Brand names and proper nouns (e.g. NIKE, NASA) may remain uppercase.

Other accessibility requirements

• <button> elements must always have text or an aria-label (icon-only buttons require aria-label)
• <input> elements must have an associated <label> (linked via for / id)
• <section> / <article> elements should contain a heading (h2 or below) or have an aria-label
• If you use aria-labelledby, the referenced id must exist on the heading: <section aria-labelledby="services-heading"> requires <h2 id="services-heading">. When the section contains a visible heading anyway, prefer adding the id over switching to aria-label; never leave a dangling aria-labelledby reference

---

Step 6: Post-Implementation Checks

Run items 1 through 4 below as one continuous flow — do not end the turn between the class checks, the build check, the dev-server startup, and the final report. This applies equally to orchestrated runs: finishing the implementation or reporting the dev-server URL is not the end of the skill.

1. Class duplication and naming collision check (required)

Check for:

• Duplicate classes: the same class name appears more than once in the same class / className (e.g. text-surface text-surface)

• Color vs. utility collision: confirm color names defined in @theme do not clash with built-in Tailwind utility names (refer to the naming rules in Step 2)

• Conflicting utilities: multiple font-size classes on the same element (e.g. text-sm and text-base together)

• Repeated classes replaceable with *:: if every child in a parent-child structure like ul > li has the same class, check whether the parent's *: prefix can consolidate them:

  <!-- ❌ Same classes repeated on each li -->
  <ul>
    <li class="py-2 border-b">...</li>
    <li class="py-2 border-b">...</li>
    <li class="py-2 border-b">...</li>
  </ul>
  
  <!-- ✅ Apply to all children with *: on the parent -->
  <ul class="*:py-2 *:border-b">
    <li>...</li>
    <li>...</li>
    <li>...</li>
  </ul>
  

1.5 Accessibility reference check (required)

• Dangling aria-labelledby: every aria-labelledby value must match an id that actually exists in the same page. Quick check:

  grep -oE 'aria-labelledby="[^"]+"' <file> | sort -u   # compare against id="..." occurrences
  

2. Build error check

If Biome (@biomejs/biome) was detected in Step 0:

<pm> run check   # Biome lint + format
<pm> run build

If not detected:

<pm> run build

Confirm there are no TypeScript errors or Vite build errors.

3. Start the dev server

Once the build succeeds, start the dev server in the background. The default port varies by mode (React / HTML mode: 5173, Astro mode: 4321). If in use, it automatically moves to the next available port — always retrieve the actual port from the startup output and report it to the user.

Steps:

1. Start the server with run_in_background: true and save the output file path
2. Wait 2–3 seconds, then Read the output file
3. Extract the port number from the Local: http://localhost:XXXX/ line
4. Report the URL to the user

grep -oE 'localhost:[0-9]+' <output-file-path> | head -1

Note: Vite + Tailwind CSS v4 projects render as a blank page in preview panes because CSS/JS is not processed there. Always direct users to verify via the dev server URL.

4. Report completion

Report completion to the user.

---

Common Pitfalls (quick checklist)

Mode-specific pitfalls are listed at the end of each reference file. Cross-mode reminders:

• Custom tokens go in @theme — tailwind.config.js is not used in Tailwind v4
• Color token names must not collide with built-in utilities (e.g. never --color-base; see Step 2)
• Duplicate or conflicting classes on the same element are easy to introduce — always run the Step 6 check
• Uppercase via the uppercase class, navigation via nav > ul > li > a (see Step 5)
• gap-* with flex/grid instead of space-x-* / space-y-* (see Step 5)
• Backgrounds and borders sneaking in as neutral-* / gray-* — every color comes from an @theme token; derive --color-border / --color-surface-alt if missing (see Step 2)
• DESIGN.md rounded values that differ from Tailwind defaults need --radius-* overrides in @theme (see Step 2)