Product feedback for Aider

Aider works against files in your repo. Drop a CobaltCapture .md export in the project and ask Aider to address each item.

This is the playbook for handing visual product feedback to an Aider session without retyping every finding into chat. For the same workflow against other tools, see the feedback for AI coding agents hub.

The problem with feedback in Aider workflows

Aider rewards discipline. You /add a small set of files to the session, Aider works against them, and you get clean commits with the diff scoped to what you asked for. The model is file-first, and that is the point.

Visual feedback breaks that model. Someone reviews staging, screenshots three issues, drops them in Slack with a sentence each. None of that is a file. So you end up describing each finding in the Aider chat. "The submit button overflows on mobile, the spacing on the pricing card is off, the empty state copy is wrong", and Aider has to guess which component each sentence refers to. The screenshots, if you reference them at all, sit in a Slack thread Aider cannot read.

The result: vague prompts, vague diffs, and a commit history that does not explain why the change happened. The fix is to turn the feedback into a file before the session starts.

The CobaltCapture workflow with Aider

Capture, narrate, publish. Open the staging URL. Open cobaltcapture.com and hit Capture screen. Drag a box around each broken component, hit Dictate, and talk through what's wrong. "The submit button overflows the container under 380px on iOS Safari, the parent should be flex-wrap not nowrap." Repeat for each finding. Hit Publish and you get a public review URL plus a one-click markdown export.

From your project root:

curl -fsSL https://cobaltcapture.com/r/<slug>/markdown > feedback.md

Now feedback.md is a file in your repo. It has H2 headings for each finding, embedded screenshot URLs, source URLs for the pages they came from, and your dictated commentary underneath. Start Aider, /add feedback.md along with the components you expect to touch, and reference it in your prompt. Aider works through the findings one by one and commits each fix with a message that points back to the spec.

Example prompt

$ aider src/components/SubmitButton.tsx src/components/PricingCard.tsx \
        src/components/EmptyState.tsx feedback.md

> Read feedback.md. For each finding, summarize what you understood in
> one sentence, propose the fix, then apply it and commit. Use the
> finding's H2 heading as the commit message subject. Pause for my
> confirmation between findings.

Aider walks the file top to bottom, produces one commit per finding, and your git log now reads like a changelog with the original review attached.

Why this works for Aider

Aider's model is file-first. Markdown in the repo is a first-class input, once it's /add-ed, it sits in context for the whole session and Aider can re-read it as work progresses. You do not have to repaste, and you do not have to keep a Slack thread open in another window.

Because the file lives in the repo, the markdown export gets committed alongside the work it produced. The commit that fixes finding three has a parent commit that added feedback.md, which means the spec for any change is one git blame away. That is the kind of provenance Aider's clean-commit workflow is designed for.

Dictation matters too. Aider prompts that read like "fix the button" produce shallow diffs. Prompts that read like "the submit button overflows the flex container under 380px on iOS Safari after the keyboard dismisses" produce real ones. Voice captures the "why" that one-line typed prompts skip, and Aider uses that context to scope the diff correctly.

Alternatives and tradeoffs

You could type each finding into the Aider chat directly. It works for one issue. By the third, you are retyping context Aider has already lost, and there is no record of the review after the session ends.

You could file Linear or Jira tickets first and have Aider read them via an MCP integration. That is overkill when the feedback is fresh and you want it fixed in the next thirty minutes, the time spent triaging into tickets is longer than the time to fix.

You could add raw image files to the Aider chat with /add screenshot.png. Aider's image handling is limited, the screenshots carry no source URL, and you lose the dictated commentary that explains what the picture is showing. For the underlying pattern, see agent feedback, the artifact has to be a file, and the file has to carry both pixels and prose.

Capture your first review.

About a minute from open tab to a shareable URL your agent can ingest.

Start capturing