Aider runs in your terminal. You paste text, it edits files, you review the diff. It has no window to drop a screenshot into and no pane to scrub a video. So the feedback you feed it has to survive as plain text with a single image reference. A cropped still plus three tight bullets does that better than a paragraph of prose or a five-minute recording.
The template below is small on purpose. You can copy it into a Cobalt Capture comment, publish, and hand Aider the markdown link. Every part maps to something Aider needs to act, and each part has a rule for when to change it.
The template
Write this as the comment on a captured, cropped screenshot:
Screen: [what the still shows and where it lives, e.g. the pricing card grid at /pricing]
Change:
- [the visible problem, stated as what is wrong right now]
- [the exact target: which element, which text, which spacing]
- [the expected result after the fix]
That is it. One screen line so Aider knows the context, then three bullets: what is wrong, what to touch, what right looks like. The pin numbers on the screenshot carry the coordinates, so your bullets stay short.
Why three bullets and not a paragraph
Aider parses instructions, not vibes. A paragraph mixes the symptom, the cause, and the fix into one run of sentences, and the agent has to untangle them. Three labeled bullets separate them for it. The first bullet is the symptom a human reviewer noticed. The second is the concrete target, which is where most feedback fails: "the button" is guesswork, "the Save button in the modal footer" is not. The third bullet is the acceptance test, so Aider knows when it is done.
How each part maps to Aider's workflow
The Screen line replaces the mental picture you would give a teammate over a call. Aider cannot see your browser, so name the route and the region. If your repo maps routes to files, add the file, but do not guess it. A wrong file path sends Aider editing the wrong component.
The Change bullets are the payload. Keep them in that order every time so you build a habit and so anyone reading the review link reads the same shape. When you publish, the markdown version of the review renders these bullets cleanly, which is the format an agent reads. You do not manually format anything; the export handles it.
The numbered pins on the still do the pointing. Instead of writing "the icon on the right side of the top nav, next to the search field," you drop pin 1 on it and write "pin 1: wrong icon." The screenshot carries the location, the bullet carries the intent. That split is the whole reason a cropped still beats an annotated live page for this job.
When to adjust the template
The three-bullet version fits a single, contained change: one element, one behavior. Adjust it in these cases.
More than one thing on the same screen
Do not stretch one comment to cover four problems. Capture the screen again for each distinct issue, or add numbered pins and write one bullet block per pin. Aider handles a list of small edits well; it handles a wall of mixed requests badly. If a screen has five issues, that is five items in the review, not one comment with five buried asks.
A change with no screenshot
Sometimes the ask is not visual at all: rename a label everywhere, change a default value. Cobalt Capture lets an item be a free-floating comment with no image. Drop the Screen line, keep the three bullets, and state the scope in the first bullet ("every instance of the label 'Sign up', app-wide").
A design change, not a bug
When you are requesting a look, not fixing a defect, the third bullet carries more weight. "Expected result" becomes a specification: exact spacing, the hex value, the font weight. Aider will match numbers it can read; it will not match "make it feel lighter." If you run these often, the pattern in running a design review on the built product pairs with this template.
The full loop, start to finish
Open a tab, click Capture screen, share the window, and drag a rectangle around the region that matters. Drop a pin or two. Type or dictate the Screen line and three bullets. Publish. You get a short public link and a markdown URL at /r/<slug>/markdown. Paste the markdown link into Aider and let it read the structured version, or read the bullets aloud to yourself first to check they are unambiguous.
No install, no extension, no signup to publish. An anonymous review sticks around for 30 days, and you can claim it later by signing in. That matters when you send a batch of change requests before you have decided whether to keep an account.
The same review serves a human reviewer too. If a teammate needs to sign off before Aider touches anything, they open the public link, read the same three bullets, and post a reply on the item. You mark it resolved when the diff lands. One artifact, two readers, and the structure that makes feedback actually get fixed stays identical for both.
Copy the template into your next review and send Aider one link instead of a paragraph it has to decode. Start a review and try it on the first UI change on your list.