parallel-prototyping

name	parallel-prototyping
description	Use when the user asks to prototype a feature, mock something up, explore options, see variations or alternatives, or says "what could this look like" — any request to trial a feature before committing to one approach.

Parallel Prototyping

Overview

A prototype request means minimum 5 genuinely distinct prototypes, built in parallel by senior-caliber builders, presented as an enterprise decision package. Never one. Never throwaway quality. The user is buying a decision surface a VP could approve from.

Invoking this skill IS the request for variants. "The user didn't ask for variants" is void here — they did, by triggering this skill.

Prototype = production candidate. Scoped to one feature, but built so the winning variant MERGES — it does not get rewritten. "Productionizing" after selection means wiring stubs to real backends, nothing more. If choosing a variant would trigger a rewrite, the variant failed.

When to Use

• "Prototype X", "mock up X", "show me what X could look like"
• "Give me options/variations/alternatives for X"
• Before committing to an approach on any new feature

When NOT to use: user names ONE specific design and wants it built ("build the dropdown version"), bug fixes, refactors, or productionizing an already-chosen prototype.

Explicit overrides (the only two): user says "skip parallel-prototyping", or names a single specific design. Nothing else — not "keep it rough", not "quick demo", not deadline pressure — disables this skill.

The Iron Rules

1. MINIMUM 5 PROTOTYPES.
2. EACH DECLARES ITS POSITION ON EVERY AXIS. NO TWO IDENTICAL.
3. VARIANTS MUST COLLECTIVELY VARY ON >= 3 AXES.
4. EVERY VARIANT MEETS THE SENIOR STANDARD. NO EXCEPTIONS.

The Axis Matrix

Every variant brief declares its position on ALL five axes:

Axis	Positions (examples)
UX pattern	strip / drawer / inline section / popover / overlay / dashboard widget
Interaction model	passive-ambient / user-pull / hover-reveal / gesture / progressive-disclosure
Architecture	event-driven / state-machine / render-on-navigation / observer-based / service-layer
Complexity tier	minimal-MVP / standard / full-featured / progressive-enhancement
Aesthetic register	dense-utility / calm-editorial / expressive-brand / industrial / luxury

Rules: no two variants share all five positions; the set must vary on at least 3 different axes (5 UX patterns with identical architecture + interaction = lazy spread — re-brief). Color/copy swaps are NOT positions.

The Senior Standard (every variant, non-negotiable)

Each prototype is built as a senior product engineer + senior product designer would build it:

Engineering:

• All four states designed: loading, empty, error, populated. Happy-path-only = automatic fail.
• Zero placeholders: no TODO, no lorem ipsum, no console.log debugging left in. Realistic domain data (real-looking product names, prices, imagery slots). This includes adapter seams — an unresolved project-specific hookup goes in README integration steps as a wiring instruction, NEVER as a TODO comment in code. Recon exists precisely so seams like toast APIs and auth context get resolved, not deferred.
• Defensive at boundaries: input validated, storage reads wrapped, graceful degradation when APIs/storage unavailable.
• Idiomatic, readable code; comments only for non-obvious WHY.
• Repo-grade: passes the project's linters/formatters, follows its file naming and module conventions, lives where it would live in the real tree. Code a reviewer would approve in a PR today.
• Adapter-isolated stubs: any stubbed backend (storage, API, auth) sits behind a narrow interface — swapping stub for real implementation touches ONE file, zero changes in feature code.
• Multi-script isolation: every JS file on a multi-script page is IIFE-wrapped; zero shared top-level declarations. Two scripts both declaring const ASSET_PREFIX killed an entire variant's JS silently — dispatch briefs must state this.
• No instruction bleed: internal guardrails and canon rules (e.g., "no countdown timers") are constraints on the work, NEVER customer-facing copy in the work. If brief text appears verbatim in UI output, that's a leak.

Design:

• WCAG 2.2 AA: keyboard operable, focus visible, ARIA where semantics need it, contrast checked.
• Full interaction states: hover, focus, active, disabled — not just default.
• Real typographic hierarchy and a consistent spacing scale (not ad-hoc pixel values).
• Mobile-first responsive; no horizontal scroll bugs, touch targets ≥ 44px.
• Honors the project's existing design system / brand tokens when one exists (read it first).

Performance:

• No layout thrash, no unthrottled scroll/resize listeners, animations on transform/opacity only, assets lazy where it matters.

The Art Direction Standard (every variant, non-negotiable)

Engineering excellence with visual timidity is a FAILED variant. A page showing only product images on flat backgrounds is a catalog printout, not a designed experience. Every browser-UI variant must ship a layered visual system:

1. Hero treatment — a real art-directed hero: backdrop imagery or video from the project's library, lockup/brand mark layering, depth (foreground/midground/background). Never a logo floating on a flat color.
2. Atmospheric layer — brand art, texture, or environmental imagery woven through sections (low-opacity backdrops, section dividers, edge accents). The brand should be felt between the products, not just in them.
3. Brand punctuation — marks, monograms, emblems, patches from the asset library used as rhythm elements (section labels, list bullets, dividers, watermarks).
4. Editorial/lifestyle imagery — if the library has lookbook or in-context photography, at least one section uses it. Garments worn beat garments floating.
5. Motion choreography — a deliberate animation system, not just fade-ins: entrance reveals (clip/blur/rise), scroll-driven moments (parallax, pinned beats, marquees), micro-interactions (magnetic CTAs, border-draw, hover states with intent). Reduced-motion always honored.
6. One signature moment — every variant has ONE memorable thing a visitor would describe to someone else (a hero reveal, a scroll moment, an interaction). If you can't name the variant's signature moment, it doesn't have one — build it.

All of it within the project's brand canon and performance budget — art direction is layered ON the Senior Standard, never instead of it.

Process

1. Recon (main thread, before briefing): read the project's stack, design tokens, and conventions — AND inventory the FULL visual asset library: hero backdrops, brand marks/lockups, atmospheric art, lookbook/lifestyle photography, video, texture systems, existing animation vocabularies. Briefs reference real context, not generic assumptions. A recon that only lists product images has not finished reconning.

   Canonical visual manifest: if the project has a visual-asset registry (e.g., SkyyRose: wordpress-theme/skyyrose-flagship/data/visual-manifest.json, verified by data/verify-visual-manifest.py), recon LOADS it and briefs cite assets FROM it — never from ad-hoc greps or session memory. Per-collection/brand ownership in the manifest is law: using an asset on a surface it isn't registered to is a MATERIAL canon failure the taste gate must catch. No manifest in the project? Building one from recon findings IS part of the first prototyping run — re-deriving the asset map every session is the drift that mis-files imagery.

2. Define 5+ variant briefs — each: idea name, one-line thesis, full axis declaration, the user problem it bets on, and a one-line scope estimate (files, rough size). Show the user the brief list with total estimated scale (only checkpoint; then execute). The user can add variants or swap briefs here — never reduce below 5.

3. Dispatch parallel subagents — one per prototype, single message, all at once. Every dispatch prompt embeds: (a) the variant brief, (b) the full Senior Standard block above verbatim, (c) project context from recon. A subagent that gets a one-liner brief produces junior output — the brief is the quality ceiling.

4. Output layout:

   prototypes/<feature-slug>/
     index.html              # UI features: gallery to preview/launch all variants side by side
     RUNBOOK.md              # non-UI features: one command per variant to run it + its tests
     v1-<idea-name>/
       (runnable prototype)
       README.md             # thesis, axis positions, tradeoffs, integration steps (wiring only — code ships as-is)
     ... v5-<idea-name>/
     COMPARISON.md
   

   Name dirs by the idea (v2-sidebar-drawer), never bare v2. UI features get the gallery; backend/CLI/API features get RUNBOOK.md instead — ship whichever fits, both for full-stack.

   Locked-and-loaded delivery (browser UI): the entry index.html is a SINGLE self-contained file — CSS and JS inlined, every image and font embedded as data URIs. Opening that one file anywhere (downloaded, emailed, file://) renders the complete page. Zero references escape the file. Keep styles.css/ alongside as the port sources and note in README that index.html is built from them. A prototype that needs the repo tree or a server to render is not delivered — it's parked.

Rationalizations — All Void

Excuse	Reality
"User didn't ask for variants"	Triggering this skill is asking. 5 is the floor.
"One solid beats five shallow"	Parallel subagents: each variant gets full depth. Count costs nothing.
"Variants respond to feedback"	Backwards. Variants GENERATE the feedback. One option = accept/reject, not a decision.
"Imagery/animation is polish, add it later"	Art direction IS the product for brand surfaces. Product-images-only = catalog printout = failed variant.
"The functional checklist passed"	Two gates. Functional AND taste. A working wireframe is still a wireframe.
"Feature too simple for 5"	Simple features have the cheapest variants. Build them.
"It's just a prototype, skip a11y/states"	Prototype = production candidate. Senior Standard applies. The winner MERGES — junk in the prototype IS junk in production.
"We'll clean it up after selection"	There is no after. Selection → integration wiring only. Code that needs cleanup = variant that failed.
"I'll note the improvement in the README"	Build it instead. README documents tradeoffs and wiring, never deferred quality.
"Good enough to present"	If you can name a better version, the better version is the deliverable. Nameable = buildable = owed.
"That seam is project-specific, leave a TODO"	Recon resolves seams. Unresolvable wiring → README integration step. TODO in code = fail.
"Happy path is enough to judge"	Empty/error/loading states ARE the design decision half the time.
"Subagent brief can be short"	Brief quality = output ceiling. Embed the full standard every dispatch.
"Two of these are basically the same"	Lazy axis spread. Re-brief on a different axis.

Red Flags — STOP and Re-Plan

• About to write one implementation and present it
• Variant briefs differ only in styling, or lack axis declarations
• Dispatch prompts missing the Senior Standard block
• Any variant without README.md, or COMPARISON.md without scored matrix + recommendation
• Lorem ipsum, TODO, or happy-path-only code in any variant
• Stub wired directly into feature code instead of behind an adapter interface
• Delivered entry file referencing anything outside itself (relative paths into the repo, CDN links, sibling files)
• Code that wouldn't pass the project's lint/format gates or follow its conventions
• README "path to production" listing rework instead of pure wiring steps
• Any deliverable containing "could be improved" / "future enhancement" for work buildable now
• A page whose only imagery is product shots — no hero art, no atmospherics, no brand punctuation
• No nameable signature moment in a variant
• Recon that inventoried code conventions but not the visual asset library
• Presenting a variant while privately aware a better version of it exists
• Skipping the self-critique loop because "it's already good"
• Delivering without running/verifying each variant
• Accepting a builder agent's own "it works" as verification
• Backend/CLI variant shipped without its own passing test suite
• Using the critique cap to skip a material finding (missing state, a11y gap, UX flaw)
• Starting to productionize the winner without being asked