Closed tickets,release notes users can read
The work shipped, but the release notes are still a blank page. Khint pulls the closed tickets from Jira, rewrites the terse internal lines into clean user-facing notes with a reusable AI action, and publishes the page to Confluence, all from one keyboard shortcut.
The tickets are closed,
the release note isn't
A tracker full of done items is not a release note. The titles are written for engineers: “fix null deref in export worker” means nothing to the customer who just wants to know the CSV export stopped breaking. So someone re-reads every closed ticket, translates it into plain language, groups it, and publishes the page, usually the evening before the release. Khint compresses that last mile with its three pillars (Agents, Capture, and Memory) wired behind one palette, so the notes get written where the tickets already live.
From done column to published page
Turning a “Release 2.4” sprint of closed tickets into one page users can read.
Open a session for the release
Before you touch the tracker, start a Memory session: call it “Release 2.4 notes”. Every pull and every Action you run is logged to it, and Khint keeps a compact running summary. That summary rides along on each AI Action, so by the time you draft the notes the model already knows which area shipped and what you have collected. How Memory works →
Gather what actually shipped
With Atlassian connected, the palette's Jira Active sprint and Search rows surface the issues that closed this cycle. Use Pull issueto bring each ticket's text into Khint. One issue per run, so the list is something you curated rather than a blind export. How integrations work →
Draft the user-facing notes
In Agents, save an Action like “Draft release notes”. No prompt yet? Type a description and press Generate. Khint drafts one that turns a raw list of closed tickets into clean notes grouped by Features, Improvements, and Fixes, with the internal jargon stripped out. Select your assembled list, hit Cmd+Shift+K, run it, and the customer-ready version is pasted back in place.
Publish to Confluence
Use the Confluence Create page row to publish the drafted notes as the release page the whole company reads. One page per run, so each publish is deliberate. Because the Create flow can run a saved Action first, the page lands already formatted to your house style. More on publishing to Confluence →
Make it one keystroke next release
Chain your “Draft release notes” Action and a Confluence Create pagestep into a single Workflow. The running text flows from the draft into the publish step, so “ticket list → live release page” becomes one run. Next release you select the list and press the shortcut once. Build a workflow →
Why not just paste the tickets into a chatbot?
You can, and every release you'll re-paste the product context, restate the tone and grouping you want, and copy the result back into Confluence by hand. Khint removes the round-trips: the “Draft release notes” Action is saved once and reused every release, Memory carries the release context into each prompt automatically, and the Atlassian and Linear integrations move the tickets and the published page without a browser tab in between. Because Actions only see the text you select, plus the session summary you opted into, your unshipped roadmap isn't sitting in a chat history.
Common questions
How does Khint know which tickets shipped this release?
You decide. Khint never guesses a release boundary. With Atlassian connected, the palette's Jira Active sprint and Search rows surface the candidates, and Pull issue brings a specific ticket's text into Khint. You pull one issue per run, so the list you assemble for the notes is something you curated, not an automatic dump. That keeps the published notes accurate: nothing lands in front of users that you didn't deliberately include.
Where do the finished release notes get published?
The Confluence Create page row in the palette turns your drafted notes into a real page the whole company can read. One page per run, so every publish is explicit. Prefer to keep the summary on the ticket? Use the Jira Add comment row instead. And because an Action just rewrites selected text, you can also paste the notes straight into Slack, an email, or your changelog doc. Linear teams can pull issues the same way before drafting.
Can I control the tone and structure of the notes?
Yes, the Action prompt is entirely yours. In the Agents page, type a one-line description like "Turn this ticket list into user-facing release notes grouped by Features, Improvements, and Fixes" and press Generate; Khint drafts the prompt, and Improve refines it in place later. You can pin the voice, drop internal jargon, and set the grouping once, then reuse it every release. The built-in Doc Polish starter pack is a good clean-writing Action to start from.
What does Khint send to the AI, and is my roadmap safe?
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 Atlassian credentials stay in the OS keychain. Stop the session and the release context is closed. The free tier covers 10 AI actions and 5 captures per day with no credit card; paid plans start at €7/mo, with Pro at €29/mo for 100 AI actions a day; every plan includes all the work integrations.
Write your next release notes here
Free with 10 AI actions and 5 captures per day. No credit card. Save the Action once, reuse it every release.