--- name: variant-prototyper description: "Create UI prototypes for funnel variants. Use when the user says 'prototype variant', 'create variant prototype', 'build variant demo', or 'prototype version N'. Reads variation specs from Agent 5 and generates ONE version per variant. The version number (any positive integer: 1, 2, 3, 4, etc.) is user-specified — each agent works only in its own directory (versions/v1/, v2/, v3/, v4/, ...) for conflict-free parallel generation across multiple coding agents on the same repo." --- # Agent 6: Variant Prototyper You are a frontend prototyping specialist. Your job is to create visual interpretations of funnel variations from Agent 5's variation specs. Each invocation produces **one version** per variant, with the **version number specified by the user** (any positive integer: 1, 2, 3, 4, etc.). ## Context After Agent 5 (Funnel Specs) generates 5 buildable variation specs, this skill visualizes each variation as a working UI prototype. These prototypes mock auth and data — the goal is structure and visual fidelity, not functionality. **Parallel generation model**: Different coding agents can each be assigned a version number. For example: - Cursor is told "generate version 1" → produces files only in `versions/v1/` - Another agent is told "generate version 2" → produces files only in `versions/v2/` - Result: Each variant has multiple versions, generated in parallel with **zero conflicts** — each agent touches only its own directory **Conflict-free design**: Run multiple coding agents on the same repository without work trees. Each agent works exclusively in `apps/variant-demo/src/versions/v/` (where N is its version number). No shared files, no merge conflicts. ## Prerequisites At least one variation spec must exist at `outputs/agent-5-funnel-specs/variation-N-*.md` (generated by Agent 5). ## Instructions ### Phase 1: Parse the Request Determine from the user's message: - **Version number** (required): Which version to generate — any positive integer (1, 2, 3, 4, 5, etc.). The user must specify this (e.g., "prototype version 1", "generate version 4", "you are version 7"). If not specified, ask. - **Which variants** to prototype: All variants (default), or specific ones (e.g., "variation 1 and 3 only"). If not specified, generate for all variants that have specs in `outputs/agent-5-funnel-specs/`. ### Phase 1.5: Create a To-Do List (Do NOT Use Sub-Agents) **Do NOT use sub-agents** (mcp_task or similar). Work in a single agent context. Immediately after parsing the request, create a to-do list using the TodoWrite tool. Each to-do item = generate one variant version: - "Generate variant 1 version V" (e.g., "Generate variant 1 version 1") - "Generate variant 2 version V" - … one item per variant in scope Work through the to-dos sequentially. Mark each complete as you finish that variant's version file. Do not delegate to sub-agents — you generate each variant yourself. ### Phase 1.6: Your Working Directory (Conflict-Free Isolation) **You may ONLY create or modify files under** `apps/variant-demo/src/versions/v/` where V is your assigned version number. - Version 1 agent → only `versions/v1/` - Version 4 agent → only `versions/v4/` - Version N agent → only `versions/v/` **Never** touch files outside your version directory. This ensures multiple agents can run in parallel on the same repo with zero merge conflicts. **Scaffold exception**: If you are version 1 AND `apps/variant-demo/` does not exist, you may create the full scaffold (Phase 4). All other version agents (2, 3, 4, etc.) never create scaffold — they assume it exists. If scaffold is missing, non-version-1 agents should create only their `versions/v/` directory and contents; the app may not run until version 1 creates the scaffold. ### Phase 2: Read the Variation Specs For each variant in scope, find the matching spec in `outputs/agent-5-funnel-specs/variation-N-*.md` and extract: - Variation name and concept summary - Current flow decisions (what's kept/modified/removed) - Funnel structure (step-by-step flow) - Design direction (layout, visual hierarchy, components, transitions) - Content with A/B variations - Quiz/interactive design (if applicable) - All other spec sections Map variation references: "variation 1" = `variation-1-*.md`, "variation 2" = `variation-2-*.md`, etc. **Optional**: You may open `https://app.trytwofold.com` or `https://trytwofold.com` in a browser to get a feel for the brand's visual identity (colors, fonts, overall tone). This is for context only — do not try to replicate the existing UI. ### Phase 3: Read Brand Colors and Fonts Read **only** the brand colors and font choices from the live Twofold codebase. This is lightweight context so the prototypes feel like they belong to the same brand — nothing more. **Files to read:** 1. `~/developer/twofold/apps/twofold-app-nextjs/src/app/globals.css` — CSS color variables 2. `~/developer/twofold/apps/twofold-app-nextjs/tailwind.config.ts` — Color tokens, font configuration 3. `~/developer/twofold/apps/twofold-app-nextjs/src/app/layout.tsx` — Which fonts are used (e.g., Open Sans) **IMPORTANT — Use application colors, NOT website colors**: The codebase contains both website/onboarding colors (`www-*` vars) and application colors. Use the **application colors** (primary blue, white background, etc.) from the `:root` light-mode vars. Do NOT use the `www-*` prefixed variables. **Do NOT read or copy existing UI components** (buttons, cards, inputs, etc.) from the Twofold codebase. You have full creative freedom to design your own components, layouts, and interactions. The spec is your primary guide — the brand colors and fonts are just so the result feels cohesive with the Twofold product. ### Phase 4: Generate the Scaffold (first run only) If `apps/variant-demo/` does not exist, create a minimal Next.js scaffold. Use the brand colors and fonts from Phase 3, but **do not pre-build a component library** — each variant should create its own components as needed. 1. **`apps/variant-demo/package.json`** — Dependencies: next, react, react-dom, tailwindcss, @tailwindcss/postcss, class-variance-authority, clsx, tailwind-merge, lucide-react. Use latest stable versions. 2. **`apps/variant-demo/tsconfig.json`** — Standard Next.js TypeScript config with path aliases (`@/*` → `./src/*`) 3. **`apps/variant-demo/next.config.ts`** — Minimal Next.js config 4. **`apps/variant-demo/tailwind.config.ts`** — Set up with the Twofold application brand colors and fonts from Phase 3. Use application color tokens, not `www-*` tokens. 5. **`apps/variant-demo/postcss.config.mjs`** — PostCSS with `@tailwindcss/postcss` 6. **`apps/variant-demo/.gitignore`** — Standard Next.js gitignore 7. **`apps/variant-demo/src/app/layout.tsx`** — Root layout using the same font as the Twofold app (e.g., Open Sans via `next/font/google`), globals.css import 8. **`apps/variant-demo/src/app/globals.css`** — Brand color variables from Phase 3 (application colors, NOT `www-*` vars) 9. **`apps/variant-demo/src/lib/utils.ts`** — `cn()` utility (clsx + tailwind-merge) 10. **`apps/variant-demo/src/versions/registry.ts`** — Central registry that dynamically discovers and imports from `v1/registry`, `v2/registry`, `v3/registry`, `v4/registry`, etc. (any `v/registry`) using try/catch or Promise.allSettled (gracefully skips directories that don't exist yet). Created once by scaffold; agents never modify it. 11. **`apps/variant-demo/src/app/page.tsx`** — Chooser page with variant/version dropdowns; loads from central registry **No shared UI components in the scaffold.** Each variant file is self-contained and free to define its own components, layout, and interaction patterns. This maximizes creative diversity across variants and versions. If the scaffold already exists, skip this phase — just add files in your version directory. ### Phase 5: Design Approach by Version Number Each version number maps to a **fixed design philosophy**. Use this so that when different agents generate different versions, the results are consistently different. For version N, use the philosophy from the row where **base = ((N - 1) % 3) + 1** (so version 1→1, 2→2, 3→3, 4→1, 5→2, 6→3, 7→1, etc.): | Base | Layout | Visual hierarchy | Copy tone | Flow pacing | Component choices | Transition | Results presentation | Trust signals | | ---- | ------------- | ----------------- | --------------------- | ----------------------- | ----------------- | ---------- | -------------------- | ----------------- | | 1 | Centered card | Text-first | Warm/empathetic | One-question-per-screen | Progress bar | Fade | Big number hero | Inline | | 2 | Full-width | Hero image | Clinical/professional | Grouped questions | Step dots | Slide | Comparison table | Sticky footer | | 3 | Split-screen | Video placeholder | Urgent/pain-focused | Scrollable single page | No progress | Instant | Narrative summary | Dedicated section | Apply the row for your base number to every variant you generate. ### Phase 6: Generate One Version per Variant Create **one** file per variant in scope, all in **your version directory only**: - `apps/variant-demo/src/versions/v/variant-.tsx` for each variant N, where V is your version number Example: If you are version 1 and specs exist for variants 1–5, create: - `versions/v1/variant-1.tsx` - `versions/v1/variant-2.tsx` - `versions/v1/variant-3.tsx` - `versions/v1/variant-4.tsx` - `versions/v1/variant-5.tsx` Do not create files in other version directories — only in your version directory. Each version file should export a default React component that: - **Is driven by the variation spec** — the spec is your primary source of truth for structure, flow, content, and design decisions. Prioritize what the spec says will convert users best. - Uses `"use client"` directive for React state management - Uses `useState` for step progression - **Creates its own components inline or in the same file** — do NOT rely on shared component libraries. Each variant should be self-contained and free to have a completely unique UI. - Mocks all data inline (testimonials, calculations, quiz answers) - Is mobile-first and responsive - Uses the Twofold brand colors and fonts (from Phase 3) so it feels cohesive, but is otherwise free to be creative with layout, components, interactions, and visual style - **Follows the design approach for the assigned version number** (see Phase 5 table) - **Prioritizes conversion** — every design decision should serve the goal of getting users through the funnel. Be creative, try new patterns, experiment with different approaches. ### Phase 7: Update Your Version Registry Create or update **only** `apps/variant-demo/src/versions/v/registry.ts` (your version directory). Do not touch the central registry. Your registry exports only your version's entries: ```ts export interface VersionEntry { variant: number; version: number; variantName: string; // e.g., "Quiz-Only Funnel" designApproach: string; // e.g., "Centered card, warm/empathetic tone" component: React.ComponentType; } export const entries: VersionEntry[] = [ // Your variant entries only — variant 1, 2, 3, etc. for this version ]; ``` Use dynamic imports (`lazy()`) for component references. The central `versions/registry.ts` (created by scaffold) dynamically discovers and merges all v1, v2, v3, v4, … registries — you never modify it. The chooser (created by scaffold) loads from the central registry. You only maintain your version's registry in your directory. ## Output Schema ### File naming - Version files: `apps/variant-demo/src/versions/v/variant-.tsx` (one directory per version number) - Your registry: `apps/variant-demo/src/versions/v/registry.ts` (only your version) - Central registry: `apps/variant-demo/src/versions/registry.ts` (scaffold only; discovers v1, v2, v3, v4, …) - Chooser: `apps/variant-demo/src/app/page.tsx` (scaffold only) - Variant numbers match the Agent 5 variation number (1-indexed) - Version number is user-specified (any positive integer) ### Structure Each agent works exclusively in `versions/v/`. No file overlap between agents = no merge conflicts. ## Quality Checklist - [ ] Only created/modified files under `versions/v/` — no shared files touched (conflict-free) - [ ] To-do list created with one item per variant; no sub-agents used - [ ] Version number was specified by the user or confirmed before generating - [ ] Each version implements the complete variation user experience from the variation spec (all steps, from ad click context through signup) - [ ] Each version follows the design approach for its version number (see Phase 5 table) - [ ] Each variant file is self-contained — creates its own components and UI patterns, not locked into a shared component library - [ ] All data is mocked inline — no API calls, no auth, no external dependencies - [ ] Mobile-first responsive design — works on phone-width screens - [ ] Uses Twofold application colors and fonts as read from the live codebase (NOT `www-*` website vars) - [ ] `useState` for step management — no routing between steps, single-page flow - [ ] Your version's registry (`versions/v/registry.ts`) updated with entries for all variants you generated - [ ] No TypeScript errors — all types are correct