“Can we also add…?”Know what it touches before you answer

A change request never arrives with its consequences attached. They are scattered across the epic, four stories, an old Confluence spec, and a sprint that is already running. Khint pulls all of it into one work session, drafts the impact assessment from that real context, and publishes the verdict back to Confluence and Jira, from one palette shortcut.

For business analysts and product owners. macOS and Windows, menu-bar app. Jira, Confluence, and Gmail connect with your own credentials.

A gut-feel estimate
is a commitment in disguise

Answer “should be small” in the meeting and that phrase becomes the estimate of record. Doing it properly means an hour of tab archaeology: reopening the epic, re-reading the spec, checking which in-flight stories quietly assume the old behaviour. Most days, that hour loses to the calendar. Khint shortens it: its pillars (Agents, Memory, Capture) plus its Jira, Confluence, and Gmail integrations let you collect the evidence in minutes and draft the assessment from it, instead of from memory.

From “quick question” to written verdict, in five moves

Every step runs from the same palette shortcut.

  1. Open a session for the change request

    Before you answer “quick question, how big would this be?”, start a Memory session named after the request. Everything you pull in the next steps is logged into it, and Khint keeps a compacted summary of the lot. The session is your evidence file: the analysis will be drafted from what is actually in it, not from what you remember about the feature.

  2. Get the request itself in, verbatim

    If it came by email, run Gmail's Pull thread from the palette and the whole exchange lands in the session, in order. If it came as a slide or a screenshot, run Extract text from the Capturerows: draw a region, the text is read out and copied. Impact analysis that starts from a paraphrase inherits the paraphrase's errors; start from the stakeholder's own words.

  3. Pull what the change would touch

    From the JIRA section of the palette, Pull issue brings in the epic and, key by key, the stories under it; Search finds the tickets that mention the same screens or rules; Active sprintshows what is in flight right now. Then run Confluence's Pull page on the original spec. The blast radius of a change hides in tickets and pages nobody reopens; this step reopens them in one place.

  4. Draft the impact assessment with one Action

    Run a saved Action built for this: list the requirements this change contradicts, the tickets it would reopen, the open questions, and a recommendation. Actions read the compacted context of your active session, so the draft is grounded in the epic, the stories, the sprint, and the spec you just pulled, together. You review and edit; the point is that the draft starts from evidence.

  5. Publish the verdict where the team will see it

    From the same palette, Create page publishes the assessment to Confluence, and Add comment puts the summary on the Jira epic, so the decision trail lives next to the work. If the change is accepted, drafting the follow-up tickets happens from the very same session, which already contains everything they need to say.

The session is the audit trail

Impact analysis has a second life: months later, someone asks why the change was accepted, or why it cost three sprints instead of one. Because the whole exercise ran inside a Memory session, the evidence is still there, on your machine: what was pulled, what the assessment said, what was published. It is the same habit that powers requirements traceability across a project, and if the change carries real delivery risk, the same session feeds your RAID log entry too.

Common questions

Does the AI decide the impact for me?

No, and it should not. The Action drafts an assessment from what you pulled into the session: the change request itself, the epic, the tickets, the spec page. It can only reason over what you collected, which is exactly the discipline impact analysis needs. You review the draft, correct what it got wrong, add what only you know, and you are the one who publishes it. Khint's job is to make sure the draft starts from the actual tickets and the actual spec instead of from your recollection of them.

The change request arrived as a slide, not an email. Now what?

Use Capture. If the request lives in a slide, a PDF, or a screenshot someone dropped in chat, run Extract text from the palette: you draw a region on screen, Khint reads the text out of it, and it lands on your clipboard ready to paste into the session. If you need to interrogate the image rather than just transcribe it, Capture & ask opens a chat about that screenshot. Either way the request's actual wording enters your session, not your paraphrase of it.

Where does the assessment end up when I'm done?

Wherever your team reads. From the same palette, Create page publishes the assessment to Confluence in the space you choose, and Add comment posts the verdict on the Jira epic so the decision is visible where the work is tracked. Both rows use your own Atlassian credentials: your email, an API token, and your cloud domain, stored in your operating system's keychain, never on Khint's servers.

Is my analysis history stored somewhere I don't control?

The session that holds your pulls and drafts lives in a local database on your machine. Sessions are never synced to Khint's cloud. When the assessment ships, end the session; it stays in your Memory history on-device, so three months later, when someone asks why the change was accepted, you can reopen the session that contains what was pulled and what was concluded.

Next time, answer with the analysis

Free with 10 AI actions and 5 captures per day. No credit card. Jira, Confluence, and Gmail connect with your own credentials, kept in your keychain.