/parallel-design-variants

name: parallel-design-variants
description: Use when you want several genuinely different design directions to choose from instead of one design you will iterate on — a page or UI redesign, a hero, a landing, a thumbnail layout — or a live/stream design bake-off where an audience votes. Triggers on "дай варианты дизайна", "несколько вариантов на выбор", "редизайн", "design options", "design bake-off", "/parallel-design-variants".

Parallel Design Variants

Overview

Generate **N genuinely different** design directions at once, each built by its own subagent locked to a **distinct visual reference**, collect them in one gallery, pick winners, then run a **second round that mixes the winning styles**.

**Core principle: divergence comes from reference anchors, not from asking "be creative."** Ten subagents told "make a nice hero" produce ten similar heroes. Ten subagents anchored to terminal / broadsheet / brutalist / swiss / zine produce ten different worlds. Same content, different reference → real choice.

When to Use

• You'd otherwise build one design and iterate — but you don't yet know the direction.
• Redesign, landing, hero, thumbnail layout, email, slide system, any visual surface.
• Live/stream or team bake-off where people vote on options.

**Not for:** a single known direction (just build it), or pixel-level refinement of one chosen design (that's normal iteration).

The Loop

ask how many variants (N)
  → spec issue (constant content + N reference anchors + briefs)
  → N subagents in parallel (blind to each other)
  → gallery index.html (side by side)
  → pick winners (optionally by vote)
  → second round: mix winning styles

Workflow

1. **Ask how many variants (N) — first, before anything else.** Don't silently pick a number; ask the user. Suggest **6–10** as the sweet spot (enough for real divergence, few enough to review side by side) and offer the default, but the count is theirs. Their answer is N for the rest of the flow. 2. **Write ONE spec issue** — it is the orchestration doc, not a throwaway prompt. It contains:

• **Constant content**: the real data and the required sections every variant must render (identical across all). You compare *style*, never completeness.
• **Result layout**: `redesign/index.html` (gallery) + `redesign/{slug}/index.html` per direction. Self-contained HTML — inline CSS, vanilla JS, Google Fonts ok, **no build step, no framework** (so the gallery just opens).
• **A table of N directions**: `slug · name · reference / media-analog`.
• **A shared prompt scaffold** (identity, required sections, real data, output files) — every subagent gets the same scaffold + its own brief.
• **Per-direction briefs**: 2–4 sentences each, naming the reference and its concrete cues (fonts, palette, layout move).

3. **Pick N divergent anchors** (the N the user chose). Each anchor a recognizable, *different* reference — adjacent styles waste a variant. Starter palette:

| slug | reference | slug | reference | |------|-----------|------|-----------| | `terminal` | TUI dashboard (btop, lazygit) | `swiss` | Int'l Typographic grid | | `broadsheet` | newspaper (NYT) | `teletext` | Ceefax / VT323 | | `neon-wire` | tech tabloid (The Verge) | `ticker` | Bloomberg terminal | | `brutalist` | raw web brutalism | `zine` | photocopy punk zine | | `magazine` | print Wired spread | `wire-feed` | Hacker News / teletype |

4. **Dispatch N subagents in parallel** (one message, N tool calls), each: shared scaffold + its brief. Blind to each other — that independence is what produces divergence. Use `sonnet` for design-build subagents. 5. **Build the gallery** `redesign/index.html` linking + previewing all N. Review side by side: `python3 -m http.server` → `/redesign/`. 6. **Pick winners (1–3).** For live/team: the gallery carries a real-time vote (emoji / poll) so the audience picks — the engagement payoff of doing it in public. 7. **Second round — mix winners.** Combine the strongest elements of the top styles into 1–2 refined variants (e.g. swiss grid + zine accents). **Converge by remixing, not by restarting** and not by polishing only one.

Common Mistakes

| Mistake | Fix | |---|---| | Picking N yourself without asking | Ask the user how many variants first; suggest 6–10, but the count is theirs. | | 2–3 variants in adjacent styles | ≥6, each a distinct *named* reference. No real choice otherwise. | | Building variants serially yourself | Parallel subagents, blind to each other — speed + true divergence. | | Different content per variant | Lock the data and required sections; vary only the visual system. | | "Refine the one I liked" as the whole ending | Second round *mixes* winning elements — runners-up have good ideas too. | | Frameworks / build steps | Self-contained HTML so the gallery opens with no toolchain. | | Prompts thrown away in chat | One spec issue = scaffold + briefs → reproducible and reviewable. |

Real-World Impact

Proven live on the **sereja.tech redesign** (YouTube stream "Claude Fable 5, day 2"): a single spec issue → **10 directions, 10 subagents in parallel** → gallery → **audience voted in chat** → second round mixed the winning styles. One session, ten fully-realized directions, a real decision instead of a guess.