A screenshot that says ‘this looks wrong’ is useful evidence, but it is not a complete implementation request. Turn it into a small, checkable job before an agent starts changing code.
Capture the state that produced the problem
For a broken settings Save button, record the page, viewport, signed-in state, steps, actual behavior, and intended behavior. Keep the screenshot with the project note or ticket, but describe the problem in text too: images may omit the URL, error message, or state needed to reproduce it. Redact private data before sharing the evidence with a CLI or teammate.
Choose a place to hold the idea
Canopy's current-main documentation describes notes for ideas, screenshots, attachments, reminders, and links. It also describes SpotSearch, where a typed request or pasted image can become a note, research run, or focused task. Use a note when the request is still vague. Use a ticket when others need priority and ownership. First check whether the same bug or decision already exists in search results, a branch, or a PR. These surfaces may differ in the installed release, so verify the actions in your build.
Investigate the unknown part first
Ask a research question if you do not know whether the button is a visual defect, a failed network request, or an existing product rule. Request a short finding with source files, relevant runtime evidence, confidence, and unresolved questions. Canopy's documented research jobs preserve findings and sources without changing code. Read those findings before deciding what to implement; a screenshot alone cannot tell you whether to patch CSS, validation, or the API.
Give one agent a bounded outcome
State the observable result: ‘Saving a valid profile shows success once and persists after reload; a failed request shows an error and leaves the form editable.’ Name the affected page and branch, link the evidence, and list checks. Ask the agent to inspect the relevant code before editing. If the task changes code, Canopy's documented custom-task route uses an isolated draft PR; keep the final decision with a person. For a CLI session, ensure the agent knows which checkout and branch it owns.
Test the behavior, then read the diff
Start the needed local service, reproduce the original problem, and test success and failure paths in Preview. Check the latest diff and PR for unrelated changes, secrets, and missing tests. A green build does not prove the screenshot's issue is fixed; compare the running result with the acceptance checks. If an agent missed one state, send that exact state back as a focused follow-up rather than restarting the whole request.
Copyable resources
Screenshot-to-task brief
Example fields for a UI defect; replace them with observed facts.
Problem: Settings > Profile Save remains in a spinner after a failed request.
Evidence: [screenshot link], [page/viewport], [steps], [console or network error if observed]
Expected: A valid save confirms once and persists after reload; a failed save shows an error and allows retry.
Investigate first: Which handler, API response, and existing tests control this state? Cite files and any uncertainty.
Change scope: Profile Save flow only; preserve current form fields and API contract.
Acceptance: Reproduce before fix, test success and failure, run relevant checks, inspect the final diff and preview.
Delivery: Branch or draft PR, changed files, checks with results, remaining risk.Frequently asked questions
Can I paste a screenshot and let the agent decide everything?
Use the screenshot as evidence, then add the page state, actual and expected behavior, and an acceptance check. Investigate uncertain causes before authorizing a code change.
Does a Canopy background task automatically merge the fix?
The current-main documentation describes code-changing custom tasks handing work through an isolated draft PR. Review the behavior and diff, and confirm your installed release's task flow before relying on it.