Receber por email
← Voltar para o catálogo

arn-spark-clickable-prototype

This skill should be used when the user says "clickable prototype", "arn clickable prototype", "interactive prototype", "test interactions", "validate UX", "user journeys", "test navigation", "make it clickable", "prototype interactions", "test the prototype", "build the screens", "create the UI", "screen mockups", or wants to generate a clickable interactive prototype with linked screens and vali

27estrelas
Atualizado há 3 meses

Ver no GitHub ↗ Licença: MIT

Como adicionar

/plugin marketplace add AppsVortex/arness

O comando exato pode variar conforme o repositório. Confira o README no GitHub.

Para o autor da skill

Cole no README do seu repo

Mostra que sua skill está catalogada na Skillteca, gera backlink e tráfego rastreável.

[![Skillteca](https://www.skillteca.com.br/api/badge/arn-spark-clickable-prototype/svg)](https://www.skillteca.com.br/skills/arn-spark-clickable-prototype)

Alerta por categoria

Receba novas skills de Design e Frontend toda segunda

1 email curto, só com as skills novas de Design e Frontend. 4 minutos de leitura, sem spam, cancela com 1 clique.

Você confirma o email no primeiro envio. Sem spam. Cancela com 1 clique.

Ler descrição completa

Arness Clickable Prototype

Generate a clickable interactive prototype with all main application screens linked together and validate it through iterative build-review cycles, aided by the arn-spark-prototype-builder agent for screen creation, the arn-spark-ui-interactor agent for Playwright-based interaction testing, arn-spark-product-strategist and arn-spark-ux-specialist 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 clickable prototype applications, journey screenshots documenting user flows, 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 interactive behavior validation: do the screens link correctly, do interactions work, can users complete journeys? For visual-only validation of component rendering, use /arn-spark-static-prototype first.

Prerequisites

The following artifacts inform the prototype. 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.

Product concept (strongly recommended):

  1. Read the project's CLAUDE.md for a ## Arness section. If found, 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

Style brief (recommended):

  1. 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

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

Static prototype results (optional):

  1. Check for [prototypes-dir]/static/final-report.md -- if a static prototype was validated, the visual direction is confirmed

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 journey screenshots for comparison. The focus is on screen-level layout comparison and overall flow feel, not component-level fidelity (that was validated in the static prototype).

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 a previous step. 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.

Use cases (recommended):

  1. Read the configured Use cases directory from the ## Arness section (default: .arness/use-cases)
  2. Check for [use-cases-dir]/README.md
  3. If found, scan for [use-cases-dir]/UC-*.md files

If use cases are found: Read the README index and all use case files. Use them alongside the product concept for richer screen and journey derivation (see Step 1b).

If no use cases are found: Derive screens and journeys from the product concept alone. Note: "No use cases found. Screen derivation will use the product concept directly. Run /arn-spark-use-cases first for richer screen derivation from structured behavioral specs."

If a product concept is found: Use it to derive the screen list and user journeys.

If no product concept is found: Ask the user to describe the screens and journeys: "No product concept found. Describe the main screens of your application and the key user flows, and I will create the prototype from your description."

If a style brief is found: Apply the visual style to all screens.

If no style brief is found: Use sensible defaults for the installed component library. Note: "No style brief found. The prototype will use default styling. Run /arn-spark-style-explore first for a custom visual direction."

Project scaffold: The project must be scaffolded with the UI framework and component library installed. If not, inform the user: "The project needs to be scaffolded before building a prototype. Run /arn-spark-scaffold first."

Workflow

Step 1: Detect Resume or Fresh Start

Check for existing versioned output:

  1. Look for prototypes/clickable/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 clickable 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/clickable/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 1b.

Step 1b: Derive Screen List and User Journeys

Load the product concept and extract screens and journeys:

Screens: Extract from the core experience:

  • Each interaction mode suggests one or more screens
  • Each user journey implies a sequence of screens
  • Administrative functions suggest their own screens
  • Check architecture vision for platform-specific screens
  • Check style brief sample screens if any exist
  • Derive state-specific screens: Each distinct state of a major screen should be a separate navigable view (e.g., a connection screen in "searching", "found", "pairing", "connected" states; a main view in "active", "muted", "idle", "offline" states). This makes every meaningful state individually navigable, screenshottable, and testable rather than hiding states behind runtime interactions that may be hard to trigger.

Screen organization: Group screens by functional area (e.g., setup flow, main experience, settings). The builder will create:

  • A hub screen grouping all areas with screen counts and descriptions as the prototype entry point
  • Sequential prev/next navigation within each group for guided walkthroughs
  • Persistent navigation across
Compartilhar X LinkedIn