Forty findings in a PDF,one labelled backlog out

An accessibility audit lands as a forty-page report from an agency: numbered findings, a criterion reference on each one, a severity, a screenshot. Khint reads the file itself, drafts a remediation ticket per finding, and files them into Jira one approved row at a time, with the label and the required fields already filled.

For product owners, business analysts and QA leads who own a remediation backlog. Works from the file, not from a copy paste.

Forty findings,
zero tickets

Nobody argues with the report. The cost is the transcription: opening the PDF beside the tracker, retyping each finding as a story a developer can act on, remembering the criterion reference so the retest can be traced, and filling the same four fields forty times. Khint starts from the file itself, drafts the ticket text with an agent, and lands it in the tracker through a connected integration so the finding never passes through your keyboard twice.

KhintPalette
Sprint 24
Workflows

The real palette running a saved workflow: the agent steps draft the text, then the last step writes it into the tool where the team works.

From the report to a labelled backlog

Working through a WCAG audit of a checkout flow, finding by finding.

  1. Point an agent at the audit file

    An agent can take a document as its input instead of a selection: pin the audit to the agent, or pick the file at each run from the palette. Khint extracts the text locally from a PDF, Word, PowerPoint or Excel file, and a long report is condensed once into a cached summary that is reused on every later run until the file changes, so re-reading the same audit costs nothing. See how document input works.

  2. Get the findings out as a working list

    Save an agent like “List the audit findings” that returns one line per finding: the criterion reference, the component, the severity the auditor gave it, and what a fix would have to change. No prompt written yet? Type the description and press Generate, and Khint drafts one you can refine in place. The list is the thing you triage from, before a single ticket exists.

  3. Let Super Khint propose one ticket per finding

    A report holds more findings than one write can carry. Point Super Khint at the same document and it proposes an action list: a Jira issue for this finding, another for that one, a Slack note to the design channel for the two that are really redesigns. Nothing is written until you press Run on that row, and a row missing its project or issue type asks you there before it fires.

  4. Pin the fields once so every ticket lands complete

    A remediation backlog is only useful if it is filterable. In a workflow, the Jira step takes its project, issue type, labels, priority, assignee and parent epic once in the editor, including the custom fields your project marks required, and replays them identically on every run at no extra model cost. Every ticket comes out carrying the same accessibility label and hanging under the same epic.

  5. Keep the trail back to the criterion

    Start a Memory session called after the audit and every run is logged to it, with the compact summary riding along on the next agent so the wording stays consistent from finding one to finding forty. Each write also leaves a row in your history with a link straight to the created issue, which is what you hand back when the auditor asks what was done with finding 12.

One finding, one shortcut, one ticket

Up to five steps in series, ending on the write that files the issue.

AgentRewrite finding as a storyAgentAdd acceptance criteriaJiraCreate issue

A workflow files one issue per run, which is exactly what you want for the long tail: the retest that fails again, the finding raised in review, the regression someone spots months later. The bulk pass at the end of an audit is the Super Khint route above, where the same findings arrive as a list of proposed writes you approve row by row. Both end in the same place, and both put the created issue key and its link back in front of you.

What Khint will not pretend to do

Khint reads the report, it does not audit your product: the findings come from your auditor or your own testing, and an agent that invents a criterion is worse than no agent. A scanned PDF with no text layer is refused with a clear message rather than returned empty, and for that case you can capture the page on screen instead and work from the extracted text. Every write is a deliberate one: the palette shows the drafted issue before it is created, a workflow makes exactly one write per run, and Super Khint waits on each row.

Common questions

How does Khint read a forty-page audit report?

You give an agent the file rather than a selection. Khint extracts the text on your machine from PDF, Word, PowerPoint, Excel and OpenDocument files, and because a long report would be expensive to send whole on every run, it is condensed once into a compact summary that is cached locally and reused until the file changes. Pin the audit to the agent so it always runs on that report, or pick the file each time from the palette. A scanned PDF with no text layer is reported as such instead of coming back empty, so you know to capture the pages on screen instead.

Can it file one ticket per finding, or only one at a time?

Both, and they are different tools. A saved workflow makes exactly one write per run, which suits the single finding you are dealing with today. For the whole report, Super Khint reads the same input and proposes an action list: one Jira issue per finding, plus anything else it thinks the input calls for. Each proposed action sits on its own row with its own Run button, so you approve the ones that are real tickets and ignore the rest. Nothing is written to Jira until you press Run on that row.

Will the tickets carry our accessibility label and required fields?

Yes. In a workflow, the Jira step holds its project, issue type, labels, priority, assignee and parent epic, including the custom fields your project marks as required, chosen once in the editor and replayed identically on every run without another model call. That is the point of pinning them: a remediation backlog you cannot filter by label or roll up under one epic is not much use at the next steering review. From the palette, Khint drafts the issue and asks for anything still required before it creates it.

Does the audit report leave my machine?

The extraction is local: opening the file, reading its text and caching the summary all happen on your device, and the cache never syncs. The text of what you ask an agent to work on is sent to the model to be processed, like any AI tool, and you can route that through your own API key if you prefer. Memory sessions and your action history, including the ticket links, live in a local database on your machine and are not synced to Khint's servers.

Is this only for accessibility audits?

The shape fits any third-party report that arrives as a document and has to become a backlog: a security review, a penetration test, a UX audit, a consultant's assessment. What changes is the agent prompt and the label you pin on the Jira step. Save one agent and one workflow per report type and each audit season starts from something that already works instead of from a blank prompt.

File the audit instead of retyping it

Free with 300 credits a month, about 10 AI actions a day. No credit card. Set the agent and the pinned Jira fields up once, then work through the report.