Anyone can write the main flow,the exceptions are the specification
Actors, preconditions, a numbered main flow, alternate flows, exception flows. The template is not the hard part: the hard part is that the alternates surface as offhand remarks and error screens spread over a week of walkthroughs. Khint collects them as they happen, then one AI action writes the use case specification from all of it and publishes it to Confluence.
A specification is judged on the branches
nobody remembered to mention
A use case whose main flow is right and whose exception flows are thin does not fail in review. It fails six months later, in UAT, when the policy has lapsed and nobody wrote what the system should do. The reason is mechanical: the main flow gets demonstrated in one sitting, while the branches leak out one sentence at a time, across different people and different days. Khint’s three pillars (Capture, Memory, Agents) exist to close that gap: capture the fragment in the second it appears, keep every fragment in one session, then draft from the whole session rather than from the last conversation you happen to remember.
From scattered walkthroughs to UC-014, in five moves
Every step runs from the same palette shortcut.
Give the use case its own session, and its own scope
Start a Memorysession named the way the specification will be named (“UC-014 Submit a claim”) and leave it active for as long as you are working on that use case. Everything you gather next lands in it as an entry, and Khint keeps a compacted summary of the lot. The boundary of the session becomes the boundary of the use case: what you refused to put in it is, by definition, out of scope.
Record the main flow in the order the system imposes it
Have the user drive their own screens and narrate. When a screen matters, run Capture from the palette: Extract text lifts the exact field labels, button wording, and status values off the shared screen, which is what stops a specification from inventing a vocabulary the system does not use. Type your own notes for the parts nobody shows: who triggers the use case, what has to be true before step one.
Chase the alternates and exceptions while they are still spoken
This is the half that sinks specifications, and it never arrives as a list. It arrives as “oh, unless the policy lapsed” halfway through an unrelated sentence, and as an error dialog somebody dismisses in half a second. Note the asides the moment they land, and when a failure appears on screen use Capture & ask to question the screenshot instead of retyping the codes. With Atlassian connected on the Integrations page, Pull issue brings in the tickets where the awkward cases were argued out. Because they all land in the same session, the drafting step sees the exceptions and the main flow together.
Draft the specification in your template, not the model's
Save an Actionwhose prompt is your house template: actors and stakeholders, preconditions, trigger, the numbered main flow, alternate flows branching off named step numbers, exception flows with the system response, postconditions, business rules, open questions. Select your raw notes, press Cmd+Shift+K, run it. The Action reads the active session’s compacted context too, so the aside from Tuesday and the error screen from Thursday come back as numbered branches rather than being lost. In the Action editor you can describe the template in one line and press Generate to have the prompt drafted, then Improve it in place as your standard hardens.
Publish it, then keep it reachable
Run Create pagein the palette’s CONFLUENCE section and the specification lands where reviewers look for it. If you specify use cases regularly, chain the two moves into one workflow: drafting Action as step one, Confluence Create page as step two, so raw notes in and published specification out is a single palette row. Your open-questions section is the agenda for the review, and Comment on pageis how each answer gets recorded against the document rather than in somebody’s inbox.
Use cases, user stories, and the process underneath
Not every team ships specifications, and the same session serves the neighbouring deliverables. When the work is sliced for a sprint rather than specified for a contract, the alternate flows you collected become the negative cases in acceptance criteria. When the question is how work moves between people rather than how one actor moves through one system, an as-is process document is the deliverable, and it usually comes first. And when the stakeholders are still telling you what they want at all, that is requirements elicitation, upstream of every specification here. The specification is what the three of them get pinned to.
Common questions
Will the AI invent flows I never observed?
It only sees what you gave it. An Action reads the text you selected when you ran it, plus the compacted summary of your active Memory session: the walkthrough notes, the captured screens, the pulled tickets and pages you put there yourself. Khint does not watch your screen or read your apps in the background. A use case specification is a contract, so treat the draft as a draft: the flows you never confirmed should come back in the open-questions section, and it is still your name on the document.
How do I keep every use case in the same house template?
Write the template into an Action once. Its prompt is where you pin your numbering scheme, your section order, and whether you use preconditions or entry conditions. Every use case you specify afterwards runs the same palette row, so UC-014 and UC-027 come out in the same shape a year apart. Bundle it with your other analysis Actions into a pack and share the pack with your team, and the whole practice writes to one template instead of five.
Can Khint write the specification straight into Confluence?
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 Create page, Append to page, and Comment on page. You can also make Create page the last step of a workflow, so drafting the specification and publishing it run as a single palette row. It is your own credentials doing the writing.
The system I am specifying is a legacy app with no documentation. Where does the input come from?
From the screens themselves. Palette to Capture: Extract text lifts field labels, statuses, and error messages off a shared screen into text, and Capture & ask lets you question a screenshot directly, for example about which states a dropdown offers. If there is an old specification PDF or Word file, point an Action at the file instead of a selection: Khint reads text, PDF, Word, PowerPoint, Excel, and OpenDocument files locally, and images through Capture.
Write the flows you actually observed
Free with 300 credits a month, about 10 AI actions a day. No credit card. Atlassian connects with your own email and API token, kept in your keychain.