AI Wireframing Prompts and Review Recipes

Specify the audience, screen dimensions, required controls, coordinate region, spacing, and what must stay unchanged. Mockup controls illustrate a flow; they do not implement authentication, persistence, or backend behavior. Use synthetic names and records.

For Replace document: "Create a low-fidelity 390 by 844 sign-in layout in the upper-left page region. Use text, two input controls, and a button. Keep 24-pixel side margins and 16-pixel gaps. Use email and password labels, with one primary Continue action. Do not add images or business logic." Review the login example before requesting extra screens.

For Modify draft: "Find the settings screen's Save button. Preserve its ID, text, color, and size; move it 16 pixels down. Leave other screens untouched." Stable IDs make the change easier to inspect and avoid replacing an object merely to move it.

For a dashboard: "Inspect the three summary cards on the analytics screen. Align their left edges to the sidebar boundary and use equal vertical gaps. Preserve labels and chart data." Ask for one region at a time when the document is large. The context guide explains the inspection and output limits.

Start with the generated element reference from Help > Download Syntax Ref, or use the MCP tools. Ask the assistant to inspect each required type, emit a document with an elements array, preserve existing IDs, and validate before presenting the result.

Do not ask for arbitrary CSS properties. A button uses textColor, not color; an input's displayed mock value uses text; frame and user-group support children, but cards and windows do not. Top-level positions use workspace coordinates; nested children use container-local coordinates. pageId alone does not translate an object. Paste bare document YAML into the YAML workspace at /editor. Use a complete .rvv envelope for File > Import File.

External chat prompt: "Use the attached vinyasa-document-reference.md. Return bare YAML with schemaVersion: 1, elements, pages and settings, explicit page/element IDs, and supported properties only. Build a 390 by 844 sign-in page starting at workspace (50, 50). Use a column frame at (74, 74) with 16-pixel padding/gaps. Do not invent CSS or application logic. Preserve existing IDs when modifying my source."

MCP agent prompt: "Connect to /mcp using Streamable HTTP. Read vinyasa://reference, list types, and inspect frame/input/button schemas. Validate my source, retain normalized IDs, then propose only the requested change. Return document YAML for review, or call export_project for a .rvv envelope. Do not claim to access or apply changes to my open Studio." The MCP guide contains actual client configuration and tool-call structures.

Before Apply proposal, check additions/removals, IDs, labels, coordinates, dimensions, and page links. Confirm that a small request did not replace unrelated content. The proposal summary counts top-level changes; inspect the diff for nested group changes. If output is unsuitable, Discard it and narrow the next request.

After applying, refine visually and export a backup. A prototype is evidence for a design discussion, not proof of accessibility, responsive behavior, or production readiness. Explore Kanban examples and tool comparisons to choose the appropriate next-stage tool.