prototype-audit

prototype-audit

Research tells you what's true about users; a prototype is a bet about how to respond to that truth. This skill checks whether the bet is a good one — reading a research-synthesis doc and a prototype side by side, then writing a prioritized plan that closes whatever gap exists between them. It's a judgment task, not a checklist: the goal is an honest, well-evidenced answer to "does this actually address what we heard," not a mechanical diff.

Inputs

Two things must already exist: a research synthesis (themes, insights, quotes — typically research-synthesis output, though any findings doc will do) and a prototype meant to respond to it. The prototype can be:

• a React/Vite app (prototype-design output) or an Angular build (spec-design output) in the workspace
• a single-file HTML prototype (prototype-design output) or wireframe (wireframe-design output)
• Figma frames, provided as a Figma link

If either input doesn't exist yet, point the user at the right skill instead of auditing something that isn't there.

Ask for the synthesis doc's path and the prototype's location or Figma link if they're not obvious — there's no fixed convention for where either lives. If the workspace has more than one candidate for either, confirm rather than assume; an audit built on the wrong prototype version or a stale synthesis doc wastes everyone's time.

Read everything before comparing anything

Read the full synthesis doc first — not just the Insights → Opportunities table; the quotes and "why it matters" notes carry nuance a table row strips out. Then read the prototype in full: every screen, every component, the actual copy, the flows a user can walk through. How depends on what it is:

• React/Vite or Angular codebase — walk the routes or screen components, note what data and copy each screen actually shows, and pay attention to states: is there an empty state, an error state, or does the happy path stand alone?
• HTML — read the screen markup and any data objects directly. A hi-fi prototype carries real copy and data, so content claims are fair game; a wireframe also carries annotations worth reading, and if it was built in placeholder mode (bars instead of real copy) that limits what you can honestly claim about content later.
• Figma frames — use the Figma MCP to pull both the design context (layout structure, component usage, actual text content, and any variants, states, or annotation notes) and a screenshot of each frame, and read them together — the structured context tells you what exists and what things are named, the screenshot confirms what a user actually sees. Walk every frame in the flow, not just the one linked. If the Figma MCP is unavailable, ask for exported screenshots of every frame instead.