First, get connected
The first section walks through setting up Paper Desktop, connecting your agent through MCP, and sending a test prompt. An official screenshot and agent selector keep the setup instructions easy to follow.
Then, choose a use case
Five practical workflows cover creating a screen from scratch, exploring and reviewing alternatives, starting from a live webpage, using existing product styles, and bringing a design into code. Each includes a prompt and a check for the result.
Try a complete beginner example
The first use case includes filled-in sample content for an event signup screen. Try the prompt, inspect the editable frame, and adapt the content for your own project before exploring other workflows.
Use product context when it helps
The product-style and code-handoff use cases explain when to open an existing repository in the coding agent. Canvas basics and connection troubleshooting remain available alongside the main walkthrough.
Put the resource to work
1. Start with one concrete task
Bring: Paper Desktop and Claude Code, Cursor, or Codex. An existing project is needed only for the product-context and code-handoff use cases.
First task: Set up Paper, connect your agent, and test the connection. Then choose a use case and follow its prompt and result check.
Choose one component, screen, or team workflow to improve. Gather the existing decisions and write down the question you want this resource to help answer.
2. Open the source material
Open the original guide or presentation ↗
Use the original walkthrough alongside your project. Its existing access flow remains available on the original page.
3. Apply it with your project context
Use the starter request below with the relevant inputs attached or referenced. Confirm that the host loaded the intended skill; a matching name alone is not evidence that its instructions were applied.
4. Review the result
Confirm the agent sees the right Paper file and creates the test frame. After a use case, inspect the actual canvas or working prototype against the intended task.
Compare the output with the task’s acceptance criteria. Check factual claims, unsupported assumptions, and any changes to the interface. For code or design changes, review real states and behavior before treating the result as finished.
5. Keep what works
Save approved outputs with their source and ownership. Note which instructions helped, where the result needed correction, and what must be checked next time. Use the workflow below to connect this task to its next step.
A starter request
Adapt this example to your files, audience, and requirements.
Check your connection to Paper. Tell me which file you can access, then create a small frame labeled “Connection check.”
Completion checklist
- The inputs and intended result are explicit.
- Required files and tools are available in the chosen host.
- The result has been reviewed against the actual task.
- Limitations and follow-up checks are recorded.