/arn-spark-static-prototype-teams

name: arn-spark-static-prototype-teams
description: >-
  This skill should be used when the user says "static prototype teams",
  "arn static prototype teams", "team static prototype", "debate static prototype",
  "collaborative visual review", "static prototype with debate",
  "team-based visual review", "visual debate", "review visuals as a team",
  or wants to create a static component showcase and validate it through
  iterative expert debate cycles where product strategist and UX specialist
  discuss their scores and findings before producing a combined review,
  with per-criterion scoring, an independent judge verdict, and versioned output.
  Supports Agent Teams for parallel debate or sequential simulation as fallback.
  For standard lower-of-two-scores visual review, use /arn-spark-static-prototype instead.
version: 1.0.0

Arness Static Prototype Teams

Create a static component showcase and validate it through iterative build-review cycles with expert debate, aided by the `arn-spark-prototype-builder` agent (in showcase mode) for rendering, the `arn-spark-style-capture` agent for screenshots, `arn-spark-product-strategist` and `arn-spark-ux-specialist` (greenfield agents in this plugin) for debate-based expert review, and the `arn-spark-ux-judge` agent for an independent final verdict. This is a conversational skill that runs in normal conversation (NOT plan mode).

This is an alternative to `/arn-spark-static-prototype` (independent sequential review with mechanical lower-of-two scoring). Use this when the project has enough visual complexity that expert debate adds value -- nuanced style decisions, multiple visual grounding assets, components where strategist and UX perspectives genuinely differ. For simpler projects or lower token budgets, use `/arn-spark-static-prototype` instead.

The primary artifacts are **versioned showcase pages** with component renders, **debate review reports** with per-criterion scores and debate findings, and a **final report** documenting the complete validation and debate history. All output is versioned so the user can compare evolution across cycles.

This skill covers visual fidelity validation: do the components look correct according to the style brief? It does not cover interactive behavior -- that is `/arn-spark-clickable-prototype`'s job.

Prerequisites

The following artifacts inform the validation. Check in order:

Determine the prototypes output directory: 1. Read the project's `CLAUDE.md` and check for a `## Arness` section 2. If found, extract the configured Prototypes directory path -- this is the source of truth 3. If no `## Arness` section exists or Arness Spark fields are missing, inform the user: "Arness Spark is not configured for this project yet. Run `/arn-brainstorming` to get started — it will set everything up automatically." Do not proceed without it. 4. If the directory does not exist, create it

> All references to `prototypes/` in this skill refer to the configured prototypes directory determined above.

**Style brief (strongly recommended):** 1. Read the project's `CLAUDE.md` for a `## Arness` section. If found, check the configured Vision directory for `style-brief.md` 2. If no `## Arness` section found, check `.arness/vision/style-brief.md` at the project root

**Product concept (recommended):** 1. Check the configured Vision directory for `product-concept.md` 2. If no `## Arness` section found, check `.arness/vision/product-concept.md` at the project root

**Architecture vision (for framework context):** 1. Check the configured Vision directory for `architecture-vision.md` 2. If no `## Arness` section found, check `.arness/vision/architecture-vision.md` at the project root

**Visual grounding assets (recommended):** 1. Read the `## Arness` section for the Visual grounding directory path 2. Check for assets in `[visual-grounding]/references/`, `[visual-grounding]/designs/`, `[visual-grounding]/brand/` 3. Also check the style brief's Visual Grounding section for asset paths and categories

If found: visual grounding assets will be provided to expert reviewers and the judge alongside showcase screenshots for comparison.

**Fresh design assets (optional):** 1. Read the `## Arness` section for `Figma` and `Canva` fields 2. If either is `yes` AND the visual grounding directory already has assets in `designs/` or `brand/`: Ask (using `AskUserQuestion`):

> **Design assets exist from style exploration. Would you like to pull fresh versions from [Figma/Canva] before starting validation?** > 1. **Yes** — Pull fresh design assets > 2. **No** — Use existing assets on disk

• If yes: ask the user to specify which assets to fetch (Figma file URL, page, or frame names / Canva design URL). Use the corresponding MCP to fetch and save to `[visual-grounding]/designs/` or `[visual-grounding]/brand/`. Show a summary of what was downloaded or replaced.
• If no: proceed with existing assets on disk.

3. If either is `yes` but NO existing design assets found in `designs/` or `brand/`: Ask (using `AskUserQuestion`):

> **No design mockups found yet. Would you like to pull design assets from [Figma/Canva]?** > 1. **Yes** — Pull design assets now > 2. **No** — Proceed without design mockups

• If yes: same flow as above.
• If no: proceed without design mockups.

4. If neither flag is `yes` or flags are missing: skip silently.

**If a style brief is found:** Use it for visual validation criteria.

**If no style brief is found:** Inform the user: "No style brief found. I can create a component showcase with default styling, but visual validation is more meaningful with a style brief. Consider running `/arn-spark-style-explore` first." Proceed if the user wants to continue -- criteria will focus on component quality and layout rather than style fidelity.

**Project scaffold:** The project must be scaffolded with the UI framework and component library installed. Check the project's dependency configura