The process lives in six heads,get it onto one page
Every business analyst inherits a process nobody wrote down: the returns flow, the onboarding checks, the approval chain that only Marie fully understands. Khint collects the walkthroughs, screenshots, stale wiki pages, and revealing tickets into one work session, then one AI action structures it into an as-is process document and publishes it to Confluence.
Process discovery is a collection problem
before it is a writing problem
The truth about a process arrives in fragments: a screen-share of the legacy tool, an offhand “oh, unless it’s a B2B order”, a wiki page last edited three years ago, a ticket that documents an exception the hard way. The doc is late not because writing is slow but because the fragments live in five places. Khint’s pillars (Capture, Memory, Agents) plus its Jira and Confluence integrations put every fragment into one session as you gather it, so the writing step starts from everything at once.
From “ask Marie” to a published page, in five moves
Every step runs from the same palette shortcut.
Open a session for the process, not the meeting
Start a Memorysession named after the process itself (“Returns & refunds, as-is”) and keep it active across the whole discovery week, not just one call. Every walkthrough, capture, and pull in the next steps lands in it as an entry, and Khint maintains a compacted summary of the lot. The session becomes the single container for a process that currently lives in six people’s heads.
Capture the process as people actually show it
Nobody narrates a process in order; they share their screen and click through the legacy tool. When a screen matters, run Capture from the palette: Extract text lifts the field names, statuses, and error messages off the shared screen into text, and Capture & asklets you question a screenshot (“what are the possible states in this dropdown?”) when reading isn’t enough. Type your own notes for the parts people say out loud: “if the amount is over 500, it goes to Marie first.”
Pull in what's already written down, however stale
There is usually a three-year-old wiki page that half-describes the process, and a handful of tickets that document its exceptions the hard way. With Atlassian connected on the Integrations page, run Pull page on the old Confluence doc and Pull issue on the revealing tickets. They land in the session next to your captures, so the AI sees what the org thinks the process is alongside what you observed it to be.
Run one Action that structures it into an as-is doc
Save an Actionwhose prompt asks for the document you actually owe: ordered steps with the actor and system per step, handoffs, decision points, exceptions, and open questions. Select your raw notes, hit Cmd+Shift+K, run it. Because Actions read the active session’s compacted context, the draft draws on the captures, the old wiki page, and the tickets too, not just the lines you selected. You review it as the analyst: fix the step order, mark what’s unconfirmed.
Publish to Confluence without leaving the palette
Run Create pagein the palette’s CONFLUENCE section and the doc lands where the team will look for it. If you document processes regularly, chain the two moves into one workflow: the structuring Action as step one, the Confluence Create page step as step two, so “notes in, published page out” becomes a single palette row. The open questions section becomes your agenda for the follow-up walkthrough.
A process doc, not a requirements doc
Documenting how work flows today is its own deliverable: the one that comes beforeanyone argues about what should change. When the walkthroughs start yielding asks rather than facts, that’s a different job with its own flow: requirements elicitation turns stakeholder interviews into structured, Jira-ready requirements. And if the workshop ended with the to-be sketched on an actual whiteboard, a photo of it is enough to bring it into the same session. The as-is page you published becomes the stable reference both of those point back to.
Common questions
What does the AI actually write the process doc from?
Only what you gave it. An Action sees the text you selected when you ran it, plus the compacted summary of your active Memory session: the walkthrough notes, captures, Confluence pages, and Jira tickets you deliberately collected there. Khint doesn't watch your screen or read your apps in the background; nothing else leaves your machine silently.
Can Khint publish the doc to Confluence for me?
Yes. Connect Atlassian on the Integrations page with your email, API token, and cloud domain, kept in your operating system's keychain, and the palette gains a CONFLUENCE section with a Create page row. You can also wire Create page as the final step of a workflow, so 'structure the notes, then publish' runs as one chain. Either way it's your Confluence credentials doing the writing.
How do I get the to-be process out of the same work?
Keep the session active. Everything you collected for the as-is is already in the session's compacted context: the walkthroughs, the exceptions, the complaints about the current flow. A second Action ('propose a to-be version of this process, list what changes per step') starts from everything you learned instead of a blank page. Draft it, edit it like a document you wrote, and publish it as a second page.
Do I have to write the structuring prompt myself?
You can, but you don't have to start from zero. In the Action editor, describe what you want in one line, 'turn raw walkthrough notes into an as-is process description with actors, steps, systems, handoffs, and exceptions', and press Generate: Khint drafts the prompt for you, and Improve refines it in place later. Once saved, the Action is a permanent palette row you rerun for every process you document.
Write the doc everyone said they’d get to
Free with 10 AI actions and 5 captures per day. No credit card. Atlassian connects with your own email and API token, kept in your keychain.