Generate Wireframe
Instructions
Create or update the project wireframe at docs/wireframes/index.html. The wireframe is a
single-page HTML document that shows every user-facing screen with production-grade visual
design — distinctive typography, cohesive color palette, polished components, and navigation
links. It bridges the use case diagram (what the system does) and stakeholder review (does
this look right?).
This skill uses the frontend-design skill for all visual output. The frontend-design
skill provides the aesthetic direction, typography, color, spatial composition, and motion
guidelines. Read and apply them when generating the HTML.
$ARGUMENTS is optional. If provided, it is a space-separated list of use case IDs
(e.g., UC-001 UC-002 UC-003) to add to an existing wireframe. If omitted, generate
screens for all user-facing use cases in the project.
Purpose
The wireframe serves four downstream consumers:
/engineer-requirements — The wireframe is a required input. Screen layouts, navigation
flows, form fields, and data visibility inform the RE's probing questions, exception path
analysis, and CRUD coverage checks. Without the wireframe, requirements engineering operates
on abstractions disconnected from how users will actually interact with the system./design-screens — Opens the wireframe in Playwright, extracts the visual language
(layout patterns, colors, typography, component styles), and produces themed HTML per
use case with full state coverage. The wireframe's visual identity directly shapes the
design output.- Human review — Stakeholders review the wireframe to validate screen flow, information
hierarchy, visual direction, and navigation. A polished wireframe builds confidence early.
/engineer-requirements — Can trigger wireframe generation for new use cases added
during cluster elaboration, ensuring the wireframe stays current as the project evolves.
Design Philosophy
Production-grade visual design. The wireframe communicates both structure and style:
- Distinctive typography — Use Google Fonts with characterful, unexpected choices. Pair a
distinctive display font with a refined body font. Never use generic fonts (Inter, Roboto,
Arial, system fonts).
- Cohesive color palette — Commit to a bold aesthetic direction with dominant colors and
sharp accents. Use CSS variables for consistency. Avoid timid, evenly-distributed palettes.
- Polished components — Cards, buttons, inputs, tables, and navigation should look like
they belong in a finished product. Use shadows, rounded corners, hover states, and
micro-interactions where appropriate.
- Spatial composition — Use generous whitespace, asymmetry where it adds interest, and
grid-based layouts. Avoid cramped or generic layouts.
- Atmosphere and depth — Add background textures, gradients, or subtle effects that match
the aesthetic direction. Avoid flat solid-color backgrounds.
- Real content, not lorem ipsum — Use realistic placeholder data that matches entity model
attributes (e.g., "Maria Popescu", "maria@example.com", not "Lorem ipsum dolor").
- Navigation is explicit — Every clickable element that navigates to another screen uses
an anchor link (
#UC-XXX) so the wireframe is internally navigable.
Apply the frontend-design skill guidelines for typography, color, motion, spatial
composition, and backgrounds. The wireframe should be visually striking and memorable —
not a gray sketch.
Inputs
| Input |
Location |
Required |
| Use case diagram |
docs/use_cases.puml |
Yes |
| Requirements |
docs/requirements.md |
Yes |
| Entity model |
docs/entity_model.md |
Yes |
| Use case specifications |
docs/use_cases/UC-XXX.md |
If they exist |
| Existing wireframe |
docs/wireframes/index.html |
If updating |
Output
A single HTML file: docs/wireframes/index.html
CRITICAL: The output MUST be an .html file written with the Write tool. Do NOT produce
Markdown. The file extension MUST be .html and the content MUST start with <!DOCTYPE html>.
Internationalization (i18n)
When the project uses internationalization, all placeholder text in the wireframe MUST use
correct, native-quality text for the project's primary locale — including every diacritical
mark and accent required by the language.
Locale detection
Check these sources in order:
- The project's
CLAUDE.md for the marker <!-- NEXA_I18N_CONFIGURED --> (includes locale list and default locale)
- i18n configuration files (e.g.,
next-intl config, i18n.ts, middleware.ts locale list)
- Translation files in
messages/ or locales/ directories
- Use case specifications (which may contain localized text)
- If no locale information is found, default to
lang="en"
Set the lang attribute on <html> to match the detected locale.
Rules
- Never approximate accented characters. Use exact Unicode characters (e.g., Romanian:
ă, â, î, ș (U+0219), ț (U+021B) — never ş (cedilla) or t̜).
- All visible UI text — labels, buttons, placeholders, headings, menu items — must be
written in the project's primary locale with correct accents.
- Use realistic localized placeholder data — names, addresses, and content appropriate
for the locale (e.g., Romanian names for a Romanian app, not anglicized names).
DO NOT
- Use generic AI aesthetics (Inter/Roboto fonts, purple gradients on white, cookie-cutter layouts)
- Use lorem ipsum — use realistic placeholder content from the entity model
- Use any JavaScript framework (no React, no Vue, no Angular)
- Create separate files per screen — everything goes in one
index.html
- Design screens for use cases that have no user-facing interaction (background jobs, system
triggers with no UI)
- Invent screens that have no basis in the use case diagram or requirements
- Destroy existing wireframe sections when adding new ones (incremental updates)
- Add responsive breakpoints or mobile layouts — that is
/design-screens' responsibility
- Strip or approximate diacritics/accents — all UI text must use correct Unicode characters
Nexa Rules Gate
Read and follow ${CLAUDE_PLUGIN_ROOT}/shared/readiness/NEXA_RULES_GATE.md.
Workflow
Phase 1 — Gather Context
- Read
docs/use_cases.puml — extract all use case IDs, names, actors, and relationships
(includes/extends/dependencies). This is the canonical list.
- Read
docs/requirements.md — understand functional requirements and their priorities.
- Read
docs/entity_model.md — understand entities, attributes, and relationships. These
inform the data fields shown on each screen.
- Read any existing use case specifications in
docs/use_cases/ — these provide detailed
screen flows (Main Success Scenario steps) that inform component placement.
- Detect the project locale following the Internationalization rules above.
- If $ARGUMENTS is provided, filter to only those use case IDs. Otherwise, include all
user-facing use cases.
- If
docs/wireframes/index.html already exists, read it to understand the current state.
Phase 2 — Determine Screen Inventory
For each use case in scope, determine the screen(s) it needs:
- Use case specs exist — derive screens from the Main Success Scenario steps. Each
distinct "System displays..." step typically implies a screen or screen state.
- Use case specs do not exist — derive screens from the requirements and use case
diagram. Use the use case name and mapped functional requirements to infer the primary
screen. Simple CRUD use cases typically need a list screen and a form screen.
Build a screen inventory table:
| UC ID |
Screen Name |
Screen Type |
Key Components |
Navigation From |
Navigation To |
| UC-001 |
Registration |
Form |
name, email, password fields, submit button |
Landing (UC-000) |
Verify Email (UC-001A) |
| UC-002 |
Dashboard |
Data display |
stats cards, activity table, quick actions |
Login (UC-001B) |
Profile (UC-003), Reports (UC-004) |
Screen types: Form, List/Table, Detail view, Dashboard, Wizard (multi-step),
Modal/Dialog, Settings, Landing page
Phase 3 — Generate the Wireframe HTML
Using the Write tool, create docs/wireframes/index.html following the HTML structure
below. If updating an existing wireframe, read it first and merge new screens into the
existing document — preserving all existing screen sections.
Incremental Update Rules
When adding screens to an existing wireframe:
- Read the existing
docs/wireframes/index.html.
- Identify which screen sections already exist (by their
id="UC-XXX" anchors).
- Preserve all existing sections unchanged — do not modify their content or structure.
- Add new screen sections after the last existing screen section and before the Navigation
Map section.
- Update the Table of Contents to include the new screens.
- Update the Navigation Map to include the new screens and their connections.
Phase 4 — Verify
- Confirm the file exists at
docs/wireframes/index.html.
- Verify every in-scope use case has a corresponding screen section.
- Verify all internal anchor links (
#UC-XXX) resolve to existing sections.
- Verify the Navigation Map includes all screens and their connections.
HTML Structure
The wireframe uses Tailwind CSS and Google Fonts for production-grade visual quality. Study the
example in examples/ for a complete reference implementation.
Technology stack:
- Tailwind CSS via CDN (
https://cdn.tailwindcss.com) — for all utility-based styling
- Google Fonts — distinctive, characterful font choices (never Inter, Roboto, or system fonts)
- Inline
<style> — only for custom CSS animations, effects, and component styles that
Tailwind cannot express. Define CSS custom properties here for the color palette.
- Inline
<script> for Tailwind config — extend Tailwind with the wireframe's custom
color palette and font families
Design direction
Before writing HTML, commit to a bold aesthetic direction following the frontend-design
skill guidelines:
- Choose a tone — e.g., brutally minimal, luxury/refined, organic/natural, editorial/magazine,
retro-futuristic, playful, art deco, industrial. Pick one and execute with precision.
- Choose distinctive fonts — pair a display font with a body font from Google Fonts. The
pairing should be unexpected and memorable.
- Choose a color palette — 3–4 colors with clear hierarchy. Define as CSS custom properties
and in the Tailwind config. Dominant color with sharp accents, not evenly distributed.
- Choose atmospheric elements — gradients, textures, grain overlays, shadows, or other
effects that create depth and character.
Template structure
<!DOCTYPE html>
<html lang="[project locale]">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>[Project Name] — Wireframe</title>
<script src="https://cdn.tailwindcss.com"></script>
<link rel="preconnect" href="https://fonts.googleapis.com">
<link href="https://fonts.googleapis.com/css2?family=[Display+Font]:wght@[weights]&family=[Body+Font]:wght@[weights][&subset=latin-ext if needed]&display=swap" rel="stylesheet">
<script>
tailwind.config = {
theme: {
extend: {
colors: {
// Define 3-4 palette colors with evocative names and shade scales
// e.g., ocean: { 50: '...', 100: '...', ..., 900: '...' }
},
fontFamily: {
display: ['[Display Font]', 'sans-serif'],
body: ['[Body Font]', 'serif'],
}
}
}
}
</script>
<style>
/* ── CSS Custom Properties ── */
:root {
/* Define palette tokens matching the Tailwind config */
/* Define semantic aliases: --bg-page, --bg-card, --text-primary, --accent, etc. */
}
/* ── Custom animations, effects, and component styles ── */
/* Grain overlays, gradient meshes, hover effects, transitions, etc. */
/* Annotation styles for wireframe metadata */
.wf-annotation {
/* Style annotations to be visually distinct but harmonious with the palette */
padding: 0.75rem 1rem;
font-size: 0.85rem;
margin-bottom: 1rem;
border-radius: 0.5rem;
}
</style>
</head>
<body class="[bg and text classes using palette] antialiased">
<div class="max-w-[1400px] mx-auto px-6 py-8">
<!-- ============================================================ -->
<!-- HEADER -->
<!-- ============================================================ -->
<div class="text-center py-8 mb-8 border-b-2 [border-color]">
<h1 class="font-display text-3xl font-bold">[Project Name] — Wireframe</h1>
<p class="mt-2 [muted-text-color]">[Brief project description] | [N] screens | Actors: [actor list]</p>
</div>
<!-- ============================================================ -->
<!-- TABLE OF CONTENTS -->
<!-- ============================================================ -->
<div class="[card-styling] rounded-xl p-6 mb-8">
<h2 class="font-display text-lg font-semibold mb-4">Screens</h2>
<ul class="columns-2 list-none">
<li class="py-1"><a href="#UC-XXX" class="[link-styling]">UC-XXX: [Screen Name]</a> <span class="text-sm [muted-color]">[Actor]</span></li>
<!-- Repeat for each screen -->
</ul>
</div>
<!-- ============================================================ -->
<!-- SCREEN: UC-XXX — [Screen Name] -->
<!-- ============================================================ -->
<div class="[card-styling] rounded-xl p-8 mb-8" id="UC-XXX">
<div class="flex justify-between items-baseline border-b [border-color] pb-4 mb-6 flex-wrap gap-2">
<h2 class="font-display text-xl font-bold">UC-XXX: [Screen Name]</h2>
<div class="flex gap-3 text-sm [muted-color]">
<span class="[badge-styling] px-3 py-1 rounded-lg">Actor: [Primary Actor]</span>
<span class="[badge-styling] px-3 py-1 rounded-lg">Type: [Form | List | Dashboard | ...]</span>
<span class="[badge-styling] px-3 py-1 rounded-lg">Route: /[suggested-route]</span>
</div>
</div>
<div class="wf-annotation">
<strong>Purpose:</strong> [What this screen accomplishes — derived from use case goal]
</div>
<div class="[viewport-styling] rounded-xl p-6 min-h-[400px]">
<!-- Screen layout using Tailwind utility classes -->
<!-- Build navbars, sidebars, cards, forms, tables, stats grids, etc. -->
<!-- Use the chosen font families, colors, and spatial composition -->
</div>
<div class="wf-annotation mt-4">
<strong>Navigation:</strong> Navigates to <a href="#UC-YYY">UC-YYY: [Screen Name]</a>
on [action]. Returns to <a href="#UC-ZZZ">UC-ZZZ: [Screen Name]</a> on cancel.
</div>
</div>
<!-- Repeat for each screen -->
<!-- ============================================================ -->
<!-- NAVIGATION MAP -->
<!-- ============================================================ -->
<div class="[card-styling] rounded-xl p-8 mb-8">
<h2 class="font-display text-xl font-bold mb-6">Navigation Map</h2>
<!-- Show primary navigation flows as sequences -->
<div class="flex flex-wrap gap-2 items-center mb-3">
<div class="[node-styling] px-3 py-1.5 rounded-lg text-sm"><a href="#UC-XXX">UC-XXX: [Name]</a></div>
<span class="[muted-color] text-sm">→</span>
<div class="[node-styling] px-3 py-1.5 rounded-lg text-sm"><a href="#UC-YYY">UC-YYY: [Name]</a></div>
<span class="[muted-color] text-sm">→</span>
<div class="[node-styling] px-3 py-1.5 rounded-lg text-sm"><a href="#UC-ZZZ">UC-ZZZ: [Name]</a></div>
</div>
<!-- Repeat for each navigation flow -->
</div>
</div>
</body>
</html>
Note: The [bracketed-styling] placeholders above are not literal — replace them with
actual Tailwind classes using your chosen palette. The template shows the structural skeleton;
the visual execution must follow the frontend-design skill's aesthetic guidelines.
Screen Derivation Rules
When deciding what screens to create for each use case:
Use cases WITH specifications
Parse the Main Success Scenario. Each step that says "System displays..." or "System shows..."
implies a screen or significant screen state. Steps like "User enters..." tell you which
form fields belong on that screen.
Example:
- Step 1: "User selects 'New Reservation'" → Button on a list or dashboard screen
- Step 2: "System displays the reservation form" → Form screen
- Step 5: "System displays available rooms" → Same form screen, results section
- Step 9: "System displays confirmation" → Confirmation/success state on the form screen
Combine closely related steps into one screen. Do not create a separate screen for every step.
Use cases WITHOUT specifications
Infer the minimum screen set from the use case type:
| Use Case Pattern |
Screens |
| Create/Register |
One form screen |
| List + View |
List screen with a row that links to a detail screen |
| CRUD entity |
List screen + Create/Edit form (can be same screen or modal) |
| Dashboard/Overview |
Single dashboard screen with cards and tables |
| Multi-step process |
Wizard screen with step indicators |
| Search/Filter |
List screen with filter controls at top |
| Settings/Profile |
Form screen with sections |
| Approval/Review |
Detail screen with action buttons (approve/reject) |
Shared Layout Consistency
All screens that share the same actor and context should have a consistent layout frame:
- Same navbar — If multiple screens share a navigation bar, use the same navbar
structure with the same links across those screens. Highlight the active link.
- Same sidebar — If the app has sidebar navigation, show it consistently with the
active item highlighted.
- Consistent placement — Buttons in the same position, tables with the same column
patterns, forms with the same field layout conventions.
- Same visual identity — Typography, color palette, spacing, and component styles must
be identical across all screens. This is enforced naturally by the shared Tailwind config
and CSS custom properties.
This consistency is essential because /design-screens will derive the shared layout
from the wireframe. Inconsistent wireframes produce inconsistent designs.
1---2name: generate-wireframe3description: Generates a high-quality wireframe as a single-page HTML file showing all screens, their spatial layout, and navigation flow. The wireframe establishes screen structure, component placement, and information hierarchy with production-grade visual design powered by the frontend-design skill. Supports incremental updates: new screens can be added without destroying existing sections. Use when the user asks to "create a wireframe", "generate a wireframe", "sketch the screens", "layout the UI", or mentions wireframe, screen layout, UI skeleton, or low-fidelity mockup.4---56# Generate Wireframe78## Instructions910Create or update the project wireframe at `docs/wireframes/index.html`. The wireframe is a11single-page HTML document that shows every user-facing screen with production-grade visual12design — distinctive typography, cohesive color palette, polished components, and navigation13links. It bridges the use case diagram (what the system does) and stakeholder review (does14this look right?).1516**This skill uses the `frontend-design` skill for all visual output.** The `frontend-design`17skill provides the aesthetic direction, typography, color, spatial composition, and motion18guidelines. Read and apply them when generating the HTML.1920$ARGUMENTS is optional. If provided, it is a space-separated list of use case IDs21(e.g., `UC-001 UC-002 UC-003`) to add to an existing wireframe. If omitted, generate22screens for all user-facing use cases in the project.2324## Purpose2526The wireframe serves four downstream consumers:27281. **`/engineer-requirements`** — The wireframe is a required input. Screen layouts, navigation29 flows, form fields, and data visibility inform the RE's probing questions, exception path30 analysis, and CRUD coverage checks. Without the wireframe, requirements engineering operates31 on abstractions disconnected from how users will actually interact with the system.322. **`/design-screens`** — Opens the wireframe in Playwright, extracts the visual language33 (layout patterns, colors, typography, component styles), and produces themed HTML per34 use case with full state coverage. The wireframe's visual identity directly shapes the35 design output.363. **Human review** — Stakeholders review the wireframe to validate screen flow, information37 hierarchy, visual direction, and navigation. A polished wireframe builds confidence early.384. **`/engineer-requirements`** — Can trigger wireframe generation for new use cases added39 during cluster elaboration, ensuring the wireframe stays current as the project evolves.4041## Design Philosophy4243**Production-grade visual design.** The wireframe communicates both *structure* and *style*:4445- **Distinctive typography** — Use Google Fonts with characterful, unexpected choices. Pair a46 distinctive display font with a refined body font. Never use generic fonts (Inter, Roboto,47 Arial, system fonts).48- **Cohesive color palette** — Commit to a bold aesthetic direction with dominant colors and49 sharp accents. Use CSS variables for consistency. Avoid timid, evenly-distributed palettes.50- **Polished components** — Cards, buttons, inputs, tables, and navigation should look like51 they belong in a finished product. Use shadows, rounded corners, hover states, and52 micro-interactions where appropriate.53- **Spatial composition** — Use generous whitespace, asymmetry where it adds interest, and54 grid-based layouts. Avoid cramped or generic layouts.55- **Atmosphere and depth** — Add background textures, gradients, or subtle effects that match56 the aesthetic direction. Avoid flat solid-color backgrounds.57- **Real content, not lorem ipsum** — Use realistic placeholder data that matches entity model58 attributes (e.g., "Maria Popescu", "maria@example.com", not "Lorem ipsum dolor").59- **Navigation is explicit** — Every clickable element that navigates to another screen uses60 an anchor link (`#UC-XXX`) so the wireframe is internally navigable.6162**Apply the `frontend-design` skill guidelines** for typography, color, motion, spatial63composition, and backgrounds. The wireframe should be visually striking and memorable —64not a gray sketch.6566## Inputs6768| Input | Location | Required |69|-------|----------|----------|70| Use case diagram | `docs/use_cases.puml` | Yes |71| Requirements | `docs/requirements.md` | Yes |72| Entity model | `docs/entity_model.md` | Yes |73| Use case specifications | `docs/use_cases/UC-XXX.md` | If they exist |74| Existing wireframe | `docs/wireframes/index.html` | If updating |7576## Output7778A single HTML file: `docs/wireframes/index.html`7980**CRITICAL: The output MUST be an `.html` file written with the Write tool. Do NOT produce81Markdown. The file extension MUST be `.html` and the content MUST start with `<!DOCTYPE html>`.**8283## Internationalization (i18n)8485When the project uses internationalization, all placeholder text in the wireframe MUST use86**correct, native-quality text** for the project's primary locale — including every diacritical87mark and accent required by the language.8889### Locale detection9091Check these sources in order:921. The project's `CLAUDE.md` for the marker `<!-- NEXA_I18N_CONFIGURED -->` (includes locale list and default locale)932. i18n configuration files (e.g., `next-intl` config, `i18n.ts`, `middleware.ts` locale list)943. Translation files in `messages/` or `locales/` directories954. Use case specifications (which may contain localized text)965. If no locale information is found, default to `lang="en"`9798Set the `lang` attribute on `<html>` to match the detected locale.99100### Rules101102- **Never approximate accented characters.** Use exact Unicode characters (e.g., Romanian:103 ă, â, î, ș (U+0219), ț (U+021B) — never ş (cedilla) or t̜).104- **All visible UI text** — labels, buttons, placeholders, headings, menu items — must be105 written in the project's primary locale with correct accents.106- **Use realistic localized placeholder data** — names, addresses, and content appropriate107 for the locale (e.g., Romanian names for a Romanian app, not anglicized names).108109## DO NOT110111- Use generic AI aesthetics (Inter/Roboto fonts, purple gradients on white, cookie-cutter layouts)112- Use lorem ipsum — use realistic placeholder content from the entity model113- Use any JavaScript framework (no React, no Vue, no Angular)114- Create separate files per screen — everything goes in one `index.html`115- Design screens for use cases that have no user-facing interaction (background jobs, system116 triggers with no UI)117- Invent screens that have no basis in the use case diagram or requirements118- Destroy existing wireframe sections when adding new ones (incremental updates)119- Add responsive breakpoints or mobile layouts — that is `/design-screens`' responsibility120- Strip or approximate diacritics/accents — all UI text must use correct Unicode characters121122## Nexa Rules Gate123124Read and follow `${CLAUDE_PLUGIN_ROOT}/shared/readiness/NEXA_RULES_GATE.md`.125126## Workflow127128### Phase 1 — Gather Context1291301. Read `docs/use_cases.puml` — extract all use case IDs, names, actors, and relationships131 (includes/extends/dependencies). This is the canonical list.1322. Read `docs/requirements.md` — understand functional requirements and their priorities.1333. Read `docs/entity_model.md` — understand entities, attributes, and relationships. These134 inform the data fields shown on each screen.1354. Read any existing use case specifications in `docs/use_cases/` — these provide detailed136 screen flows (Main Success Scenario steps) that inform component placement.1375. **Detect the project locale** following the Internationalization rules above.1386. If $ARGUMENTS is provided, filter to only those use case IDs. Otherwise, include all139 user-facing use cases.1407. If `docs/wireframes/index.html` already exists, read it to understand the current state.141142### Phase 2 — Determine Screen Inventory143144For each use case in scope, determine the screen(s) it needs:1451461. **Use case specs exist** — derive screens from the Main Success Scenario steps. Each147 distinct "System displays..." step typically implies a screen or screen state.1482. **Use case specs do not exist** — derive screens from the requirements and use case149 diagram. Use the use case name and mapped functional requirements to infer the primary150 screen. Simple CRUD use cases typically need a list screen and a form screen.151152Build a screen inventory table:153154| UC ID | Screen Name | Screen Type | Key Components | Navigation From | Navigation To |155|-------|-------------|-------------|----------------|-----------------|---------------|156| UC-001 | Registration | Form | name, email, password fields, submit button | Landing (UC-000) | Verify Email (UC-001A) |157| UC-002 | Dashboard | Data display | stats cards, activity table, quick actions | Login (UC-001B) | Profile (UC-003), Reports (UC-004) |158159Screen types: **Form**, **List/Table**, **Detail view**, **Dashboard**, **Wizard** (multi-step),160**Modal/Dialog**, **Settings**, **Landing page**161162### Phase 3 — Generate the Wireframe HTML163164Using the **Write** tool, create `docs/wireframes/index.html` following the HTML structure165below. If updating an existing wireframe, read it first and merge new screens into the166existing document — preserving all existing screen sections.167168#### Incremental Update Rules169170When adding screens to an existing wireframe:1711721. Read the existing `docs/wireframes/index.html`.1732. Identify which screen sections already exist (by their `id="UC-XXX"` anchors).1743. **Preserve all existing sections unchanged** — do not modify their content or structure.1754. Add new screen sections after the last existing screen section and before the Navigation176 Map section.1775. Update the Table of Contents to include the new screens.1786. Update the Navigation Map to include the new screens and their connections.179180### Phase 4 — Verify1811821. Confirm the file exists at `docs/wireframes/index.html`.1832. Verify every in-scope use case has a corresponding screen section.1843. Verify all internal anchor links (`#UC-XXX`) resolve to existing sections.1854. Verify the Navigation Map includes all screens and their connections.186187## HTML Structure188189The wireframe uses Tailwind CSS and Google Fonts for production-grade visual quality. Study the190example in `examples/` for a complete reference implementation.191192**Technology stack:**193- **Tailwind CSS** via CDN (`https://cdn.tailwindcss.com`) — for all utility-based styling194- **Google Fonts** — distinctive, characterful font choices (never Inter, Roboto, or system fonts)195- **Inline `<style>`** — only for custom CSS animations, effects, and component styles that196 Tailwind cannot express. Define CSS custom properties here for the color palette.197- **Inline `<script>` for Tailwind config** — extend Tailwind with the wireframe's custom198 color palette and font families199200### Design direction201202Before writing HTML, commit to a **bold aesthetic direction** following the `frontend-design`203skill guidelines:2042051. **Choose a tone** — e.g., brutally minimal, luxury/refined, organic/natural, editorial/magazine,206 retro-futuristic, playful, art deco, industrial. Pick one and execute with precision.2072. **Choose distinctive fonts** — pair a display font with a body font from Google Fonts. The208 pairing should be unexpected and memorable.2093. **Choose a color palette** — 3–4 colors with clear hierarchy. Define as CSS custom properties210 and in the Tailwind config. Dominant color with sharp accents, not evenly distributed.2114. **Choose atmospheric elements** — gradients, textures, grain overlays, shadows, or other212 effects that create depth and character.213214### Template structure215216```html217<!DOCTYPE html>218<html lang="[project locale]">219<head>220 <meta charset="UTF-8">221 <meta name="viewport" content="width=device-width, initial-scale=1.0">222 <title>[Project Name] — Wireframe</title>223 <script src="https://cdn.tailwindcss.com"></script>224 <link rel="preconnect" href="https://fonts.googleapis.com">225 <link href="https://fonts.googleapis.com/css2?family=[Display+Font]:wght@[weights]&family=[Body+Font]:wght@[weights][&subset=latin-ext if needed]&display=swap" rel="stylesheet">226 <script>227 tailwind.config = {228 theme: {229 extend: {230 colors: {231 // Define 3-4 palette colors with evocative names and shade scales232 // e.g., ocean: { 50: '...', 100: '...', ..., 900: '...' }233 },234 fontFamily: {235 display: ['[Display Font]', 'sans-serif'],236 body: ['[Body Font]', 'serif'],237 }238 }239 }240 }241 </script>242 <style>243 /* ── CSS Custom Properties ── */244 :root {245 /* Define palette tokens matching the Tailwind config */246 /* Define semantic aliases: --bg-page, --bg-card, --text-primary, --accent, etc. */247 }248249 /* ── Custom animations, effects, and component styles ── */250 /* Grain overlays, gradient meshes, hover effects, transitions, etc. */251 /* Annotation styles for wireframe metadata */252253 .wf-annotation {254 /* Style annotations to be visually distinct but harmonious with the palette */255 padding: 0.75rem 1rem;256 font-size: 0.85rem;257 margin-bottom: 1rem;258 border-radius: 0.5rem;259 }260 </style>261</head>262<body class="[bg and text classes using palette] antialiased">263264<div class="max-w-[1400px] mx-auto px-6 py-8">265266 <!-- ============================================================ -->267 <!-- HEADER -->268 <!-- ============================================================ -->269 <div class="text-center py-8 mb-8 border-b-2 [border-color]">270 <h1 class="font-display text-3xl font-bold">[Project Name] — Wireframe</h1>271 <p class="mt-2 [muted-text-color]">[Brief project description] | [N] screens | Actors: [actor list]</p>272 </div>273274 <!-- ============================================================ -->275 <!-- TABLE OF CONTENTS -->276 <!-- ============================================================ -->277 <div class="[card-styling] rounded-xl p-6 mb-8">278 <h2 class="font-display text-lg font-semibold mb-4">Screens</h2>279 <ul class="columns-2 list-none">280 <li class="py-1"><a href="#UC-XXX" class="[link-styling]">UC-XXX: [Screen Name]</a> <span class="text-sm [muted-color]">[Actor]</span></li>281 <!-- Repeat for each screen -->282 </ul>283 </div>284285 <!-- ============================================================ -->286 <!-- SCREEN: UC-XXX — [Screen Name] -->287 <!-- ============================================================ -->288 <div class="[card-styling] rounded-xl p-8 mb-8" id="UC-XXX">289 <div class="flex justify-between items-baseline border-b [border-color] pb-4 mb-6 flex-wrap gap-2">290 <h2 class="font-display text-xl font-bold">UC-XXX: [Screen Name]</h2>291 <div class="flex gap-3 text-sm [muted-color]">292 <span class="[badge-styling] px-3 py-1 rounded-lg">Actor: [Primary Actor]</span>293 <span class="[badge-styling] px-3 py-1 rounded-lg">Type: [Form | List | Dashboard | ...]</span>294 <span class="[badge-styling] px-3 py-1 rounded-lg">Route: /[suggested-route]</span>295 </div>296 </div>297298 <div class="wf-annotation">299 <strong>Purpose:</strong> [What this screen accomplishes — derived from use case goal]300 </div>301302 <div class="[viewport-styling] rounded-xl p-6 min-h-[400px]">303 <!-- Screen layout using Tailwind utility classes -->304 <!-- Build navbars, sidebars, cards, forms, tables, stats grids, etc. -->305 <!-- Use the chosen font families, colors, and spatial composition -->306 </div>307308 <div class="wf-annotation mt-4">309 <strong>Navigation:</strong> Navigates to <a href="#UC-YYY">UC-YYY: [Screen Name]</a>310 on [action]. Returns to <a href="#UC-ZZZ">UC-ZZZ: [Screen Name]</a> on cancel.311 </div>312 </div>313 <!-- Repeat for each screen -->314315 <!-- ============================================================ -->316 <!-- NAVIGATION MAP -->317 <!-- ============================================================ -->318 <div class="[card-styling] rounded-xl p-8 mb-8">319 <h2 class="font-display text-xl font-bold mb-6">Navigation Map</h2>320321 <!-- Show primary navigation flows as sequences -->322 <div class="flex flex-wrap gap-2 items-center mb-3">323 <div class="[node-styling] px-3 py-1.5 rounded-lg text-sm"><a href="#UC-XXX">UC-XXX: [Name]</a></div>324 <span class="[muted-color] text-sm">→</span>325 <div class="[node-styling] px-3 py-1.5 rounded-lg text-sm"><a href="#UC-YYY">UC-YYY: [Name]</a></div>326 <span class="[muted-color] text-sm">→</span>327 <div class="[node-styling] px-3 py-1.5 rounded-lg text-sm"><a href="#UC-ZZZ">UC-ZZZ: [Name]</a></div>328 </div>329 <!-- Repeat for each navigation flow -->330 </div>331332</div>333334</body>335</html>336```337338**Note:** The `[bracketed-styling]` placeholders above are not literal — replace them with339actual Tailwind classes using your chosen palette. The template shows the structural skeleton;340the visual execution must follow the `frontend-design` skill's aesthetic guidelines.341342## Screen Derivation Rules343344When deciding what screens to create for each use case:345346### Use cases WITH specifications347348Parse the Main Success Scenario. Each step that says "System displays..." or "System shows..."349implies a screen or significant screen state. Steps like "User enters..." tell you which350form fields belong on that screen.351352Example:353- Step 1: "User selects 'New Reservation'" → **Button on a list or dashboard screen**354- Step 2: "System displays the reservation form" → **Form screen**355- Step 5: "System displays available rooms" → **Same form screen, results section**356- Step 9: "System displays confirmation" → **Confirmation/success state on the form screen**357358Combine closely related steps into one screen. Do not create a separate screen for every step.359360### Use cases WITHOUT specifications361362Infer the minimum screen set from the use case type:363364| Use Case Pattern | Screens |365|-----------------|---------|366| Create/Register | One form screen |367| List + View | List screen with a row that links to a detail screen |368| CRUD entity | List screen + Create/Edit form (can be same screen or modal) |369| Dashboard/Overview | Single dashboard screen with cards and tables |370| Multi-step process | Wizard screen with step indicators |371| Search/Filter | List screen with filter controls at top |372| Settings/Profile | Form screen with sections |373| Approval/Review | Detail screen with action buttons (approve/reject) |374375## Shared Layout Consistency376377All screens that share the same actor and context should have a consistent layout frame:378379- **Same navbar** — If multiple screens share a navigation bar, use the same navbar380 structure with the same links across those screens. Highlight the active link.381- **Same sidebar** — If the app has sidebar navigation, show it consistently with the382 active item highlighted.383- **Consistent placement** — Buttons in the same position, tables with the same column384 patterns, forms with the same field layout conventions.385- **Same visual identity** — Typography, color palette, spacing, and component styles must386 be identical across all screens. This is enforced naturally by the shared Tailwind config387 and CSS custom properties.388389This consistency is essential because `/design-screens` will derive the shared layout390from the wireframe. Inconsistent wireframes produce inconsistent designs.
nexadevapp