ui-bakeoff

name

ui-bakeoff

description

Design one UI several ways at once and pick the best — the orchestrator for the ui-* family. Spins up four parallel subagents, each driven by a different posture skill (ui-sharp, ui-reimagine, ui-refine, ui-dense) on IDENTICAL instructions, so you get four genuinely different takes on the same brief, then helps you choose a winner and graft the best features of the others into it. Trigger this when a screen matters enough to explore multiple directions, or when the user says "build it a few ways", "design options", "bake-off", "show me variations", "run the four skills", or "compare approaches". This is the empirically best way to get great UI in this app.

ui-bakeoff — design it four ways, then pick and merge

Running the same brief through four different design postures in parallel, then choosing the best and merging the rest, is the most reliable way to get a great UI here. This skill orchestrates that. You (the agent that triggered this skill) are the conductor — you interview, you spawn, you present, you merge. You do not design anything yourself.

The environment constraints — design around these

• You can run subagents in parallel — issue all four Agent calls in a single message so they run concurrently.
• Subagents cannot stop to ask the user questions — they run autonomously to completion. The interview therefore cannot happen inside them.
• So you, the conductor, run the interview once, up front, and inject the answers into all four subagents. This is the whole reason the interview lives here and not in the children.

Step 1 — Merge the interviews, ask once, in prose

Read the "Interview first" section of all four posture skills:

• .claude/skills/ui-sharp/SKILL.md
• .claude/skills/ui-reimagine/SKILL.md
• .claude/skills/ui-refine/SKILL.md
• .claude/skills/ui-dense/SKILL.md

Take the union of their questions, dedupe the overlap (persona / primary job / reference recur across all four), and ask the user the combined short list — in plain conversation, never a multiple-choice UI. Always include the two universal ones:

• Who is this for and what's the one job they came to do?
• What in the current version already works and must NOT be regressed?

Keep it tight. If the user says "just go," proceed with your best inferences and tell them what you assumed.

Step 2 — Spawn four parallel subagents (one message, four Agent calls)

Each subagent gets identical instructions: the brief + the interview answers + an explicit "the interview is already done — do NOT ask the user anything; build with these answers." Tell each to read ground-rules.md + design-system-anchors.md (paths in .claude/ui-skills/shared/) and its one assigned posture skill, and name which posture it is. Assign:

• subagent 1 → ui-sharp
• subagent 2 → ui-reimagine
• subagent 3 → ui-refine
• subagent 4 → ui-dense

Keep each subagent prompt minimal — this is the most important rule here. Tell it only: which surface(s) to redesign and where they currently live, to read its assigned posture skill + the shared floor, where to build, and to build it real. Do NOT add design direction, component names, "reuse X", "rebuild only the presentation," or any verification choreography. Every such instruction you add silently overrides the skill and flattens the result back toward the existing UI — this is the documented way a bake-off loses all its creativity. The skill carries the design intelligence; your job is to get out of its way. The only exception: a posture the user gave specific guidance for — pass that guidance verbatim, and nothing more of your own.

Step 3 — REAL, not fake (hard rule, no exceptions for real work)

Every subagent builds a real, fully-wired implementation against the actual data, service, and stream — with real loading / empty / error / stalled-stream handling — not a mock demo. (This is ground-rules §1, the rule that matters most. A bake-off of fakes teaches you nothing about the unknowns that actually kill a page.)

To let four real implementations run in parallel without colliding, give each its own route (e.g. …/create-sharp, …/create-reimagine, …/create-refine, …/create-dense) — or its own git worktree (Agent with isolation: "worktree") if they'd otherwise touch shared files. Confine each subagent to its own route/files. Each must verify it runs against real data — including an error and an empty path — before reporting.

Only stub if the user explicitly asks for a throwaway visual exploration (skill/design experimentation, not feature work) — and then say so loudly. Default is always real.

Step 4 — Present, recommend, then merge

Collect the four. For each, summarize: the posture, the reference product it chose, its standout features, and its weak spots. Recommend a winner with reasoning. Then offer the consolidation pass: spawn one more agent that takes the winner as the base and grafts the specific strengths the user liked from the others ("take reimagine's stream animation, refine's error state, dense's table") into a single real, canonical implementation on the true route — then delete the throwaway variant routes.

Notes

• Default to real implementations on parallel routes so the user can view all four on one dev server; use worktrees only when shared-file conflicts are likely.
• The four postures are designed to diverge — converging outputs usually means the brief over-specified the design. If that happens, loosen the brief (say only what the surface is and must do) and let the postures express themselves.