Reverse-Engineer the PRD From Any Figma Design

Designs and specs drift apart. Designers ship screens without specs and then face engineering asking "what is this supposed to do?" PMs review designs they didn't spec and need to verify the assumptions embedded in the frames. Engineers building from thin or outdated specs want structured confidence that their mental model matches the product intent before writing code. Founders shipping quickly need a forcing function to surface missing states and edge cases before launch. Reverse PRD bridges the gap by reading a design artifact — Figma frame, screenshot, or description — and writing the product spec it already implies: the user goal, user stories, success criteria, states covered, states missing, implicit assumptions about literacy, context, device, network, prior knowledge, attention budget, and permissions, and open spec questions. This gives each audience a usable first draft where they had nothing, or clarity on what's missing where they had uncertainty.

Point the reverse-PRD skill at a Figma design (URL, frame, screenshot, or description). The skill reads the design artifact, infers the user goal and stories from visible affordances, catalogs which states the design covers and which it misses, surfaces seven categories of implicit assumptions (literacy, context, device, network, prior knowledge, attention budget, permissions), and generates a PRD document that engineering can use as a spec starting point. The output is a structured Markdown brief covering user goal, stories, success criteria, state inventory, missing states, assumption risks, and open questions for spec.

Ship designs with clarity on what engineering is actually building before development starts. Surface missing states, edge cases, and risky assumptions in hours rather than discovering them broken in production. Converts ad-hoc design review into a repeatable, systematic spec-writing workflow that takes minutes and produces a document suitable for Linear, Jira, or Confluence.

The skill uses a locked opening pattern for consistency across invocations. It reads Figma directly via MCP when available (preferred for accuracy), falls back to screenshot analysis, or works from text descriptions with lower confidence. The core workflow is seven ordered phases: acknowledge/read design → infer user goal → extract user stories from affordances → catalog states against the states-checklist reference → surface assumptions against the inference-rubric reference → identify open questions → write the PRD using the prd-template.md. Key prompt structure: each phase has explicit quality bars (e.g., user stories must be grounded in visible design, not invented; states must be marked present/implied/missing with one-line explanation for missing states).

The input can be a Figma URL (preferred — allows MCP to inspect frames, states, copy, and components directly for highest confidence), a screenshot, or a text description. Screenshots are less precise than MCP reads but still surface likely gaps. Text descriptions are the weakest input but can still flag probable missing states. If context is insufficient, the skill asks one surgically specific clarifying question — never generic, always grounded in what it just read and informed by which gap would most change the brief. Examples: distinguishing admin-only versus member views when affordances are mixed; clarifying whether an empty state is first-run or cleared; confirming scope for multi-frame flows. The question is single-sentence, expects a single answer, and signals that the skill did its work before asking. The entire workflow — from pasting a URL to a usable PRD in the outputs folder — should complete in under three minutes, making it faster than chasing answers in Slack or email. Output is Markdown (pasteable into Linear, Confluence, Notion) plus a brief chat summary flagging the top three findings: biggest missing state, riskiest assumption, most critical open question.