---
name: wireframe
description: Use when the user wants to explore the design space quickly — many rough ideas, not one polished direction. Low-fi, handwritten-font sketches; 3–5 structurally distinct options per idea, not recolors.
---

Loaded when the user wants to explore the design space quickly — many rough ideas, not one polished direction.

## Output location

Write all output files to `./opendesign/mockups/<task-slug>/`. Derive the slug from the task name (e.g. `dashboard-redesign`, `onboarding-flow`).

## Role framing

The goal is breadth, not polish. The output is a map of the design space, not a finished artifact. Use this skill early in a project, before the user has committed to a direction.

Interview the user first to understand the problem, then generate multiple rough takes in one pass.

## Quantity and spread

- Produce 3 to 5 distinctly different approaches per idea. "Distinct" means different structural logic, not different colors of the same layout. If two wireframes could be swapped by changing a class, they are the same wireframe.
- Lay options out side by side so the user can compare them in one glance. For small sets, use a single canvas. For larger sets, use tabbed or paginated groupings so the comparison stays readable.

## Visual style

- Low-fidelity, sketchy vibe. Handwritten-but-readable fonts (e.g. Caveat, Patrick Hand, Shadows Into Light, Kalam).
- Mostly black and white. Sparing color accents only to call out active or emphasized elements.
- Simple shapes: rectangles, lines, circles. No real imagery, no real icons. Placeholder text is fine and expected.
- No polished typography. No real brand colors. No hover states. These are thinking aids, not mockups.

## Structure of each wireframe

- Focus on layout and flow. Where things sit, what reads as primary, what sequence the user moves through.
- Label sections clearly in plain language ("search bar", "filters", "results list", "primary action") so the user can discuss them without pointing.
- When a wireframe implies an interaction, annotate it with a short note. Do not implement it.

## Tweaks and iteration

- Expose a small set of simple tweaks: toggle between variants, change density, swap an optional section in or out. Keep the tweak surface minimal. Wireframes should not compete with prototypes for fidelity.

## What to avoid

- Do not polish a wireframe. If the user likes one, the next step is a separate higher-fidelity pass — not sanding down the sketch.
- Do not let wireframes converge visually. If five options all look the same, you have one option, not five.