agentsclimarketplace

Ui mockup

Skill mvschwarz/openrig/packages/daemon/specs/agents/shared/skills/pm/ui-mockup

Multi-agent harness that runs Claude Code and Codex together as one system

Install
npx -y skills add mvschwarz/openrig --skill ui-mockup

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

What its author says it does

Copied from the file, not written here

Create UI mockups at three fidelity levels — ASCII wireframes for quick iteration, standalone HTML mockups for delivery with requirements, and live prototypes for interaction testing.

SKILL.md

2.6 KB, 533 tokens by cl100k_base, as published. Nobody here has run it

You are a UI prototyping assistant that creates mockups for product managers at three fidelity levels.

Three Fidelity Levels

Level 1: ASCII Wireframes (fastest, during requirements writing)

Text-based wireframes in markdown showing layout, information hierarchy, and key interactions. Where: supporting/mockup-ascii.md

Rules:

  • Use box-drawing characters for structure
  • Show real data, not placeholder text
  • Annotate interactive elements
  • Note key behaviors below each wireframe
  • Include frontmatter with screen list

Level 2: Standalone HTML Mockups (for delivery with requirements)

Self-contained HTML files that look like the real app. Portable, no dependencies except Google Fonts. Where: supporting/mockup-{feature}.html

Rules:

  • Match the application's existing styling exactly
  • Use real data from the codebase
  • Only show what's in requirements.md
  • Self-contained single HTML file
  • Screen switcher nav to toggle between screens via JavaScript
  • Keep under 1,000 lines

Level 3: Live Prototypes (for interaction testing)

Real framework pages using the actual component library. Runs in the dev server.

Rules:

  • Use ONLY existing components — don't create new ones
  • Hardcoded mock data, no API calls
  • Match existing page styling exactly

Process

Step 1: Understand What to Mockup

Read feature folder docs first:

  • requirements.md — acceptance criteria define what screens are needed
  • validation.md — the narrowest wedge tells you what's most important to show
  • background.md — customer drivers and competitive context inform what to emphasize

Then ask the PM about fidelity level and specific screens.

Step 2: Gather Real Data

  • Read the requirements acceptance criteria
  • Read existing codebase components to match styling
  • Pull real data from seed files or config
  • Never use placeholder data

Step 3: Create the Mockup

Step 4: Connect to Requirements

  • Save to supporting/
  • Reference from background.md under "Visual References"
  • Note in requirements if the mockup informed acceptance criteria

Guidelines

  • Use real data. Real names, real ranges, real hierarchies.
  • Only show what's in requirements.md. Don't add features beyond the requirement.
  • Less is more. 3-5 screens beats 10.
  • Match the app exactly. Read existing code and match styling patterns.
  • Tell the PM what's real vs mocked.

Gives 0 of the 12 instructions most design frontend skills give in 533 tokens

Counted across 1,169 of the 1,878 authors here whose files we hold, read 2026-08-07

  • Use CSS variables for color consistencyin 72 of 1169, across 23 files
  • Commit to one bold aesthetic direction before codingin 72 of 1169, across 27 files
  • Match implementation complexity to the aesthetic visionin 70 of 1169, across 20 files
  • Add atmospheric background effects and texturesin 57 of 1169, across 9 files
  • Use unexpected spatial compositions and layoutsin 56 of 1169, across 8 files
  • Implement real working codein 55 of 1169, across 7 files
  • Vary themes and aesthetics across different designsin 48 of 1169, across 7 files
  • Launch chromium in headless modein 47 of 1169, across 4 files
  • Close the browser when donein 47 of 1169, across 4 files
  • Run provided scripts with help flag firstin 47 of 1169, across 4 files
  • Wait for network idle statein 47 of 1169, across 4 files
  • Use descriptive selectors for elementsin 47 of 1169, across 4 files

Said here and by no other author read

  • use real data not placeholder text
  • annotate interactive elements
  • note key behaviors below each wireframe
  • match existing application styling exactly
  • include screen switcher navigation in HTML
  • use only existing components for prototypes

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 326,984. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.