Test cases that cover the story,not just the happy path
Acceptance criteria say what done means; someone still has to design the walks that prove it. Khint turns a selected user story into a structured test suite (one case per criterion, plus the negatives and edge values the criteria imply) and publishes the plan to Confluence, all from one keyboard shortcut.
The criteria are three lines,
the coverage isn't
A story says “a signed-in user can save a payment method”. The suite that actually protects it asks what a signed-out user sees, what happens on the second identical card, what an expired date does, where the limit is. Deriving those walks by hand for every story in the sprint is slow, and skipping them is how the bug that was never tested ships. Khint compresses the derivation with its three pillars (Agents, Capture, and Memory) behind one palette, so the suite gets designed where you read the story.
Story to published test plan
Designing the suite for a “saved payment methods” story before the build lands.
Open a session and pull the story into it
Start a Memorysession, call it “Test design: saved payment methods”. With Atlassian connected, the palette's Jira Pull issue row fetches the ticket into the session, so the story and its acceptance criteria become the context every Action in this session can see. Your cases get designed against the real ticket, not a stale copy.
Save a test-case Action once
In Agents, create an Action like “Design test cases”. No prompt yet? Describe it in one line and press Generate: Khint drafts a prompt that maps each acceptance criterion to a titled case with preconditions, numbered steps, and an expected result, then adds the negative and boundary variants the criteria imply. Your template, your coverage bar: saved once, reused on every story after.
Select the story, run the Action
Select the story text wherever you are reading it: Jira in the browser, the Confluence spec, a refinement doc. Hit Cmd+Shift+K, run the Action, and the structured suite is pasted back in place. Because the session summary rides along, a case like “expired card is rejected with the agreed error message” can lean on details from the pulled ticket even if your selection only said “handle invalid cards”.
Publish the plan to Confluence
A suite in a scratch doc is a suite nobody re-runs. The palette's Confluence Create page row publishes the cases as a page in your space, or chain the Action and the Confluence step into one Workflow, so a single keystroke takes the selected story to a published test plan. How integrations work →
When a case fails, file the bug from the same palette
Execution finds what design predicted. When a case fails, use Capture's Extract text to grab the error off the screen, then shape your notes into a report with a bug-report Action and file it to Jira: the whole loop, from designing the case to filing its failure, lives behind the same shortcut.
What a case your team can re-run carries
The fields your Action fills in: one example of a template you control.
Nothing here is baked into Khint: the fields above are just an example. The template lives entirely in the Action prompt you save, so a team that traces every case to a criterion, a team that needs an automation-candidate flag, and a team that writes exploratory charters instead each get the suite they asked for. Draft it with Generate, tighten it over time with Improve, and share the pack so every tester designs against the same bar.
Why not just paste the story into a chatbot?
You can, and for every story in the sprint you'll re-explain your case template, re-paste the acceptance criteria, and copy the suite back out by hand. Khint removes the round-trips: the test-design Action is saved once and runs the same on story twelve as on story one, Memorycarries the pulled ticket into each draft automatically, and the Confluence integration publishes the plan where the team will actually find it. Because an Action only sees the text you select (plus the session summary you opted into), an unreleased feature's behaviour isn't sitting in a chat history. Writing the criteria themselves is the story's author's job. See the acceptance criteria generator.
Common questions
How does Khint generate test cases from a user story?
You save an AI Action that carries your test-design standard: for each acceptance criterion, a titled case with preconditions, numbered steps, an expected result, and the negative and edge variants around it. Then you select the story text wherever it lives (Jira in the browser, a Confluence spec, a scratch doc), hit Cmd+Shift+K, and run the Action. The structured cases come back in place, in your template, without opening another tool. The prompt is yours, so a team that tests API contracts and a team that tests checkout flows each get their own kind of suite from the same shortcut.
Is this the same as the acceptance criteria generator?
No, it is the step after, on the other side of the handoff. The acceptance criteria generator helps a product owner define what done means: Given/When/Then conditions attached to the story. A test-case Action consumes that definition and designs how to prove it: concrete walks through the feature, including the invalid inputs and boundary values the criteria imply but never spell out. They pair naturally: sharp criteria in, honest coverage out.
Can Khint read the story straight from Jira?
Yes. Once Atlassian is connected (your email, API token, and site domain, stored in your OS keychain), the palette's Jira Pull issue row fetches a ticket into your active Memory session. From then on the story's summary rides along with every Action you run in that session, so the cases you draft stay anchored to the actual ticket, not your memory of it, even when you are working from a half-quoted version in a doc.
Where does the finished test suite end up?
Wherever you want it. The cases paste back in place of your selection by default. To make them the team's copy, the palette's Confluence Create page row publishes the suite as a page in your space, or you chain the test-case Action and the Confluence step into one Workflow, so a single run takes the selected story all the way to a published test plan.
Do I have to write the test-design prompt myself?
No. In the Action editor, type a one-line description like "turn this user story and its acceptance criteria into test cases with preconditions, steps, expected results, and negative and edge variants" and press Generate: Khint drafts the prompt for you. Run it on a few real stories, notice what you keep fixing, and press Improve to tighten the prompt in place. When it is good, share the pack with your team so every tester designs against the same bar.
Where does my story text go?
An Action only ever sees the text you selected, plus the compacted summary of your active Memory session if you opted in. Memory sessions live in a local SQLite database on your Mac and are never synced to Khint's servers, and your Atlassian credentials sit in your OS keychain. Nothing about an unreleased feature leaves your device silently.
Design your next test suite in one shortcut
Free with 10 AI actions and 5 captures per day. No credit card. Save the test-design Action once, run it on every story after.