Go-live is a decision,make it on evidence
The day before a release, someone has to answer whether it can ship. The checklist itself is not the hard part: gathering what it needs is. Khint collects the sprint, the open defects, the UAT feedback and the screenshots into one work session, then an agent drafts the gate from that session, with an owner and a ticket reference on every line.
Everyone has a checklist template.
Nobody has the evidence in one place
The template takes ten minutes to find and two hours to fill, because filling it means going back through three weeks of work that lives in six places: the sprint board, the UAT spreadsheet, a Confluence page somebody updated on Monday, a Slack thread where the vendor incident was mentioned once, a screenshot of a monitoring panel, and the thing you remember but cannot cite. So the checklist gets written from memory the night before, the lines that are inconvenient get softened, and the gate becomes a formality that nobody trusts. A chat window does not fix that either, because it knows nothing about your release: you would have to paste all six places into it, which is the work you were trying to avoid.
Five steps, spread over the release week
Four of them are gathering, done as the week happens. The drafting is one shortcut at the end.
Open a session for the release, not for the day
In Memory, start a session named after the release and give it an objective: ship 4.2 with payments and the new onboarding, no open blockers, rollback rehearsed. From then on every pull, capture and note you make lands in that session as an entry. A release runs over two or three weeks, so the session is the only place where the evidence accumulates instead of scattering across tabs, threads and your own memory.
Pull the real state in, rather than retyping it
From the palette, pull the active sprint from your Jira board, then search for what is still open in plain English and let Khint write the JQL for you: unresolved blockers on the release version, tickets nobody is assigned to, everything reopened this week. Each pull lands in the session with its keys intact. Pull the test report page from Confluence the same way. The integrations that pull it in →
Capture the signals that have no API
Half of what decides a go-live is not in a ticket tracker: a red panel on a monitoring dashboard, a vendor status page, an error in the staging environment that only exists as a screenshot in a chat thread. Select the region and Capture extracts the text into the session. When the screenshot needs interpreting rather than copying, ask about it and save the exchange to the session, so the gate keeps the reasoning and not just the pixels.
Let the agent read the session, not your clipboard
Create the checklist agent in Agents and set its input source to Active session. It then runs on the session's working state with nothing selected: no copying, no pasting a wall of tickets into a chat window. Write the prompt to return the gate in sections, one line per item, each carrying its ticket reference, an owner, and a verdict of ready, at risk or blocking. Ask it to list separately the items it could not resolve, because an unanswered question is a finding too.
Publish it once, then keep it honest
Create the checklist as a Confluence page in the release space. As the week moves, append the updates to the same page rather than mailing a new version: the append is version locked, so if a colleague edited the page while you were writing, the write fails and tells you instead of overwriting their paragraph. Comment the verdict on the release ticket in Jira, and when the go or no-go is called, broadcast it to Jira, Slack and Confluence in a single step.
The shape worth asking for
An illustrative structure. Saved in the agent's prompt, it comes back identical every release, which is what makes two releases comparable.
Scope
What is actually in the build versus what was promised in planning, and which tickets moved out at the last minute.
Quality
Open defects by severity, UAT feedback that never became a ticket, and the tests that were skipped rather than passed.
Operations
Migrations, feature flags, the vendor whose status page was amber yesterday, and who is on call the evening of the release.
Rollback
The plan if it goes wrong, whether anyone has rehearsed it, and the point of no return after which it stops being available.
Communication
Who is told, when, and in which words: support, the client, the internal channel, and the release notes themselves.
Unresolved
The questions the agent could not answer from the session. The shortest section on a good week, and the one worth reading first.
One blocker, from signal to gate
An illustrative example. Notice what never disappears: the ticket key.
The same discipline applied to the defects coming back from user acceptance testing is covered in UAT feedback to tickets, and once the release has actually shipped, the closed tickets become release notes from the same material.
A gate is not a status report
They read alike and they are not the same document. A status report describes progress to people who are not in the room; it can be broadly true and still be useful. A readiness checklist exists to stop a release, so every line needs an owner, a reference and a verdict, and a line that says work is progressing well is worse than no line at all. The practical consequence is in the prompt: ask for verdicts and owners, forbid adjectives, and require the items with no answer to be listed rather than smoothed over. The risks that are structural rather than release specific belong in your RAID log instead, and if the gate keeps taking the same shape every time, chain the drafting and the Confluence write into one workflow behind a single shortcut.
Common questions
If I paste nothing, where does the checklist content come from?
From the Memory session you spent the week filling. An agent's input source is normally the text you selected, but it can be set to Active session instead, and then the session is the input. Khint keeps a compacted working state of each session, organised as an objective, open threads, artefacts, decisions and notes, and that working state is what the agent receives. So the checklist is assembled from the Jira issues you pulled, the UAT feedback you filed, the screenshots you captured and the notes you typed, and from nothing else. If a risk was never pulled into the session, it will not appear in the draft, which is the honest behaviour: the gate reflects what the team actually recorded.
Can Khint decide go or no-go for me?
No, and you should not want it to. What an agent can do reliably is the part nobody enjoys: collect every open item, group them by area, attach the ticket reference to each one, and mark the lines that have no owner or no answer yet. The judgement call, whether a known defect is acceptable on Friday afternoon, belongs to the room. That is also why nothing is filed automatically: a Jira comment, a Confluence page or a Slack post happens when you run that step, after you have read the draft.
What about the signals that are not in Jira, like a vendor status page or a monitoring panel?
Capture is for exactly that. Select a region of the screen and Khint extracts the text into your clipboard, and the extraction is logged into the active session. If you need to reason about a chart rather than copy it, Capture and ask opens a short conversation about the screenshot and a Save to session button writes the questions and answers back into the session as an entry. Reading pixels uses the Vision model, so each capture counts against your plan, while the rest of the gathering costs nothing until an agent actually runs.
Does the state of the release leave my machine?
The session does not. Memory sessions, their entries and the input and output text of every run live in a local database on your machine and are not synced to Khint's cloud. What does travel is the text of a given call: the working state is compacted through Khint's backend, which forwards it to the model and keeps no copy, and the same is true when the checklist agent runs. For a release that involves a client name or a support contact, the Redact PII switch on an agent replaces emails, phone numbers, national identifiers and IBANs before anything is forwarded.
Start the session on the next release
Free with 300 credits a month, about 10 AI actions a day. No credit card. Sessions stay on your machine.