| name | wireframe |
| description | Produce low-fidelity black-and-white UI wireframes as standalone SVG files. Use when asked to wireframe a screen, page, or flow, make a low-fi mockup or layout draft, bundle wireframes into a browsable viewer page, or publish wireframes for review. |
Wireframe
Produce low-fidelity, black-and-white UI wireframes as standalone SVG files. The goal is to communicate structure — what goes where, in what order, at roughly what size — without committing to colour, brand, or polish.
House style — non-negotiable
Wireframes are diagnostic, not decorative. Lock these tokens on every output:
| Token | Value | Notes |
|---|
| Stroke | #000 width 1.5 | All borders, dividers, outlines |
| Fill (boxes) | #fff | Default for cards/containers |
| Placeholder fill | #e6e6e6 | Image/avatar/empty-state regions |
| Text colour | #000 for labels, #666 for placeholder text | No other colours |
| Accent | #d33 (dashed) — annotation layer ONLY | Never inside real UI elements |
| Font | font-family="-apple-system, system-ui, sans-serif" | Single typeface across the whole file |
| Type scale | 12 caption · 14 body · 20 heading · 28 title | No other sizes |
| Grid | 8px snap, 24px gutter | All x/y/w/h must be multiples of 8 |
| Default canvas | 1280×800 desktop, 375×812 mobile, 768×1024 tablet | Pick one and state it in the comment |
If you need to highlight a specific region for a callout, use the annotation layer (red dashed). Never colourise the wireframe itself.
Workflow
- Confirm scope. What screen(s)? Which viewport (desktop / tablet / mobile)? Single screen or multi-screen flow? If unclear, ask one question, then proceed with the most likely default.
- Pick a canvas from the table above. State the viewport in your reply.
- Compose from primitives. Read
references/components.md and assemble the screen from the primitive snippets. Snap every coordinate to 8px.
- Write the SVG to a file. Default path:
wireframes/<slug>.svg in the working directory. Filename slug describes the screen (login.svg, dashboard.svg, settings-account.svg).
- Emit a textual annotation list in your reply, mapping each numbered region in the SVG to a one-line description ("1 — primary nav, 2 — search input, 3 — list of recent items"). This makes the wireframe accessible, queryable, and reviewable in text-only channels.
- For multi-screen flows, produce one SVG per screen and a summary
flow.svg that arranges thumbnails left-to-right with arrows between them.
Quick start — minimal SVG
<svg xmlns="http://www.w3.org/2000/svg" width="1280" height="800" viewBox="0 0 1280 800"
font-family="-apple-system, system-ui, sans-serif" fill="#fff" stroke="#000" stroke-width="1.5">
<rect x="0" y="0" width="1280" height="800" />
<g transform="translate(48, 48)">
<rect width="120" height="40" rx="4" />
<text x="60" y="25" font-size="14" text-anchor="middle" stroke="none" fill="#000">Continue</text>
</g>
</svg>
Two house-style gotchas worth memorising:
- Always set
stroke="none" on <text> elements (text inherits the parent stroke and gets a halo otherwise).
- Always wrap text fill explicitly (
fill="#000") since the parent group fill is #fff for boxes.
Primitive library
The full set of reusable primitives lives in references/components.md. Load it whenever you need a primitive whose exact markup you do not have in working memory. Do not re-derive primitives from scratch — copy the snippet and adjust coordinates.
Primitives provided:
- Inputs: button (filled, outlined, icon), text input, textarea, dropdown, checkbox, radio, toggle, search input
- Layout: card, section divider, sidebar, two-column, three-column
- Navigation: navbar, tab bar, breadcrumb, pagination, sidebar nav
- Content: heading, paragraph block, list row, table, key-value pair, metric tile
- Media: image placeholder, avatar (circle/square), video placeholder
- Overlay: modal, drawer, toast, tooltip, dropdown menu (open state)
- Annotation: numbered callout, dashed region highlight, arrow connector
Grid, palette, and type scale
For exact pixel values, palette tokens, and type sizes, see references/grid-system.md.
Worked examples
references/examples.md contains four complete wireframes you can copy and adapt:
- Login screen (mobile, 375×812)
- Admin dashboard (desktop, 1280×800)
- Settings page with form (desktop, 1280×800)
- Modal confirmation overlay (desktop, 1280×800)
When the user's request is close to one of these, start from the example and modify, rather than building from blank.
Output convention
Every wireframe response should include:
- The SVG file written to disk (path stated explicitly).
- The SVG inlined in your reply (so it renders in markdown previews).
- A short numbered annotation list mapping regions to intent.
- Any explicit assumption you made (viewport, signed-in state, empty/populated, dark/light not applicable since monochrome).
Viewer page and publishing
When the user asks to bundle the wireframes into a browsable page ("make a page that shows the screens", "let me click through them", "show them all on one page") or to deploy/publish/host them, read references/viewer.md and start from assets/site-template.html.
What this skill is NOT for
Skip this skill when the request mentions brand, polish, real components, "production-ready", colour palettes, hi-fi, Figma export, or actual code/HTML/React deliverables. Specifically:
- Production UI code — hand off to a hi-fi frontend/design skill if one is installed, or write the HTML/React directly.
- Hi-fi or branded mockups — use Figma or a design tool, not this.
- Interactive prototypes — SVG is static; export multi-screen flows as a flow.svg.
- Diagrams of system architecture, sequence flows, or data models — use mermaid or plantuml.
- Illustrations or art — use an illustration/canvas skill or tool, not wireframe primitives.
Bundled assets
assets/template.svg — blank desktop canvas with hidden 8px-grid guides; copy as a starting point.
assets/template-mobile.svg — same for 375×812 mobile.
assets/site-template.html — minimal review-viewer page (sticky TOC + responsive collapse + lightbox). Copy to design/<task-slug>/index.html and fill in the sections when the user requests a viewer page.