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.
1---2name: wireframe3description: 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.4---56Loaded when the user wants to explore the design space quickly — many rough ideas, not one polished direction.78## Output location910Write all output files to `./opendesign/mockups/<task-slug>/`. Derive the slug from the task name (e.g. `dashboard-redesign`, `onboarding-flow`).1112## Role framing1314The 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.1516Interview the user first to understand the problem, then generate multiple rough takes in one pass.1718## Quantity and spread1920- 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.21- 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.2223## Visual style2425- Low-fidelity, sketchy vibe. Handwritten-but-readable fonts (e.g. Caveat, Patrick Hand, Shadows Into Light, Kalam).26- Mostly black and white. Sparing color accents only to call out active or emphasized elements.27- Simple shapes: rectangles, lines, circles. No real imagery, no real icons. Placeholder text is fine and expected.28- No polished typography. No real brand colors. No hover states. These are thinking aids, not mockups.2930## Structure of each wireframe3132- Focus on layout and flow. Where things sit, what reads as primary, what sequence the user moves through.33- Label sections clearly in plain language ("search bar", "filters", "results list", "primary action") so the user can discuss them without pointing.34- When a wireframe implies an interaction, annotate it with a short note. Do not implement it.3536## Tweaks and iteration3738- 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.3940## What to avoid4142- Do not polish a wireframe. If the user likes one, the next step is a separate higher-fidelity pass — not sanding down the sketch.43- Do not let wireframes converge visually. If five options all look the same, you have one option, not five.
manalkaff