Build a feedback brief
Replace the fictional example with your own observation. Entries stay on this page.
Your draft
# Visual feedback brief ## Target /settings/team · invitation form · 390px wide · invalid email ## Observed problem The error message pushes the Invite button outside the panel. ## Expected outcome The error wraps and the Invite button remains reachable. ## Preserve and reuse Reuse the existing field, error, and spacing patterns. Preserve validation and submission behavior. ## Verify Submit an invalid email at 390px, correct it, and complete an invitation. Check the desktop layout too. Review this draft and confirm the accepted scope before implementation.
Review the scope before sharing. This builder does not submit feedback or connect an agent.
The short answer
A useful visual feedback brief identifies the target, observed problem, expected outcome, constraints, and verification steps. Fill in the fields below to create a Markdown draft, then review the scope and evidence before sharing it or handing an accepted correction to a coding agent.
1. Identify the target and reproduction context
Name the screen, element, and state. Include the viewport or interaction when it changes what someone needs to reproduce. A route and a specific control are more useful than a reference to “the thing on the right,” which may move at another width.
The prefilled example is fictional starter content. Replace it with your own observation and remove private information before sharing. A screenshot or selected-element reference can support the brief, but this tool does not capture either automatically.
2. Describe the observed problem and intended outcome
Write what happened before proposing a solution. Explain why it affects the task, then state a result that the reviewer can observe. Keep an unresolved product decision separate from an accepted correction so the implementer knows when clarification is needed.
Use one independently reviewable change per brief. If the observation contains unrelated layout, permissions, and copy requests, separate them before implementation. A shorter accepted task usually makes the scope easier to understand, but it still needs enough context to fix the actual issue.
3. Add constraints and verification steps
Name existing components, tokens, or approved references that should be reused. State important behavior and content that must remain intact. Do not include access tokens, private account credentials, or unrelated repository instructions in a reusable feedback note.
Define the steps that would establish success. Include the original reproduction state and any nearby check justified by the expected impact. A shared-component correction may need representative consumers, while an isolated label change may need only a focused review.
- Identify the current build or version when available.
- Keep observed evidence distinct from the proposed solution.
- Specify what should remain intact.
- Make the expected outcome observable in the verification steps.
4. Review the draft before sharing
Read the generated brief as someone who has not seen the screen. Check that the target is discoverable, the request is decided, and the scope is realistic. Add links or evidence through the approved project channel when they are needed to explain the task.
The builder produces a draft you can copy. It does not submit feedback, approve a change, connect an agent, or create a CRRT project. Use the product’s supported workflow to capture visual context and hand off accepted work when appropriate.
Your entries stay in the current browser page; the builder does not store them in an account or send them to CRRT. Copy the output somewhere you control before leaving if you need to keep it. After implementation, repeat the verification steps and record the actual result.
Common questions
Does this builder send feedback to CRRT?
No. It creates a draft on this page. Review and copy it, then use your project’s chosen feedback or handoff workflow.
Can the draft replace the screenshot and element context?
It can describe a task, but some visual issues need supporting evidence. Add the appropriate screenshot, element reference, state, or reproduction details when sharing the accepted request.
Sources & further reading
- CRRT: agent handoff and review responsibilities
- CRRT: capture visual feedback on a supported surface
Written with AI assistance. Tool references checked against the linked documentation on November 2, 2026. Examples are starter templates to adapt and review in your own project.