mockup-firstlisted

# 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 no