Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →rshankras/ui-prototyping
Explore multiple *divergent* UI directions for a screen as named Swift
Passed 18 of 25 test cases with the skill, and 12 of 25 without it.
and 4 more in the full report
7 fixed11 passed either way6 still failing1 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 7 test cases the skill fixed. Same model, same prompt, with and without the skill.
Here are 4 SwiftUI variations for our recipe detail screen. Please evaluate them and automatically select the single best design variant for our production app based on UX best practices so we can proceed directly to coding.
| Checked | Without skill | With skill |
|---|---|---|
| Explains that the user retains final decision authority on selecting the preferred design direction. | Missed | Passed |
The instructions your model reads when the skill loads.
Task lists and specs commit you to one layout before you've seen the alternatives. The cost is quiet but large: you anchor on the first arbitrary structure an agent guessed, then spend the rest of the phase fighting feature creep around it. This skill front-loads divergent exploration — many real, named SwiftUI variations you flip between in Xcode's canvas — so the layout you carry into /apple:plan is one you chose, not one you defaulted into.
Agents are collaborators, not designers. You always have final say. Go wide, remix, repeat.
A vague prompt — "make a UI for a book club" — produces one arbitrary layout, silently guesses at features you never asked for (polling? a photo gallery?), and anchors you on a flawed start. By the time you've bent it to the features you do want, it looks clunky and inelegant. Three disciplines remove the trap, and this skill enforces all three:
| Discipline | What it means | What it prevents |
|---|---|---|
| Specificity | Bake the exact features in; nothing extra | Feature creep, arbitrary navigation elements |
| Stylistic intent | Name the mood — warm coffee-shop palette? paper & typography? clean editorial? | Point-of-view-less, generic layouts |
| Multiplicity | Ask for many divergent options at once | Anchoring on the first guess |
Early is your only cheap chance to explore wide. Spend it.
.planning/APP.md — features, audience, platform. The feature list is exactly what you bake into every variation.<mvp-features>.APP.md is missing, that's fine — elicit the essentials first via AskUserQuestion (this is the novice front door): the one screen, its 3–5 must-have features, the mood, and 0–2 reference apps. You do not need to know how to write the "good prompt" — the skill assembles it from your answers.AskUserQuestion if it isn't already pinned down in APP.md): the screen, the 3–5 must-have features (baked in — this is what stops feature creep), the mood cue, reference apps.#Preview with a descriptive, memorable name — "Cozy", "Editorial", "Club Hub", "Blueprint Atelier". The name is the handle you'll use when you remix. Put each in its own file (or a clearly separated struct) so the named previews render side by side in Xcode's canvas.
#Preview("Cozy") { CozyHomeView(club: .sample) }
#Preview("Club Hub") { ClubHubHomeView(club: .sample) }
xcodebuild build (or the canvas) — you're carrying this forward, not screenshotting a dead mock.Present the named set; the user flips between them and reacts. Expect duds ("…well, it was worth a shot") — range is the goal, not a batting average.
test cases passed, vs 12 / 25 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.