A lo-fi multi-screen MOBILE flow wireframe — three or four phone frames laid out in a row on a board, showing a connected user flow (Onboarding → Home feed → Item detail → Confirm). Grey-box content inside each device, dashed connector arrows + numbered step labels between screens, and a couple of annotation callouts. Reads like an app flow pinned to a whiteboard before any pixels are committed.
NewMaintained
Automatic
◆Design & UX Review pack
Last verified 8/28/2026
What it changes
Passed 1 of 22 test cases with the skill, and 3 of 22 without it.
Without skill14%
With skill5%
Checks it passed that the model alone missed
The response contains zero text following the closing artifact tag.
The HTML output includes data-od-id attributes on the header and phone screens.
The HTML document uses inline CSS without importing external JavaScript libraries.
1 fixed0 passed either way18 still failing3 broke
Pass-rate lift
-9 pp
Tokens
+15%
Agent turns
0%
Response time
-7%
Model gemini-3.6-flashMeasured 8/28/2026v11 of 22 cases passed with skill
Tokens, turns and time describe resource use, not a dollar price.
See it in action
A test case the skill fixed. Same model, same prompt, with and without the skill.
Prompt
We are designing a mobile payment app and want to visualize the screen-by-screen progression for sending money: entering the recipient's phone number, typing the amount with a note, reviewing transaction details, and seeing the success state. Return this visual wireframe layout as a web document rendered inside `<artifact identifier="p2p-transfer-flow" type="text/html" title="Wireframe — P2P Payment Flow">`. Provide just one lead-in sentence prior to the artifact code block and nothing at all after.
What was checked, without and with the skill
Checked
Without skill
With skill
The HTML document uses inline CSS without importing external JavaScript libraries.
Missed
Passed
The HTML output includes data-od-id attributes on the header and phone screens.
Missed
Passed
The response contains zero text following the closing artifact tag.
Missed
Passed
case-03 · gemini-3.6-flash · 8/28/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md61 linessingle file
Wireframe Mobile Flow Skill
Produce a single board showing a mobile app's user flow as a row of lo-fi
phone frames. The point is the flow — how a user moves screen to screen —
not the polish of any one screen. Keep the screens clean grey-boxes (not
scribbly) but keep the connectors and annotations loose and informal.
Workflow
Skip the DESIGN.md if it pushes for finished UI. This skill is
deliberately low-fidelity: greyboxes, placeholder rects, and bars stand in
for real content. Honor type tokens only loosely (system sans for the
board, mono for labels and datelines).
Pick the flow steps from the brief — typically 3–4 connected screens
like Onboarding → Home feed → Item detail → Confirm. Name each step so the
connector arrows can carry a numbered, verb-first label ("① tap Start",
"② open item", "③ add to cart").
Lay out the board, in order:
Board header — bold sans title with a pinned "WIREFRAME v0.1 ·
MOBILE" tag (dashed border, slight rotation) and a mono dateline on the
right (date / device / fidelity).
Phone row — 3–4 rounded device frames (~240–280px wide) in a
horizontal row, each with a notch / status bar. Inside each frame put
the greybox content for its step: hero image-placeholder (rect + X),
title/price bars, list cards (thumbnail X + 2 text bars), category
chips, a bottom tab bar, sticky CTA bars, a confirm checkmark — match the
screen's role.
Connectors — dashed arrows between consecutive phones, each carrying
a small mono step label describing the tap that advances the flow.
Annotations — 1–2 small sticky / callout notes pinned near a screen
to flag intent ("hero must sell value in 3s", "checkout = 1 screen").
Write a single HTML document:
<!doctype html> through </html>, CSS inline, no external JS, no
external images (CSS/SVG placeholders only).
Use Inter / system-ui for the board and IBM Plex Mono for labels via
Google Fonts; a light marker font is allowed for annotations only.
Defined dark device-frame borders, medium-grey content blocks on white
screens, and a single accent color for arrows and annotations so the
board reads clearly even as a small thumbnail.
data-od-id on the header, each phone screen, the connectors, and the