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 isn't 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 agent you run is logged to it, and Khint keeps a compact running summary. That summary rides along on each AI agent, 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 issue to 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 agent 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 agent first, the page lands already formatted to your house style. More on publishing to Confluence →
Make it one shortcut next release
Chain your “Draft release notes” agent and a Confluence Create page step 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” agent 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 agents 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 agent 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 agent 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 agent to start from.
What does Khint send to the AI, and is my roadmap safe?
An agent 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 300 credits a month, about 10 AI actions a day with no credit card; paid plans start at €7/mo, with Pro at €29/mo for 4,000 credits a month; every plan includes all the work integrations.
Write your next release notes here
Free with 300 credits a month, about 10 AI actions a day. No credit card. Save the agent once, reuse it every release.