Non-functional requirements,asked before the demo, not after
The functional scope gets written. The quality attributes get assumed: how fast, how available, who is allowed, what is kept and for how long. They surface in the demo, or in production. Khint lets you save one AI action that reads your spec and comes back with the questions nobody asked, phrased as requirements somebody can actually test.
Nobody forgets the feature.
Everybody forgets the constraints
A spec is easy to write in the direction of the happy path, because that is the part the stakeholder described. The rest is implicit: it will be fast enough, it will be available, nobody will export the whole customer table, we will delete data when asked. Those assumptions cost nothing until the load test, the accessibility audit or the first data request, at which point they cost a release. The reason they get skipped is not that analysts do not know them, it is that recalling the full list at 22:40 while finishing a page is unrealistic. A saved Action holds the list instead, and asks the same questions on every feature, whoever writes it.
One feature, one pass
From a functional spec to quality requirements sitting under it in Confluence.
Open a session for the feature, not for the document
Start a Memorysession called “Search revamp” and set its objective in one line. Every note you type, every page you pull and every screen you capture from here on lands in it, and Khint keeps a compacted working state of the lot: objective, open threads, artifacts, decisions. The quality constraints for a feature are never gathered in one sitting, so having a place they accumulate is most of the battle.
Write one Action that asks the boring questions
In the Action editor, describe it once: read the functional scope and produce non-functional requirements grouped by performance, availability, security, privacy and data retention, accessibility, observability, and operability. Press Generate for a first prompt, then Improve to tighten it. Add the two rules that make the output usable: every requirement must be measurable, and any figure not present in the input must come back as TBD rather than a guess.
Point it at the spec, not at a paragraph
Selected text works when you are reviewing one section. For a whole spec, set the action's input source to Document and either pin the file or leave it on Ask me each run, which opens a picker with a drop zone and your recent files. Small files are sent as they are, larger ones are condensed once per version of the content, so a re-run on an unchanged document does not redo that work. Running actions on documents →
Capture the constraints that only exist on somebody's screen
The retention rule lives in a compliance PDF nobody can export, the current latency is a number on a dashboard, the browser support matrix is a screenshot in a Slack thread. Pick Extract text in the palette, drag a region, and the text is on your clipboard and logged in the session, so the next run of the action sees it. How Capture works →
Chain the draft and the publish into one shortcut
A Workflow runs up to five steps in series. Step one, your NFR action. Step two, the Confluence Append to page integration step pinned to the spec page. Give the workflow a keyboard shortcut and the whole pass becomes one gesture: the requirements arrive under the functional scope, in the page where the team already looks. Appending to Confluence →
Reuse it on the next feature, and share it
The value of an NFR pass is that it is the same pass every time. Keep the action in a Pack with your other requirement tools, and if you own a team, Share the pack: teammates see it as a read-only Team Pack and clone their own copy in one click. Your definition of “we always ask about retention” stops depending on who is writing the spec that week.
A requirement you can argue about
The rewrite is the whole job: same intent, but now it has a subject, a measure and a place to put a number.
Notice what the model did not do: it did not pick the numbers. It cannot, because it has never seen your traffic, and a confident invented threshold is worse than an empty one. What it did is turn an adjective into a sentence with a blank in it, which is a thing your architect can answer in a minute and your tester can verify later. When the figures are agreed, the same text feeds the test case pass and the acceptance criteria on the stories it constrains.
The checklist lives in the prompt
Put your own categories in the saved action once, and every feature gets asked the same thing.
How fast, under what volume, measured where
What uptime, and what happens when it breaks
Who can do it, and what gets recorded
What is kept, for how long, and who can ask for deletion
Which standard, which viewport, keyboard only
What we can see when a user says it is slow
Your list will differ: a regulated domain adds traceability and approval trails, a public site adds SEO and browser support, an internal tool can drop half of it. That is why it belongs in a prompt you own rather than in a tool's idea of best practice. Bundle the action in a Pack with your spec review and glossary actions, and switch the pack when you switch product.
What Khint will not do here
It will not measure anything. There is no profiler, no load test, no scan of your codebase: an Action reads the text you gave it and, if you opted in, the compacted context of your active session, and nothing else. It will not tell you whether the target is achievable either, because that is an architecture conversation with people who know what the database does at three in the afternoon. And it will not decide which requirements matter enough to block a release. What it removes is the part that was never intellectual work: remembering the full list, and writing each item in a form that can be verified. If your problem is that an existing spec is already written and you need a critique of it instead, that is a different pass, AI spec review feedback.
Common questions
Will the AI invent performance targets my system cannot meet?
It will if you let it, so write the prompt so it cannot. An Action only sees the text you handed it plus, when you opt in, the compacted context of your active Memory session. It has no access to your monitoring, your load tests or your infrastructure. The version that works asks it to produce the requirement shape and leave the number as TBD unless the figure appears in the input: response time under TBD ms at the 95th percentile, measured on the search endpoint. You then fill the numbers with your architect, which is a five minute conversation instead of a blank page. Khint gives you the checklist and the phrasing, not the thresholds.
How is this different from generating acceptance criteria?
Acceptance criteria describe what the feature does for one story: given, when, then. Non-functional requirements describe how well the whole thing has to behave, and they usually cut across several stories at once: latency, availability, data retention, accessibility, audit logging, what happens under load. They also land in a different place, normally the spec page rather than the ticket. Different prompt, different output shape, different destination, so it is worth a separate saved Action. If you want the per-story layer too, see the acceptance criteria generator.
My spec is a long document. Do I have to paste it into a selection?
No. In the Action editor you can set the input source to Document instead of Selected text. Choose Ask me each run and the palette lets you drop a file, pick one of your recent files or browse before it runs. Choose Always use this file and the action is pinned to that document. Files up to 10 KB are sent as they are, and larger ones are condensed once per version of the content, so re-running against the same unchanged spec does not repeat that work.
Can it write the requirements straight into our Confluence spec?
Yes, through a Workflow. Connect Atlassian from the MCP page, build a workflow whose first step is your NFR action and whose second step is the Confluence Append to page integration step pinned to the spec page. Appending is version locked: if a colleague edited the page while your run was in flight, the write fails and tells you rather than overwriting their edit, and the existing page content is copied through untouched so macros and tables survive. Prefer to keep the discussion out of the page body? Use Comment on page instead.
Ask the boring questions early
Free with 10 AI actions and 5 captures per day. No credit card. Save the checklist once, run it on every spec.