Write the bug reporta developer can reproduce

A bug that can't be reproduced bounces straight back: “works on my machine, need steps”. Khint turns the rough notes from your test run into a structured report (environment, numbered repro, expected vs actual, severity) and files it to Jira or Linear, all from one keyboard shortcut.

For QA engineers and testers. Works in any app: your test-case tool, a scratch doc, your tracker.

A bug you can't reproduce
is a bug that comes back

You found it in ten minutes; the report takes twenty more. The developer needs the exact build, the precise sequence of clicks, what you expected versus what happened, and enough severity for triage to rank it. Skip a field and the ticket bounces (“can't repro”), and you re-test to answer the one question you already knew. Khint compresses the write-up with its three pillars (Agents, Capture, and Memory) behind one palette, so the report gets written where you found the bug.

Failed test to filed ticket

Logging a checkout regression during a test pass.

  1. Open a session for the test run

    Before you start testing, open a Memory session: call it “Regression: checkout v2”. Every Action you run is logged to it, and Khint keeps a compact running summary. That summary rides along on each report you draft, so the build number, the environment, and the bugs you have already logged stay in context as you work down the test plan. How Memory works →

  2. Grab the evidence you can't retype

    When a test fails, the proof is usually on screen: a console 500, a red toast, a broken layout. Open Capture from the palette: Extract text draws a region around a stack trace or error and drops the recognised text on your clipboard; Capture & askopens a short Vision chat about a screenshot you can't select. The evidence becomes text you can paste into the report instead of transcribing by hand. Capturing an error to a ticket →

  3. Shape rough notes into a reproducible report

    In Agents, save an Action like “Bug report”. No prompt yet? Type a description and press Generate. Khint drafts one that returns a symptom title, the environment, numbered steps to reproduce, expected vs actual, and a severity call. Or clone the Support Desk starter pack for a working report Action. Select your messy notes, hit Cmd+Shift+K, run it, and the structured report is pasted back in place: the version a developer can follow without a single follow-up question.

  4. Check it isn't already filed

    A flaky bug gets found by three testers in one afternoon and filed three times. With Atlassian connected, use the Jira Search and Active sprint rows to look for the same symptom before you open anything new. If it already exists, add your fresh repro as a comment instead of a duplicate. How integrations work →

  5. File it: Jira or Linear, one per run

    When the bug is genuinely new, the Jira Create issue row opens it in your project; on Linear the Create issue row does the same. One issue per run, so nothing is filed silently. Chain your report and Create issue steps into a single Workflow so one keystroke takes your rough notes all the way to a filed, reproducible ticket.

What a reproducible report carries

The fields your Action fills in: this is one example of a template you control.

Symptom titlewhat broke, where
EnvironmentOS, build, browser
Steps to reproducenumbered, deterministic
Expected vs actualthe gap, spelled out
Severity & priorityagainst your rubric
Evidencelog or screenshot text

Nothing here is baked into Khint: the fields above are just an example. The template lives entirely in the Action prompt you save, so a team that reports against a strict repro standard, a team that needs a regression-vs-new flag, and a team with a long compliance field each get the report they asked for. Start from the Support Desk starter pack on the Agents page and tighten it over time with Improve.

Why not just paste the bug into a chatbot?

You can, and for every bug in a regression pass you'll re-explain your report template, restate how your team ranks severity, and copy the result back into the tracker by hand. Khint removes the round-trips: the report Action is saved once and runs the same on every bug, Memorycarries the build and environment into each write-up automatically, and the Atlassian and Linear integrations file the ticket where engineering will actually see it. Because an Action only sees the text you select, plus the session summary you opted into, the details of an unreleased build aren't sitting in a chat history. Need to score the ticket itself against a bar first? See Jira ticket quality checks.

Common questions

How does Khint turn my test notes into a bug report?

You save an AI Action that contains the shape of a good report: title, environment, preconditions, numbered steps to reproduce, expected vs actual, and a severity call against your rubric. During a test run you jot the rough version: "clicked Save, spinner never stops, console 500, only on staging, 3/3". Select those notes, hit Cmd+Shift+K, run the Action, and Khint returns a clean, structured report the developer can actually follow. You stay wherever the notes already are: your test-case tool, a scratch doc, the tracker.

Is this the same as capturing an error message off the screen?

No, and they pair well. Capturing an error is a single move: OCR a stack trace or crash dialog straight into text; see capturing an error message to a ticket for that. Bug report writing is the step after: you have the raw evidence and your own repro notes, and the hard part is turning them into a report a developer can reproduce on the first read. A bug-report Action is tuned to structure and sharpen your findings, not to digitize one screenshot.

Does Khint decide the severity for me?

It runs the rubric you wrote. You save the priority bar your team agreed (how you weigh blast radius, data loss, whether a workaround exists, which tier is affected), and Khint applies it to the report text you selected. There is no hidden severity model inside Khint; the standard is the prompt you control, so two QA teams with different bars get different calls from the same shortcut. Tighten it over time with Improve.

Can Khint check for a duplicate before I file?

Yes. Once Atlassian is connected, the palette's Jira Active sprint and Search rows let you look for an existing ticket with the same symptom before you open a new one, so a flaky checkout bug doesn't get filed three times. When it is genuinely new, the Create issue row opens it in your project, one issue per run, so nothing is filed silently. If your team runs on Linear, the Create issue row does the same there.

Do I have to write the bug-report prompt myself?

No. In the Action editor, type a one-line description like "turn these test notes into a bug report with title, environment, numbered repro steps, expected vs actual, and severity" and press Generate. Khint drafts the prompt; press Improve later to tighten it in place. Khint also ships a Support Desk starter pack you can browse and clone from the Agents page, which gives you a working report Action to adapt to your own template.

Where does the bug detail go?

An Action only ever sees the text you selected, plus the compacted summary of your active Memory session if you opted in. Memory sessions live in a local SQLite database on your Mac and are never synced to Khint's servers, and your Jira or Linear credentials sit in your OS keychain. Nothing about an unreleased build or an internal defect leaves your device silently.

Write your next bug report in one shortcut

Free with 10 AI actions and 5 captures per day. No credit card. Save the report Action once, run it on every bug after.