# Mockup First

> Use when a request changes how an interface looks or is arranged — a new screen, block, form, table, card, or chart; a different layout; a new screen state (empty, error, loading, limit exceeded); "make it look good", "redo the styling", "redesign this page". Do not use for one-off tweaks to a color, size, spacing, font, or copy, for fixing a broken layout, or when told "just do it, no mockup".

- Skill: `leogodnik/mockup-first-2` (Agent Skill)
- Install (CLI): `npx skillmds@latest add leogodnik/mockup-first-2`
- Raw SKILL.md: https://api.skillmd.com/api/skills/leogodnik/mockup-first-2/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: leogodnik (https://skillmd.com/u/leogodnik)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/leogodnik/mockup-first-2

---


# Mockup first, code second

## Why

The gap between what a person pictured and what they got is cheaper to catch in a
mockup than in finished code. This skill inserts one stop: show a clickable mockup as
a link, then wait for a yes before touching the real file.

## Where the line falls

A noticeable change gets a mockup. A one-off tweak goes straight to code.

- Several small tweaks that together change the layout count as one noticeable change.
- If you are unsure whether it is noticeable, treat it as noticeable. But do not build
  a mockup silently — ask in one line.

## Order of work

1. Say in one sentence what is changing. Ask a clarifying question only if the mockup
   would certainly be wrong without an answer. Otherwise take a sensible default and
   name it in the caption.
2. Take the styling from an existing project file: colors, fonts, radii, spacing,
   ready-made markup. Do not invent your own — the mockup should look like a
   continuation of the page.
3. Build the mockup in a temporary folder: the part being changed plus enough
   surroundings to show where it lives. Placeholder data, but plausible. Buttons press,
   tabs switch, empty and error states show if the task involves them. Never touch the
   real file.
4. Publish it as an Artifact. Give the link and 3–4 plain sentences: what is visible,
   which decisions you made on the person's behalf, what you deliberately left for
   later. If publishing fails, save the file and open it in a browser — but do not drop
   the step.
5. Wait for an answer. Revisions mean editing the same file and republishing to the
   same address; the link does not change. Never slip into code silently.
6. After a yes, carry the approved version over literally: layout, labels and states
   match the mockup. The only deviations are ones you were asked for.
7. The mockup file stays in the temporary folder: it never moves into the project or
   lands in git.

## Neighboring skills

- Material for students — `course-handout` handles it: the published page *is* the
  deliverable there, so no separate mockup is needed.
- Not yet decided what to build — `superpowers:brainstorming` comes first.
- `frontend-design` and `make-interfaces-feel-better` apply while building the mockup,
  not instead of it.

## Excuses that do not work

| The thought | What is actually true |
|---|---|
| "It is obvious how this should look" | Obvious to you; it still needs agreeing. |
| "It is a small change" | The layout changes — then it is not small. |
| "I will just show it in finished code" | Then rework happens in the real file. |
| "I will do the mockup and the code at once" | Approval is their answer, not your guess. |
| "They are in a hurry" | A mockup takes two minutes; reworking code does not. |