The spec says what it does,the guide says how to do it
A spec is written for the team that builds the feature. A guide is written for the person who has to use it. Khint runs that rewrite where the spec already lives: point one saved agent at the file, get back prerequisites and numbered steps, and publish the finished page to Confluence from the same keyboard shortcut.
The feature shipped,
the guide did not
Documentation is the task that loses every scheduling argument. The spec exists, the screens exist, and what is missing is the hour that turns intent into instructions: what this is for, what you need first, the steps in order, what you should see when it worked. Khint runs that hour as one saved agent on the file you already wrote, with your session context riding along.
A real workflow run: the draft leaves the document it was written in and the last step files it in the tool your readers already open.
One pass, spec to published guide
Documenting a new “Bulk invoice export” screen the week it ships.
Open a session for the release
Start a Memorysession called “Invoice export release” before you write anything. Every agent you run is logged to it, and Khint keeps a compact running summary that rides along on the next prompt. That is what stops section four calling the same screen by a different name than section one, and it is why the second guide you write this week already knows the vocabulary of the first.
Point the agent at the spec, not at a copy of it
An agent can take a document as its input: pick the spec file once and the agent reads it on your Mac, in Word, PDF, Markdown or a wiki export. A short spec is read in full. A long one is condensed into a compact digest that Khint generates once, caches locally, and regenerates only when the file changes, so re-running the agent on a fifty-page spec does not mean paying to read it again.
Draft the guide with an agent you keep
In Agents, save one called “Write the user guide”. No prompt yet? Type a description and press Generate: Khint drafts one that returns a purpose line, the prerequisites, numbered steps in the order a user meets them, the result they should see, and a short troubleshooting list. The agent is the part you keep. Every feature after this one is the same shortcut on a different file.
Name the real buttons, not the ones in the spec
Labels drift between the spec and the build, and a guide that names a button nobody can find is worse than no guide. Open the palette on the finished screen and use Extract text: drag a box over the page and the visible labels come back as plain text on your clipboard. Paste them under the draft, run a second pass, and the steps say Export selected because that is what the product says.
Publish it where people go looking
Connect Atlassian and the palette gains a Confluence Create page row. The first line of the draft becomes the page title and is not repeated underneath it, and the markdown becomes real headings, numbered lists and code blocks rather than one grey wall of text. One write per run, and the page URL comes back as the result. See how integrations work.
Spec in, published guide out
Up to five steps in series, with the write that files the result at the end.
Set Starts from to Document and the workflow asks for the spec instead of a selection, which means the whole guide is one keypress on a file. Swap the middle step for whatever your readers need: a translation pass for a second market, a house-style check, a step that trims every sentence over twenty words. The write at the end is what makes the workflow worth saving, because the guide stops living in your editor and starts living where someone will look for it.
What it will not do
Four things worth knowing before you save the workflow.
It writes words, not screenshots
Khint publishes the text the workflow produced. The images are still yours to add: create the page from the palette, then drop the screenshots into it. Nothing else is uploaded with the draft.
One write per run
The Confluence step is the last step and it fires once, on your go. A run you cancel before it never touches the page, and a run that fails at the write leaves the draft intact rather than half a page published.
A scanned spec stops it
If the file is a scan with no text layer, Khint says so instead of guessing, and points you at Capture, which reads the page as an image. Image files go that way too. Everything else is extracted on your Mac.
It reads what you point at
The agent sees the file you picked or the text you selected, plus the compacted summary of your active session if you left that on. Searching your indexed Jira and Confluence is a separate checkbox on the agent, off until you tick it.
The version you rewrite three months later
Guides rot the moment the feature moves. When the spec changes, the same agent runs on the updated file and returns the guide again, and because the session summary is still the release you documented, the second version keeps the vocabulary of the first. If the page is already live and only one section moved, use the version-safe append instead of publishing a second page, and keep the release notes for what changed rather than for how it works.
Common questions
Can Khint write a user guide from a spec I already have?
Yes, and pointing it at the file is the whole setup. An agent can take a document as its input source: pick the spec once, in Word, PDF, Markdown or a wiki export, and Khint reads it on your Mac. A short spec is read in full; a long one is condensed into a compact digest that is generated once, cached locally, and refreshed only when the file changes. The agent returns the guide in the structure you asked for: what the feature is for, what you need before you start, the numbered steps, and what you should see when it worked.
How is a user guide different from release notes?
Release notes tell someone who already uses the product what changed this week. A guide tells someone who has never seen the screen how to finish a task, in order, with the prerequisites stated up front. Khint writes both, but from different sources: release notes from the tickets that closed in the version, a guide from the spec plus the screen as it was actually built. Trying to make one document do both jobs is why so many wiki pages get skimmed and then ignored.
Will the steps name the real buttons in the product?
They will if you show Khint the screen. Labels drift between the spec and the build, so open the palette on the finished feature and run Extract text: drag a box over the page and the visible labels come back as plain text on your clipboard, with no retyping. Paste them under the draft and run a second pass, and the steps use the product's own wording instead of the spec's. For a screen you do not know, Capture and ask lets you question the region in a short vision chat first.
Where does the finished guide get published?
Connect Atlassian and the palette gains a Confluence Create page row. The first line of the draft becomes the page title and is dropped from the body, so a page never opens with its own heading twice, and the markdown is rendered into real Confluence structure: headings, bullet and numbered lists, code blocks, links. There is one write per run and it is always deliberate. The page URL comes back as the result, so the next thing you do is paste the link, not go hunting for it.
Does my unreleased spec leave my Mac?
Running the agent sends the text you pointed at to the model that drafts the guide, and that is the only place it goes. Khint keeps no copy in the cloud: Memory sessions and the document digest cache live in a local SQLite database on your machine and are never synced, and the body of every history entry stays on the device as well. Stop the session and the context is closed.
Document the next feature the week it ships
Free with 300 credits a month, about 10 AI actions a day. No credit card. Save the agent once and every feature after it is one shortcut.