ui-prototyping

Name: ui-prototyping
Author: rshankras

548stars46forks

How to install ui-prototyping?

rshankras/claude-code-apple-skills/ui-prototyping

$npx -y skills add rshankras/claude-code-apple-skills --skill ui-prototyping

Installs into the current project.

Summary

Explore multiple *divergent* UI directions for a screen as named Swift #Previews, remix the strongest elements into hybrids, fill them with lived-in sample content and edge-case states, then tune signature animations with a generated tuning panel. Produces real native SwiftUI you

Files · 1

View on GitHub

SKILL.md

1	# UI Prototyping Skill
2
3	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.
4
5	> Agents are collaborators, not designers. You always have final say. Go wide, remix, repeat.
6
7	## Why this exists (the trap it removes)
8
9	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:
10
11	\| Discipline \| What it means \| What it prevents \|
12	\|---\|---\|---\|
13	\| Specificity \| Bake the exact features in; nothing extra \| Feature creep, arbitrary navigation elements \|
14	\| Stylistic intent \| Name the mood — warm coffee-shop palette? paper & typography? clean editorial? \| Point-of-view-less, generic layouts \|
15	\| Multiplicity \| Ask for many divergent options at once \| Anchoring on the first guess \|
16
17	Early is your only cheap chance to explore wide. Spend it.
18
19	## Input
20
21	- `.planning/APP.md` — features, audience, platform. The feature list is exactly what you bake into every variation.
22	- Optional target screen (arg). If none, prototype the primary screen implied by `<mvp-features>`.
23	- If `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.
24
25	## The method — go wide → remix → make lived-in → tune
26
27	### Stage 1 — Go wide (divergent variations)
28
29	1. Assemble the brief (via `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.
30	2. Generate 6–10 genuinely divergent variations of that ONE screen. Divergence is measured by organizing metaphor, not paint: vary tab vs. grid→detail vs. single-scroll vs. dashboard/standings, the navigation shape, typography (New York / serif vs. SF), density, and color/mood. Two variations that differ only in tint = one wasted slot.
31	3. Each variation gets its own `#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.
32	```swift
33	#Preview("Cozy") { CozyHomeView(club: .sample) }
34	#Preview("Club Hub") { ClubHubHomeView(club: .sample) }
35	```
36	4. Only the requested features appear. If the app needs no polling or gallery, no variation invents one.
37	5. It compiles. `xcodebuild build` (or the canvas) — you're carrying this forward, not screenshotting a dead mock.
38
39	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.
40
41	### Stage 2 — Remix + make it lived-in
42
43	1. Remix. The user names what they liked by preview name and element — "the standings board from Club Hub + the current-book cover from Cozy." Generate new hybrid variations from only those elements, each its own new named preview. Go wide → remix → repeat until one direction feels right.
44	2. Lived-in content. Empty scaffolding lies about how a screen feels. Generate reusable sample models in their own file (delegate to `generators/preview-data-generator`) so you can edit them, and make the content plausible for the audience — a book club's discussions are about books, not lorem ipsum. Plausible also means messy, not idealized: prototype with real data ranges, because the layout that flatters a hilly San Francisco route must also survive a pa

People who liked this also viewed

6 picks

Type

ui-prototyping

548stars46forks

View on GitHub

How to install ui-prototyping?

rshankras/claude-code-apple-skills/ui-prototyping

$npx -y skills add rshankras/claude-code-apple-skills --skill ui-prototyping

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# UI Prototyping Skill
2
3	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.
4
5	> Agents are collaborators, not designers. You always have final say. Go wide, remix, repeat.
6
7	## Why this exists (the trap it removes)
8
9	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:
10
11	\| Discipline \| What it means \| What it prevents \|
12	\|---\|---\|---\|
13	\| Specificity \| Bake the exact features in; nothing extra \| Feature creep, arbitrary navigation elements \|
14	\| Stylistic intent \| Name the mood — warm coffee-shop palette? paper & typography? clean editorial? \| Point-of-view-less, generic layouts \|
15	\| Multiplicity \| Ask for many divergent options at once \| Anchoring on the first guess \|
16
17	Early is your only cheap chance to explore wide. Spend it.
18
19	## Input
20
21	- `.planning/APP.md` — features, audience, platform. The feature list is exactly what you bake into every variation.
22	- Optional target screen (arg). If none, prototype the primary screen implied by `<mvp-features>`.
23	- If `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.
24
25	## The method — go wide → remix → make lived-in → tune
26
27	### Stage 1 — Go wide (divergent variations)
28
29	1. Assemble the brief (via `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.
30	2. Generate 6–10 genuinely divergent variations of that ONE screen. Divergence is measured by organizing metaphor, not paint: vary tab vs. grid→detail vs. single-scroll vs. dashboard/standings, the navigation shape, typography (New York / serif vs. SF), density, and color/mood. Two variations that differ only in tint = one wasted slot.
31	3. Each variation gets its own `#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.
32	```swift
33	#Preview("Cozy") { CozyHomeView(club: .sample) }
34	#Preview("Club Hub") { ClubHubHomeView(club: .sample) }
35	```
36	4. Only the requested features appear. If the app needs no polling or gallery, no variation invents one.
37	5. It compiles. `xcodebuild build` (or the canvas) — you're carrying this forward, not screenshotting a dead mock.
38
39	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.
40
41	### Stage 2 — Remix + make it lived-in
42
43	1. Remix. The user names what they liked by preview name and element — "the standings board from Club Hub + the current-book cover from Cozy." Generate new hybrid variations from only those elements, each its own new named preview. Go wide → remix → repeat until one direction feels right.
44	2. Lived-in content. Empty scaffolding lies about how a screen feels. Generate reusable sample models in their own file (delegate to `generators/preview-data-generator`) so you can edit them, and make the content plausible for the audience — a book club's discussions are about books, not lorem ipsum. Plausible also means messy, not idealized: prototype with real data ranges, because the layout that flatters a hilly San Francisco route must also survive a pa

People who liked this also viewed

6 picks

Type