Learn Cue · task-based tutorial

Turn a Spoken Bug Report into a Coding Agent Brief

Describe the problem where you see it. Capture the visible symptom with Cue, then give a coding Agent enough context to reproduce and check a fix without guessing at the cause.

By the Cue product team · Updated . Written from product-source review. Exercises and outputs are illustrative, not recorded Cue runs. Follow the controls shown in your installed version.

How do you give a coding Agent a useful spoken bug report?

Describe the problem with Cue while the affected app is visible. Turn the description into steps to reproduce, expected and observed behavior, known conditions and acceptance checks. Review the brief, then transfer it explicitly to your configured Claude Code or Codex task in the correct repository.

Need: a concrete symptom and starting state; a configured coding tool is needed only for the later handoff. Result: a reproducible report and bounded task, not an assumed root cause or an already verified fix.

Capture what you can actually observe

“The layout is broken” leaves the next person to reconstruct your situation. A useful voice report preserves the page, the action, the visible result and the conditions. Cue lets you start that explanation while the relevant app is in front of you; the useful output is a reproducible brief, not a confident guess about the code.

  1. Keep the affected page or app state visible. Write down the URL or screen name, app version, operating system and browser when known. Mark unavailable details as unknown rather than borrowing them from a previous report.
  2. If you want your spoken words inserted into an issue draft, focus its text field and use Cue Dictation. If you want a structured report, use Cue Agent and explicitly identify the relevant screen or supply a short description.
  3. Record the steps in order, including the starting state. Distinguish “I saw this once” from “I reproduced it three times.” Note the comparison that worked, if you actually checked one.
  4. Ask for a draft report. Do not authorize repository edits until the target project, evidence and scope are clear.

Visible screen context does not include hidden browser logs, source code or every tab. If a screenshot is useful, capture the real state, remove private information and attach it deliberately. Do not claim that an attachment exists until you can see it in the task. This tutorial has no product screenshots or recorded test run.

Practice: describe a distorted preview without guessing the cause

This fictional report concerns a disposable example website, not a claim about the current Cue website. Its sizes and reproduction count are practice facts; they have not been measured in a browser for this example.

Source B-01: On the example site's video preview page, the supplied image is 1600 by 900 pixels. At a viewport width of 390 pixels, opening the preview makes the image look tall and stretched. At 1280 pixels wide, the same image looks proportional. The exercise report says the narrow-view behavior occurred on three tries. Browser version, operating system and affected code path are unknown. The requested fix is visual only; text and download behavior must remain unchanged.

Supply B-01 and ask Cue:

Turn B-01 into a bug-report draft with Summary, Environment, Reproduction steps, Expected result, Observed result, Unknowns and Acceptance checks. Keep observations separate from possible causes. Do not invent a CSS selector, file path, screenshot, root cause or test result. Include the 390-pixel and 1280-pixel cases. Scope the work to the preview's aspect ratio and overflow. Draft only; do not submit an issue or edit code.

Illustrative brief, not a recorded Cue result:

Summary: Video preview appears vertically stretched at a 390-pixel viewport.
Environment: Example site; browser version and operating system unknown.
Steps: open the preview page, set the viewport width to 390 pixels, display the supplied 1600 × 900 image, and inspect its proportions. Repeat at 1280 pixels.
Expected: the preview preserves the image's 16:9 proportions without page-level horizontal overflow at both widths.
Observed in B-01: stretched at 390 pixels on three reported tries; proportional at 1280 pixels.
Unknown: relevant component, CSS rules and root cause.
Scope: visual preview only; keep text, pricing and download behavior unchanged.
Acceptance checks: at 390 pixels the rendered preview keeps the source 16:9 ratio within one percent, and the page reports no horizontal overflow; at 1280 pixels both remain true; the download link, price text and preview caption are byte-identical to before the change; a browser check covering both widths fails before the fix and passes after it.

A 1600 × 900 source has a width-to-height ratio of 16:9. That arithmetic is a useful check, not evidence of the rendered dimensions. Ask the coding Agent to inspect the actual image and layout before choosing a fix. “Probably a flexbox issue” belongs under a hypothesis only if there is evidence for it, not in the confirmed cause.

Proofread the steps and the acceptance checks before you hand them over

A spoken report reads fluently even when it is wrong. The parts most likely to be damaged in transit are exactly the parts a coding Agent depends on: the order of the steps, the numbers, and the difference between what you saw and what you concluded. Read the draft back against the source before it becomes someone else's task. This takes a minute and removes most of the back-and-forth that follows a vague report.

Reproduction steps

  • One action per step, in the order performed. “Open the preview page at 390 pixels and check the image” is two steps that hide which one failed. Split them.
  • The starting state is named. Signed in or out, which account type, which page, what was already open. A reproduction that only works from your particular starting point is not reproducible.
  • Exact values, not adjectives. 390 pixels, not “a narrow window.” 1600 × 900, not “a large image.” Three tries, not “usually.” Check every number against the source, because a dictated number is the easiest thing to lose.
  • Unknown stays unknown. If the browser version was not recorded, the draft must say unknown rather than borrow the version from your last report. Read the draft specifically for facts that appeared without a source.
  • Someone else can follow it. Read the steps as though you have never seen the bug. Anything you would have to ask about is a missing step.

Acceptance checks

  • Observable by a person who was not there. “The preview looks right” is not a check. “The rendered preview keeps the 16:9 source ratio and the page reports no horizontal overflow at 390 and 1280 pixels” is.
  • Tied to the reported symptom. Each check should fail today for the reason you reported. A check that already passes proves nothing about this defect.
  • At least one negative check. State what must not change — the download link, the price text, the caption. Scope damage is the common failure mode of a small fix, and it is invisible unless you asked for it to be checked.
  • Name what counts as evidence. The actual output of a check that ran, the changed files, the compared screenshots. A sentence saying the fix works is not evidence, and neither is a passing test of an unrelated component.
  • Do not relax a check to obtain a green result. If a check cannot be met, that is information about the fix, not a reason to rewrite the requirement.

Two versions of the same B-01 step, so the difference is concrete. Weak: “I made the window small and the preview looked stretched, probably a flexbox problem.” That merges the viewport, the action and a guess about the cause, and it gives the Agent a hypothesis to confirm rather than a defect to reproduce. Checked: “Set the viewport to 390 pixels. Open the preview page. Display the supplied 1600 × 900 image. Observed: the image is taller than its 16:9 source ratio. Repeated three times. Cause unknown.” The second version can be reproduced and disproved; the first cannot.

If you dictated the report, read the inserted text itself rather than trusting your memory of what you said — transposed digits and a dropped “not” both survive a fluent sentence. Identifiers and version numbers deserve a character-by-character check against the source rather than against what you meant to say.

Hand the brief to Claude Code or Codex explicitly

The simplest route is a reviewed text handoff. Open your already configured Claude Code or Codex task in the intended repository and paste the report, or dictate a short follow-up into its prompt field. This is voice input into another tool, not proof of a native integration or shared conversation.

Route What you actually do What it establishes What it does not establish
Dictate into the other tool's own field Focus the Claude Code or Codex prompt field, use your Cue Dictation control, then read the inserted text before submitting. Your words reached that tool's input. Fastest route for a short follow-up. That the text was reviewed. Speech arrives unproofread, which is the worst state for identifiers and numbers.
Paste a brief you have already checked Draft with Cue, proofread it as above, copy it, then paste it into the intended Claude Code or Codex task. The receiving task got exactly the text you approved. This is the route the exercise uses. Any connection between Cue and that tool. It is a manual transfer you performed.
An external Agent configured in Cue Select the configured external Agent in Cue and check its setup, sign-in and permissions first. Only what your own configuration and that provider's account actually allow. Seeing Claude, Codex or Gemini listed is not proof of a connection, authorization, available model or a completed run. Billing and availability follow the configured route, not the list.

This exercise uses the manual text handoff above; it does not require or demonstrate a configured external-Agent connector. If you instead use an external Agent from Cue's Agent selector, check that connector's setup, sign-in and permissions first. Selecting a model for Cue's own Agent is different from selecting the Claude Code or Codex runtime. Availability and billing depend on the configured route. Consult the guide to Agents, models and context before assuming these routes are interchangeable.

Task: investigate the attached B-01 report in the selected website repository.
First: inspect the current changes and preserve unrelated work. Locate the real preview implementation. Reproduce the symptom and state what is still unknown.
Then, if authorized: add a browser regression check for image proportions and overflow at 390 and 1280 pixels, confirm it fails for the observed defect, and make the smallest relevant fix.
Boundary: do not change text, pricing, downloads, production settings or unrelated components. Do not commit, submit an issue or deploy unless separately authorized.
Return: the scoped diff, the commands actually run, their results and any remaining uncertainty.

A different Agent does not automatically receive the previous task's history, files or permissions. Include the brief and the specific source or screenshot you are authorized to share. Repository files should come from the selected project, not guessed paths in a voice prompt. Credentials, session tokens and unrelated customer records do not belong in a reproduction.

Anthropic's Claude Code best practices recommend giving the Agent ways to check its work. Here, the concrete acceptance checks are more useful than asking it to “make the page better.” That guidance does not prove a Cue connector is installed or that this exercise has been executed.

Review the fix, not only the explanation

  • Before: did the Agent reproduce the reported behavior in the correct project? If not, it should return what it tried and ask for the missing environment information.
  • Diff and tests: inspect the changed files and the actual test output. A suggested command is not a command that ran; a green test of an unrelated component is not a regression check.
  • Visual result: compare the real preview at both widths. Verify that it preserves the source aspect ratio and does not produce page-level horizontal scrolling. Check the image itself, not only its outer card.
  • Scope: confirm no unrelated copy, price or download behavior changed. If the patch touches a shared layout rule, check its other consumers too.
  • Release: distinguish local edits, committed code, a merged change and a deployed page. After an authorized deployment, verify the same scenario on the public page.

For the writing exercise, success means the report is reproducible and honest about its unknowns. Completing the actual fix requires the separate repository and browser checks above. Do not publish the illustrative report as a real customer incident.

When the Agent cannot finish safely

The Agent cannot reproduce the bug

Add one missing fact at a time: exact page, viewport, browser version, starting state or a redacted real screenshot. Ask what it tested. Do not relax the acceptance criteria just to obtain a green result.

The proposed fix changes unrelated behavior

Pause the work and point to the scope boundary. Ask for a smaller patch or an explanation of the dependency. Review the current diff before any further action; stopping a task is not an undo operation.

A retry might repeat a partial action

Inspect the repository, issue draft or deployment status first. Continue only the unfinished portion. A new task should receive a short checked status summary rather than an instruction to repeat everything blindly.

To supply richer background, first turn your meeting notes into source-linked actions, then attach only the decision and constraints relevant to this bug. If the report starts from text already on your screen, check what the Agent actually received before you trust the draft.

Try it with Cue

Use your configured shortcut and verify the active mode in Cue Settings. Available app context and actions depend on permissions, version and account. Read the privacy policy before providing confidential material; this guide does not promise all processing stays on your device.

Get Cue for your computer · Current plans

Need help or found an error? Contact Cue support or email eli@sophoninc.com. Include your Cue version, platform, mode and a redacted example. Do not send passwords, tokens or private meeting material.