# UI branch — Delegates to apt:mockup

When the user's question is about **appearance / layout / flow /
discoverability**, the prototype is one or more HTML files generated
by Aperant's existing `/apt:mockup` skill. apt:mockup already enforces
the UI-specific universal rules (zero-dep Tailwind CDN, no JS, throwaway
HTML iterations preserved).

## When this branch fires

Question types that route here:

- "Does this UI shape feel right?"
- "Is this flow discoverable?"
- "Does this layout work on mobile?"
- "Should the primary action be a button or a card?"
- "How does X scale to N items?"

Question types that DO NOT route here (use LOGIC branch):

- "Does this state machine work?"
- "Does this control flow handle edge case X?"
- "Can this protocol handle out-of-order messages?"

## How the delegation works

apt:prototype's UI branch is a thin wrapper that:

1. Parses the user's question to extract the UI element / flow being
   asked about (e.g., "search results card with N items").
2. Invokes the existing skill: `/apt:mockup --variants 3 [extracted topic]`.
3. apt:mockup produces 3 parallel HTML+Tailwind variants under
   `.aperant/mockups/{topic-slug}/` so the user can compare them
   side-by-side.

apt:prototype does NOT re-implement HTML+Tailwind generation — the
discipline lives in apt:mockup's body. UI.md exists so the apt:prototype
skill body can branch on question-type without conflating "logic
prototype" and "UI mockup" code paths.

## The 5 universal rules still apply

apt:mockup already enforces:

- Throwaway-marked (each HTML file carries a comment marker)
- Single-command-run (`open mockup.html` — zero dependencies)
- No-persistence-default (static HTML, no localStorage usage by default)
- Skip-polish (CSS reset, no animation refinement, no responsive
  breakpoints unless the question is about responsive)

The fifth rule — **surface-state-transparently** — is the one
apt:mockup doesn't fully cover by default. For UI prototypes where the
question is about data shape (e.g., "what does this look like with 0
items vs 100 items?"), instruct apt:mockup to render each variant with
a different data-fixture state, and put the fixture JSON in a
side-panel of each mockup so the user can see what's driving the
render.

## What apt:prototype's UI branch adds over running apt:mockup directly

Two things:

1. **Question framing.** apt:mockup is invocable as "build me a mockup
   of X". apt:prototype's UI branch is invocable as "I have a question
   about UI X — show me three answers." The framing shifts the
   discipline from "deliver the mockup the user asked for" to "answer
   the user's question with the cheapest possible visual artifact."

2. **5-rule cross-discipline reminder.** When the UI branch fires, the
   skill body explicitly re-states all 5 universal rules (not just the
   UI-specific ones). The user gets the apt:prototype mental model on
   top of apt:mockup's mechanical output — which prevents the variant
   from drifting into "polish this until it's production-ready."

## When the apt:mockup delegation is NOT enough

If the question requires interaction the user can drive (click through,
hover states, conditional rendering on input), the right call is
`/apt:prototype` LOGIC branch on top of `/apt:mockup` — a tiny
JS-driven terminal-ish runner that swaps between the 3 mockups based
on simulated state. This is rare; most UI questions are answered by
the side-by-side parallel variants apt:mockup already produces.
