ui-mockup · diff
git:20260924.c3bd4b5 to git:20260924.8056e4d
61 added, 16 removed. Audit A to A.
---
name: ui-mockup
- description: Create three UI mockup options per round from product screenshots, then refine the user’s favorite. Use for "mock this up," "UI mockup," or "show me what this would look like" for interfaces. Collect screenshots and save approved designs with the ticket or brief.
+ description: Create three UI mockup options per round, then refine the user's favorite until they approve one. Works from screenshots of the current product or from agreed references for something new, with whatever tools are available (an image model, HTML/CSS in a browser, or a wireframe). Use for "mock this up," "UI mockup," or "show me what this would look like" for interfaces. Saves the approved design with the ticket or brief.
---
# UI mockup
- Match the product’s visual language; handle screenshot collection and image-tool selection.
+ Show the person what an interface could look like before anyone builds it.
+ Match the product's visual language when there is a product, and make every
+ option easy to compare.
- ## Start from the current UI
+ ## Start from what exists
- - Reuse screenshots or capture them yourself. When specific user state is unnecessary, launch dev or open accessible production and capture screens with Playwright or app/browser tools, following repository setup guidance. Inspect a small reference set for layout, theme, typography, and components. Ask for screenshots when the required screen or state is inaccessible.
- - Establish the screen, state, change, and elements to preserve; clarify material gaps. For new products, agree on references or a concept labeled as new-image generation. Route prototypes and source changes through the implementation workflow.
+ - **Existing product:** reuse screenshots you have, or capture them. When no
+ specific user state is needed, run the app or open an accessible page and
+ capture with the browser or app tools available (for example Playwright),
+ following the repository's setup notes. Ask for screenshots when the screen
+ or state can't be reached.
+ - **Something new:** agree on references first (products, sketches, a style
+ to follow), and label the result as a new concept.
+ - Pin down the screen, the state, what changes, and what must stay the same.
+ Ask about gaps that change the design; decide the rest yourself.
- ## Edit and iterate
+ ## Pick the medium
- - Read the available image tool's prompting guidance, and its docs for capability or setup questions. Use the image-editing tool with actual screenshot inputs, or generate new concepts from agreed references. Use HTML/CSS reconstruction when requested.
- - If image editing is unavailable, explain and offer setup or handoff. Get agreement for paid API fallbacks.
- - Specify changes and exact labels. Preserve layout, dimensions, theme, typography, density, icons, and unaffected regions. Label inputs as edit targets or style references.
- - Generate three distinct options per round through separate image calls: initial design directions, then refinements of the favorite. Label 1–3, inspect text and unintended changes, and automatically open all three. If opening fails, display inline with file links; explain fidelity limits.
- - Ask for a favorite, then apply feedback using it as the next edit target. Retain original screenshots, prior options, and preservation constraints. A favorite guides iteration; explicit approval selects the final design to save.
+ Use the most faithful medium you have, and say which one you used:
- ## Save the approved result
+ 1. **An image model with editing** (edits a screenshot, or generates from
+ references): best for changes to an existing screen. Read its prompting
+ guidance first. Get the person's agreement before using a paid API.
+ 2. **HTML and CSS in a browser:** always available where a browser is. Rebuild
+ the relevant part of the screen with the product's fonts, colors, spacing,
+ and components, render it, and screenshot it. Good for layout and copy
+ changes, and the result is closer to what gets built.
+ 3. **A wireframe** (ASCII or a quick SVG): for early structure questions when
+ fidelity doesn't matter yet.
- - Follow the destination’s storage skill; reuse the linked Grain workspace or tracker artifact. Honor local-only and draft-only requests; standalone mockups stay local. Preserve the audience and obtain authorization for public sharing. Link private Grain briefs.
- - Save and display approved image bytes with caption, version, and approval status. Retain prompts and source references; identify drafts and rejected versions.
- - Reconcile authorized decisions into the ticket/brief, preserving identity and history. Align scope and acceptance criteria; treat incidental generated details as illustrations.
- - Verify rendering and links, then return image and artifact links. If uploads fail, retain local files and report paths, outstanding saves, or access limits.
+ The same steps apply to every medium.
+
+ ## Three options per round
+
+ - State the change and the exact labels and copy. Keep layout, dimensions,
+ theme, typography, density, icons, and untouched regions as they are unless
+ the option is about them. Mark each input as an edit target or a style
+ reference.
+ - Make three distinct options: design directions in the first round, then
+ refinements of the favorite. Label them 1 to 3.
+ - Check each option for garbled text, changed regions that should have stayed,
+ and anything that couldn't really be built. Open all three for the person;
+ if opening fails, show them inline with file links, and note any fidelity
+ limits.
+ - Ask for a favorite and feedback, and use the favorite as the next round's
+ starting point. Keep the original screenshots, earlier options, and the
+ things that must stay the same. A favorite guides the next round; only
+ explicit approval makes a design final.
+
+ ## Save the approved design
+
+ - Save it where the work lives: with the ticket or brief (see `create-ticket`
+ and `brief`), in Grain when it's connected, or in the page bundle (see
+ `page`) otherwise. Honor local-only and draft-only requests. A standalone
+ mockup stays local.
+ - Save the approved image with a caption, version, and approval status. Keep
+ the prompts or source, the references, and the earlier options, marked as
+ drafts or rejected.
+ - Bring the approved decisions into the ticket or brief: align scope and
+ acceptance criteria with the design, and treat incidental details in the
+ image as illustration.
+ - Match the audience: keep private artifacts private, and get authorization
+ before sharing anything publicly.
+ - Check that images and links render, then return them. If a save or upload
+ fails, keep the local files and report their paths and what is still
+ outstanding.