Review the spec,don't rewrite it
Being asked to review someone else's spec is a real job with no real tooling: you read forty paragraphs, spot six things, and then lose an hour turning them into feedback polite enough to send. Khint runs your own review Action on the document and posts the findings as a Confluence comment under the page, so the author gets a structured review and their page stays exactly as they wrote it.
Reviewing is a different job
from writing
Most AI writing tools assume you own the document. A reviewer does not. You cannot “improve” a colleague's spec, because the version they wrote is the record the team agreed to read, and an edit that arrives without a conversation reads as a takeover. So reviewers do the safe thing instead: they skim, write “looks good, a couple of questions”, and the ambiguity survives all the way to a sprint where it becomes a bug. The useful output of a review is not a better document. It is a short, specific list of what is missing, attached to the page, with the author still holding the pen. That is the shape Khint produces, and the Confluence integration has the exact write for it: a comment is a pure addition, with no version and no read-modify-write, so it cannot damage the page even in principle.
One review pass, step by step
From “can you take a look at this?” to feedback the author can act on, without leaving the page.
Switch on Comment on page
Connect Atlassian from the MCP page with your email, API token, and cloud domain, which stay on your machine. On that same Atlassian card, open the Palette actions block and switch on Comment on page: it is off by default, because most people write before they review. Turn on Pull page at the same time if you want the spec itself in your session.
Open a session for this review
Name a Memory session after the thing under review: “Payments spec, review pass 1”. Pages you pull and comments you post are logged into it, and its compacted working state is fed to your later actions, so a second pass does not re-raise what the first pass already raised. How Memory works →
Write the reviewer, once
In the Action editor, create an Action called “Spec review”. Describe it in one line, something like “list gaps, ambiguities, missing acceptance criteria, and open questions, as short bullets, no rewriting”, and press Generate to get a prompt. Give it a keyboard shortcut. Every review you ever run now asks the same questions in the same order, which is what makes reviews comparable.
Run it on the passage, or on the whole file
Select the ambiguous section in the browser and hit Cmd+Shift+Kto run the Action on exactly that text. For a full document, set the Action's input source to Document and the palette asks which file to read each run, with a drop zone and your recent files. Long specs are condensed into a cached digest first, so the review is one action, not a paste marathon. Running actions on documents →
Post it under the page, not into it
Select the passage, open the palette, and pick Comment on pageunder Confluence. Khint asks for the space, then the page (your last used space floats up, and pasting the page URL works too), then which agent should write the comment. Pick “Spec review”, read the preview, confirm, and the findings land as a footer comment. Already drafted the review yourself? Choose use the text as-is and Khint just posts it.
The page is untouched. The review sits under it.
What a posted review looks like on the author's page.
- 3.2 does not say whether a partial refund can be issued twice on one order.
- No acceptance criteria on the chargeback path, so QA has nothing to test.
- “Promptly” in 3.1 needs a number before this can be estimated.
The grey rows are the spec as its author left it, and nothing in this flow reads or republishes them: the comment is posted on its own, so the page version does not even move. The blue block is the only thing you added, and its shape comes from your saved Action, which means every reviewer on your team who runs the same Action produces feedback in the same format. When a finding is real work rather than a question, it graduates: select it and run Create issue to file it in Jira, the flow covered in writing to Jira from anywhere.
When the review is a standing gate
Some reviews repeat: the same architecture page before every release, the same intake template from a partner team. Put the review in a workflow instead of running it by hand. One agent step drafts the findings, one integration step posts the comment on a page you pinned once, and the whole gate is a single keystroke. If the document you are reviewing is a mockup or a diagram rather than prose, capture it and ask about it directly, which is the ask AI about your screen flow, and paste the answer into the same comment. Everything you pull, ask, and post lands in the Memory sessionfor the review, so when the author asks “what did you flag last time?” the answer is one recap away.
Common questions
Why post a comment instead of editing the spec directly?
Because reviewing and authoring are different jobs, and mixing them costs the author their record. A comment in Confluence is a pure addition: Khint posts a footer comment under the page without reading, versioning, or rewriting the body, so it physically cannot corrupt what the author wrote. The page owner still decides what to accept. If you are the author and you do want text added to the body, that is the append flow, covered in the append to a Confluence page use case.
Does the AI need the whole spec, or just the part I am reviewing?
Either works, and they are two different moves. Select a passage and the review runs on exactly that passage, which is what you want when one section is ambiguous. To review a whole document, give the Action a Document input source instead: it reads the file you pick each run, and files above roughly ten kilobytes are condensed into a digest first, cached by content so re-running on an unchanged file costs nothing extra. Long specs stay reviewable without pasting them anywhere.
Can I post a review I wrote myself, without AI drafting?
Yes. When the Comment on page flow asks which agent should write the comment, the first choice is always to use the text as-is with no AI drafting. That makes the flow useful as plain plumbing: draft your review however you like, select it, and Khint handles the space picker, the page picker, the preview, and the post. It is also how you post the output of a Document input review, since that output lands as ordinary text you can select.
How do I stop repeating context I already gave in the last review?
Start a Memory session for the review and leave it active. Every page you pull and every comment you post is logged into it, and the session keeps a compacted working state that rides along on later AI actions. So the second pass on the same spec is written knowing what the first pass already flagged, instead of repeating it. The Recap tab gives you a readable summary of the whole review when you need to brief the author.
Give the review you would want to receive
Free with 10 AI actions and 5 captures per day. No credit card. Your next review lands as a comment before the author has finished their coffee.