You have a build in front of you and a list of things that look wrong. The button sits too low, the empty state shows a raw error, the spacing on the settings page is off by half. You could write all of that as a prose paragraph and paste it into Cursor, and Cursor would guess at half of it. Or you could hand it a numbered list where every item names the screen, the spot, and the change. Here is the order that gets you there without switching between five tools.
Step 1: Open a review tab and pull up the built screens
Open the running product in one browser tab and start a new review in another. No install, no extension, no signup. The review tab is where every note lands. Keep the product tab on the first screen you want to critique, for example the signed-out landing page or the dashboard after login.
The outcome of this step: you have two tabs open and a blank review waiting for its first item.
Step 2: Capture each screen as its own item
In the review tab, click Capture screen. The browser asks which window to share, and the current frame is drawn to a canvas. Drag a rectangle to crop down to the part that matters, or keep the full frame. Each capture becomes a separate item, so capture the signed-out header, the dashboard, and the settings page as three items rather than cramming them into one.
This is a still capture, not a recording. If you have been sending Loom walkthroughs, the difference matters for what comes next, and it is worth reading how a capture compares to a recording as agent input before you decide.
The outcome: one item per screen, each holding a cropped image of exactly what you are talking about.
Step 3: Say what is wrong on each item
Add a comment to each item. In Chrome or Edge you can dictate it with the browser's built-in speech recognition, which is faster than typing when you are looking at the screen and describing it out loud. On Firefox you type instead. Write the change, not a vague reaction. "Move the Save button above the fold on mobile" beats "the button feels buried."
When a screen has several problems in different spots, drop numbered pins on the screenshot so each pin points at one place. Pin 1 on the misaligned icon, pin 2 on the truncated label. That way your comment can say "pin 1: this icon is 4px too high" and Cursor knows which element you mean. See how pins mark the exact spot a reviewer means if you have a dense screen.
The outcome: every item now carries a concrete, actionable comment tied to a specific spot.
Step 4: Publish and get your two outputs
Click Publish. The review is saved and gets a short public URL at /r/<slug> that anyone with the link can read. That link is for the people on your team who want to see the screens and the comments in a browser. The second output is the one Cursor cares about: the same review is available as plain-text markdown at /r/<slug>/markdown.
You did not sign up to get here. If you want to keep the review past 30 days, sign in afterward to claim it, which you can read about in claiming an anonymous review after signing in.
The outcome: one review, two links. A readable page for people and a markdown file for the agent.
Step 5: Paste the markdown into Cursor as a task list
Open the markdown URL, copy it, and paste it into the Cursor chat as your task list. The export is structured: each item is a heading with its comment underneath, and the screenshots come through as image references. Cursor reads it as a set of discrete tasks instead of one wall of text, so it can work through them in order and check each off.
The full canonical walkthrough for this handoff, including how to phrase the request that goes with the paste, lives in the guide on getting feedback into Cursor. If your feedback keeps landing badly, the list of mistakes that make feedback land badly in Cursor covers the usual causes.
The outcome: Cursor has a clean, ordered list of changes, each tied to a screenshot and a specific spot on it.
What each teammate does with the same review
The reason this workflow scales past a solo build is that the one review serves everyone. The developer or the agent works from the markdown. A designer or a client reads the public link and can post a comment on any individual item, which you mark resolved as you go. You do not need a separate tracker for that; see how you can resolve review comments without a bug tracker.
If your review mixes audiences, split the outputs deliberately. One review can send a client link and a developer link at once, so the client sees the polished page and the agent gets the markdown.
Next time you finish walking a build, do not write the prose paragraph. Capture each screen, pin the spots, comment the changes, publish, and paste the markdown. The whole loop fits in a couple of browser tabs and costs nothing, which you can confirm on the pricing page.