The short answer
Scope one visual fix by naming the accepted outcome, affected element, implementation boundaries, and checks that will establish success. Give the agent access to the relevant project context, then require it to report what changed and what remains unverified.
1. Confirm that the requested outcome is approved
Read the visual comment and separate its observation from its proposed solution. Confirm which outcome the reviewer actually accepted. A comment asking whether the button should move is still a question until someone owns the decision.
Identify the target route, element, viewport, and state. Link the screenshot or design reference when available. If important context is missing, resolve that ambiguity before an agent starts editing. A precise implementation brief cannot compensate for an undecided product requirement.
2. Define the smallest useful boundary
Describe the behavior and content that must remain intact. A spacing correction on an invitation form should not silently alter the permission model, redesign navigation, or rewrite unrelated copy. Point to the existing component and tokens when those already express the desired rule.
Ask the agent to inspect the implementation before deciding whether the issue is local or shared. A local override might be the cause, but the same symptom can originate in a shared component. If the appropriate fix expands the scope, have the agent explain the affected consumers before proceeding with a wider change.
Accepted outcome: the invitation error stays beside its field
Target: /settings/team, invite form, invalid-email state
Reference: [selected element, screenshot, and approved example]
Reuse: existing form field and error-message pattern
Preserve: validation, submission, labels, and permission checks
Boundary: fix this issue; report shared consumers before widening scope
Verify: invalid email, correction, successful submission, narrow width
Return: changed files, checks performed, and any unverified behavior3. Supply the context needed to implement
Include the relevant project instructions, component documentation, and approved design decisions. Give enough context to locate the source without pasting a large archive of unrelated material. Use fictional examples when private customer content is unnecessary to reproduce the problem.
Use the project’s supported handoff method. CRRT’s agent documentation describes scoped access and review boundaries; follow those instructions for the actual connection. Do not place access tokens in public URLs or in a reusable task template. A guide about handoff is not a reason to broaden repository or account permissions.
4. Review the result before expanding the task
Ask for a short description of the implementation and evidence tied to each requested check. “Tests passed” is incomplete if the request depended on a narrow layout that was never opened. Distinguish automated checks, manual inspection, and behavior that remains untested.
Repeat the original state and review nearby consumers if shared code changed. Keep newly discovered issues separate unless they are necessary to complete this fix. A person should decide whether the change meets the accepted outcome and is ready to merge; an agent’s completion status does not make that decision.
- Confirm the change matches the accepted request.
- Inspect shared-component impact when applicable.
- Record the original issue’s verification result.
- Assign a follow-up owner for anything deliberately left unresolved.
Common questions
Should I prescribe the exact code change?
Provide verified constraints and references. Let the agent inspect the source before choosing an implementation unless there is a specific, approved technical requirement.
What if the smallest correct fix affects several screens?
Make that impact explicit, agree on the expanded boundary, and review representative consumers. A small task should still fix the actual cause.
Sources & further reading
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.