Product feedback for Claude Code

This is the playbook for getting visual product feedback into a Claude Code session without losing context. For other coding agents, see the full feedback for AI coding agents hub.

The problem with feedback in Claude Code workflows

Claude Code is great at reading files in your repo and making structured changes across them. It struggles when feedback lives outside the repo. The usual flow: someone reviews the staging build, screenshots a few issues, drops them in Slack with a paragraph each. By the time you sit down with Claude Code, the screenshots are buried in scrollback, the context is fragmented across three threads, and the only way to "give Claude Code the feedback" is to paste each screenshot into your terminal prompt one at a time. Half the visual context gets lost in the copy-paste, and Claude Code starts guessing which component a finding refers to.

The cleanest fix is to put the feedback into a file in the repo. Once it's a file, it behaves like any other source in your project.

The CobaltCapture workflow with Claude Code

Capture and publish a review at cobaltcapture.com. You get a public URL and a markdown export. From your project root:

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

Now feedback.md lives in your repo. It contains H2 headings for each finding, embedded screenshot URLs that render in any markdown viewer, source URLs for the pages the screenshots came from, and your dictated commentary as paragraphs underneath.

Open a Claude Code session and prompt:

Read feedback.md and address items 1, 2, and 3 in order. For each
item, summarize what you understood, propose the fix, then apply it
and run the tests. Pause for confirmation between items.

Claude Code reads the file as a first-class repo artifact, follows the embedded image URLs when it needs visual context, and works through the findings in order.

Why this works for Claude Code

Claude Code's strength is file-aware, multi-step work in a project. Markdown in a repo is the input format that strength is built for. A feedback.md at the root is also discoverable across sessions, the next time you open Claude Code, you can reference it without re-paste. And because the file is part of your project, it survives session compaction in a way that pasted context does not.

The dictated commentary matters too. Claude Code prompts that read like "the button is broken" produce shallow fixes. Prompts that read like "the submit button overflows the container on viewport widths under 380px, only on iOS Safari, after the keyboard has dismissed" produce real ones. Dictation captures that voice without the friction of typing it.

Alternatives and tradeoffs

You could paste screenshots into Claude Code directly. The CLI does accept images and the model does process them, but you lose source URLs, you lose any chance of a re-readable record, and the screenshots are session-bound, gone when the session ends.

You could keep the feedback in a tool like Linear and ask Claude Code to read it via an MCP integration. That works when the feedback has already been triaged into tickets. It does not work for the "I just walked through staging and found six things" stage, which is where CobaltCapture lives.

You could write the markdown by hand. It is slower than dictating it. The point of CobaltCapture is that the artifact is structured the same way regardless of who reviewed, which means the same prompt pattern works across reviewers and against the agent-feedback workflow consistently.