arn-spark-static-prototype

Arness Static Prototype

Create a static component showcase and validate it through iterative build-review cycles, 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 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).

The primary artifacts are versioned showcase pages with component renders, review reports with per-criterion scores, and a final report documenting the complete validation 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.
• 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.
• 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 configuration. If not scaffolded, inform the user: "The project needs to be scaffolded before building a component showcase. Run /arn-spark-scaffold first."

Workflow

Step 1: Detect Resume or Fresh Start

Check for existing versioned output:

1. Look for prototypes/static/v*/ directories at the project root
2. If versions exist, find the highest version number

If existing versions found:

Ask (using AskUserQuestion):

"I found existing static prototype versions up to v[N]. Which would you prefer?"

Options:

1. Continue from v[N] — I will read the latest review report and continue with new cycles
2. Fresh start — I will begin from v1 (existing versions are preserved)

If continuing: read prototypes/static/v[N]/review-report.md to understand the current state and what was flagged. Ask the user for the new cycle budget and any focus refinements.

If no existing versions: Proceed to Step 2.

Step 2: Configure Validation Parameters

Present defaults and ask the user to confirm or adjust:

"Let me set up the validation parameters:

Scoring:

• Scale: 1-5 (1 = unmet, 5 = exemplary)
• Minimum threshold: 4 (every criterion must score at least 4)
• Max cycles: 3 (build-review iterations before judge review)

Criteria: Based on your style brief and product concept, here are the proposed criteria:

| # | Criterion | Description | |---|-----------|-------------| | 1 | [criterion] | [description] | | ... | ... | ... |

Adjust any parameter or criterion, or confirm to proceed."

To propose criteria:

1. Read the default criteria template:

> Read ${CLAUDE_PLUGIN_ROOT}/skills/arn-spark-static-prototype/references/static-prototype-criteria.md

1. Adapt based on available artifacts (remove dark mode criterion if not applicable, add reference image criterion if images exist, etc.)
2. Present the adapted list

When the user confirms, write the agreed criteria to prototypes/criteria.md (create prototypes/ directory if needed).

Step 3: Create Task List

Create the task structure for the validation run. For max_cycles=N:

• Task pairs: Build v[X] + Validate v[X] for each cycle (2 tasks per cycle)
• Judge review task
• User review task

Example for max_cycles=3 (starting from v1):

Task 1:  Build v1
Task 2:  Validate v1
Task 3:  Build v2
Task 4:  Validate v2
Task 5:  Build v3
Task 6:  Validate v3
Task 7:  Judge review
Task 8:  User review

If resuming from v[N], number versions sequentially from v[N+1].

Present the task list to the user and proceed.

Step 4: Build-Review Cycle (Iterative)

For each cycle:

4a: Build

Invoke the arn-spark-prototype-builder agent via the Task tool, passing the model from .arness/agent-models/spark.md as the model parameter (see plugins/arn-spark/skills/arn-spark-ensure-config/references/ensure-config.md "Dispatch convention" for fallback). Context:

• Showcase mode: true
• Style brief: toolkit configuration section
• Component list: components from the criteria + style brief
• UI framework and component library: from architecture vision or the project's dependency configuration
• Project root path
• Output path: prototypes/static/v[N]/
• Reference images (if available): captured screenshots or user-provided images
• **Previous review feedback (if not first cyc