Fix a Small Bug with Cue Voice and Claude Code

Choose your input route

Use Cue when the bug explanation starts in another app. You might be reproducing a problem in a browser, reading an issue, or collecting a teammate's notes. Dictate the symptom into a scratch note while it is fresh, then check the wording and carry one reusable brief into Claude Code. This is useful for gathering context across apps before the coding task begins.

Stay in Claude Code when your project and request are already ready. For a short correction in an existing session, type or paste it directly. Claude Code also has native voice input: its official voice dictation guide documents /voice for the CLI, requiring a Claude.ai account and a local microphone. Check its environment and account requirements. Cue is optional here; adding a scratch note only helps if you need to collect, edit or reuse the brief.

Cue Dictation into an external app

This is the route used below. Cue inserts text into the focused scratch note or supported prompt field. You check and send that text; Claude Code does the coding in its own environment. No Cue connector is needed, and the note does not automatically transfer the other app's history, files or permissions.

Claude connector inside Cue

This is a separate route for using an external Agent from Cue. Check the connection, sign-in, selected project and permissions before sending work. Confirm that route's account and billing; a visible Claude option alone does not show that it is ready. Follow the controls actually available in your installed version.

Cue Agent with a hosted model

You can ask Cue Agent to turn the supplied symptom into a draft brief, then review it before handoff. Selecting an Anthropic model for Cue Agent does not start Claude Code or give it repository access. Hosted model access and billing follow your Cue account; they are separate from the external Agent connection.

Try the zero-count exercise using Dictation followed by an explicit text handoff. Start by saying the symptom, verify zero, null and undefined in the note, then give Claude Code sources F-01 through F-03. The exercise is complete when you have the original failing assertion, the scoped patch and the same test passing in your own run.

Start with one change you can verify

This guide goes beyond writing a bug-report brief: it explains what to do once a coding Agent has the report. Keep the first task small enough that you can state the wrong result, the expected result and the conditions under which both occur. Do not combine a bug fix with a redesign, a dependency upgrade or a release.

1. Open the affected screen and a scratch note. Use only information you are authorized to share. Focus the note's input field, use the Dictation shortcut shown in Cue Settings, confirm recording, and describe the symptom. Stop using the configured control, wait for processing, then check the text appears once.
2. Correct names, numbers and negations before sending. Dictation captures your words; it does not grant permission to edit a repository. If you ask Cue Agent to structure the report, request a draft and explicitly supply the relevant note when app context is missing.
3. Open Claude Code in the intended project. Confirm the working directory, branch and existing changes. Paste the reviewed brief, or dictate a short follow-up into the focused prompt field. Do not dictate shell commands directly into a terminal prompt.
4. Ask Claude Code to inspect the relevant implementation and tests before proposing a change. If it cannot reproduce the failure, give it the missing input or environment detail, not permission to guess a patch.

This tutorial uses an explicit text handoff. Cue's optional external-Agent selector requires its own connection, authentication and permission checks; a visible Claude option is not proof of a working connector. Selecting an Anthropic model for Cue's own Agent is also not the same as running Claude Code. Check the Agent and model distinctions before choosing a route. An existing conversation in another tool does not automatically travel with your note.

Practice: preserve a zero count in a result label

The following fictional JavaScript exercise is intentionally small. The task is to fix a label function, not to modify Cue or an application you use for work. Create these files only in a new disposable folder. Node.js is needed to run the test. The code examples are ordinary JavaScript, not Cue commands.

Source F-01 — intended behavior: Inputs in this exercise are limited to non-negative integers and the missing values null or undefined. Zero is a real count and must display 0 results; positive integer counts keep their existing number-plus-results wording. Missing values must display No count. Input validation, singular wording, and the behavior of other input types or values are outside scope; this exercise does not define validation rules for them.

Source F-02 — starting implementation, result-label.mjs:

export function resultLabel(count) {
  return count ? `${count} results` : 'No count';
}

Source F-03 — current observation: Calling resultLabel(0) returns No count. This follows from the supplied code; it is not a recorded Cue or Claude Code run. The exercise does not establish what causes a different bug in your project.

Try saying into your scratch note: “Zero results is a real count, not a missing count. Use F-01 through F-03. Fix only this distinction, keep null and undefined missing, and show a test that catches the original bug. Do not publish anything.” Check that the transcribed note still says zero, null and undefined correctly.

The point of using voice here is to capture intent while the problem is fresh. Copy identifiers from the code when spelling matters. You do not need to speak every punctuation mark or read an entire file aloud.

Ask for a failing regression, then a minimal patch

Ask Claude Code to add result-label.test.mjs with a public-behavior check such as this one. In a real project, use its existing test runner instead of imposing this example's setup.

import assert from 'node:assert/strict';
import test from 'node:test';
import { resultLabel } from './result-label.mjs';

test('zero is a count; only null or undefined is missing', () => {
  assert.equal(resultLabel(0), '0 results');
  assert.equal(resultLabel(null), 'No count');
  assert.equal(resultLabel(undefined), 'No count');
  assert.equal(resultLabel(3), '3 results');
});

Run node --test result-label.test.mjs. Against F-02, the zero assertion should fail. A missing Node installation, an import error or a test that never executes is not the expected regression failure. Save the actual output before changing the implementation.

A candidate replacement for the function is:

export function resultLabel(count) {
  return count === null || count === undefined ? 'No count' : `${count} results`;
}

Apply that candidate only in the disposable exercise. Rerun the test and inspect the changed function. A green result covers these four inputs; it does not prove every possible input is valid or that an unrelated application is safe to deploy.

For a real fix, ask for the failing check first, authorize the bounded implementation, then require the same check to pass plus the nearby existing tests. Anthropic's official best practices emphasize verifiable work and separating exploration from implementation. Our exercise applies that idea to a voice-originated task; the documentation does not verify a Cue integration.

Copy a voice-to-fix acceptance brief

Replace the bracketed fields before sending. Keep sources below the task instruction so quoted material is not mistaken for permission to run commands.

Task: Fix the single behavior described below in this repository.
Working location: [confirmed project and branch]
Source: [reviewed symptom, input, expected output, actual output]
Scope: [one behavior and affected area]
Preserve: [existing work and behavior that must not change]
First inspect the current diff and locate the real call path.
Reproduce the bug with a test through the public interface.
Show that it fails because of this bug, not a setup error.
After I approve the scope, make the smallest relevant change.
Rerun that test and the applicable nearby checks.
Evidence: actual commands, exit results, relevant output and scoped diff.
If blocked, state the missing fact; do not weaken assertions to pass.
Do not commit, push, deploy, change credentials or edit unrelated files.
Return remaining risks and a short handoff. Stop for release approval.

Decide whether the fix is ready to hand off

• Reproduction: the original zero-count check failed for the right reason. If the Agent reports “cannot reproduce,” the task remains an investigation.
• Scope: the patch distinguishes missing from zero without adding unrelated formatting, validation or dependencies. Review every changed file, including changes made before the task.
• Evidence: ask for the command actually executed and its output. “Tests should pass” is not a run. If an environment limitation prevented a check, keep that limitation in the handoff.
• Product result: a function test does not prove the UI uses that function. In a real app, repeat the user's visible scenario after the unit or integration check passes.
• Release state: record local modification, commit, push and deployment separately. Keep production unchanged until a person authorizes the next step and the repository's release checks pass.

An illustrative handoff for this exercise is: “The proposed change separates zero from missing. Expected coverage: zero, null, undefined and three. Actual test status: fill in from this run. Other inputs and UI integration: not covered.” Do not replace that last uncertainty with a confident success statement.

Recover without hiding the failure

For a second perspective on the patch, continue with a bounded Codex code review. For background that arrived in a recording, first build a source-linked context packet.

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.