The ticket is written.Jira still says no
A good description is only half a Jira issue. The other half is the fields your project insists on: the required custom field that rejects the create, the priority nobody sets, the labels the board filters on. Khint reads your project’s own create screen first, so the issue lands complete instead of coming back as an error with no field name in it.
Rejected for a field
the error never names
Every mature Jira project grows a field policy: a mandatory Team or Component picker, a priority the triage rota depends on, labels the board is filtered by. Write the ticket somewhere else and you meet that policy as an HTTP 400 that lists an internal key and no explanation, or worse, as an issue that saves fine and then sits unassigned and unlabelled where nobody’s filter will ever show it. Khint asks your project what it wants before the write, not after, and pins the answers onto the workflow step through the Jira integration.
The real run panel: one workflow turns the selected notes into a Jira issue, a Confluence page and a Slack post, each row reporting what it created.
From rough note to a complete issue
Filing into a payments project that requires a Team field and triages on priority.
Connect Jira once, and let Khint read the project
Add your Atlassian credentials on the integrationspage and Khint reads the create screen of the project you file into: its real priorities, the people who can actually be assigned, the labels already in use, and any custom field marked required. Those are your project’s values, not a generic list, so nothing has to be guessed at write time.
Draft the ticket where the notes already are
Select the raw material wherever it lives, a stand-up note, a bug report pasted into Slack, a line in your inbox, and press Cmd+Shift+K. The Jira Create issue row drafts a summary and a description from the selection, so the writing and the filing are the same gesture. See how agents work.
Confirm the fields on the card, before anything is written
The draft comes back as one editable card with the fields already filled in: priority, assignee, labels, and any required custom field. Khint resolves the names the model chose onto the real ids behind them, so a priority reads as “High” and still saves. A required field left empty is flagged on the card while you can still fix it, instead of surfacing as a rejected write afterwards. Change the project or the issue type right there and nothing is redrafted.
Pin the fields once for a step that runs weekly
Filing the same kind of ticket every sprint is a workflow, not a decision. On a Jira create step you choose the assignee, priority, labels and parent epic once in the editor, picked from the same live project data, and every later run replays them identically at no credit cost. The editor warns you while a required field is still empty, because that step would otherwise fail on every single run.
Get the issue key back, or a readable reason
A successful write returns the issue key and a link straight to the ticket, and the run is logged to your Memory session and your history with that link on the row. If Jira does refuse the create, Khint turns its error payload into one readable line naming the field that caused it, which is the part the raw API response leaves out.
One shortcut, a complete ticket
Up to five steps in series, ending on the write.
The pinned values are what make this worth saving rather than repeating. A palette card is the right trade when you are watching: the model fills the fields and you confirm them. A workflow is the opposite situation, since the same step runs while you are in a meeting, so the fields are chosen once and replayed exactly. Add a second write, a Slack post or a Confluence page, and one selection updates every place the team looks.
What it will not do
The rules that keep a filled-in field from becoming a wrong one.
It never invents an id
Field values are resolved from the names your project actually publishes. A name that matches nothing is left empty and reported, rather than sent as a guess that Jira rejects.
An unreadable project is not a blocker
Reading the create screen is best effort. If it fails, Khint simply asks nothing extra and still files the ticket, so a slow Atlassian response never costs you the write.
Pinned means replayed, not re-decided
A pinned assignee or priority is stored on the step and reused verbatim on every run. It costs no credits and cannot drift, which is the point of pinning it.
One write per run, deliberate
Nothing reaches Jira until you run the row or the workflow. Labels are cleaned to a form Jira accepts, so a label typed with a space does not fail the create.
When you would rather approve each action
Some inputs are not one ticket. For a set of meeting notes that implies a ticket, a page and a message, Super Khint reads the notes and proposes the list of actions, filling the targets it can and asking in the row for the one thing it cannot know, including a project’s required custom field. Nothing is written until you press Run on that line, which is the same guarantee as the create card, applied to a whole batch. See how the approval step works.
Common questions
Why does creating a Jira issue fail with an error that names no field?
Because the project has a field marked required on its create screen and the request did not carry it. Jira answers with a 400 and an internal field key, which tells you very little if you were not the person who configured the screen. Khint avoids the situation by reading the project's create screen before drafting: the required fields come back with their allowed values, they are asked on the card or pinned on the workflow step, and the create goes out complete. If Jira still refuses, Khint reads its error payload and shows one readable line naming the field responsible.
Does Khint pick the assignee and priority itself?
On the palette create card, yes: the draft comes back with priority, assignee, labels and any required custom field already filled from your project's real values, and you confirm or change them before anything is written. On a saved workflow step it is the opposite by design. You choose those values once in the editor and every run replays them identically, because that step runs while nobody is watching and a field that changes per run is not something you can approve.
Can it set the epic and the labels too?
Yes. A create step can carry a parent key, so the issue lands under the right epic instead of loose in the backlog, and it can carry labels, which is usually what your board filters on. Labels are cleaned into a form Jira accepts before the write, so a label typed with a space does not turn into a failed create. Both are optional: a step that sets none of them behaves exactly like a plain create.
What happens if the field values come back wrong?
Khint resolves field values from the names your project publishes rather than asking a model for internal ids, since a model cannot know an id and will produce a plausible looking one. If a name matches nothing in your project, the field is left empty and that is reported to you, so you get a visible gap to fill rather than a rejected write or, worse, a ticket filed against the wrong value.
Does my ticket text leave my machine?
The selection you file is sent to the model that drafts the ticket, and the finished issue is sent to your own Jira instance using credentials stored in your operating system keychain. Khint holds no copy of your Jira data on its servers, the run history and Memory session bodies stay in a local database on your machine, and you can turn on PII redaction per agent so emails and phone numbers are replaced before the text is sent.
File the ticket Jira will accept
Free with 300 credits a month, about 10 AI actions a day. No credit card. Connect Jira, pin the fields once, and every ticket after lands complete.