--- title: "Release Freeze Triage Workflow With AI Agents | Kylon" description: "How a release team triages pull requests during a code freeze, merges what meets the bar, reverts what no longer does and records every decision, in one Kylon room." url: "https://kylon.io/use-cases/release-freeze-triage" language: "en" --- [HOME](https://kylon.io/)\>[Use Cases](https://kylon.io/use-cases)\>Release Freeze Triage: Only Changes That Meet the Bar Reach the Release Branch Use Case8 min read # Release Freeze Triage: Only Changes That Meet the Bar Reach the Release Branch During a release freeze, in-scope pull requests are dispositioned against the admission standard, admitted ones merge after approval, and exceptions, a raised bar and CI readbacks re-derive decisions, reverting merged changes that no longer qualify. [Get started](https://app.kylon.io/sign-up) Kylon TeamProduct November 6, 2026 ## A freeze is only as good as its admission bar During a release freeze the release branch takes only what meets the admission standard. Section 1 of the standard decides which pull requests are in scope at all. The rest decides whether an in-scope pull request is admitted, deferred until the freeze lifts or rejected, and with which reason code. Admitted pull requests are merged, and every decision goes on the freeze board so the release manager can see the whole branch at once. The pull requests and their checks are in GitHub, the board is in ClickUp, the standard and its amendments are in Google Drive, and the arguments happen in Slack. Freezes go wrong in the middle: an exception is granted, the bar is raised the night before release, or CI results come back for a handful of pull requests. Re-checking only what someone named, or forgetting that a raised bar applies to what has already merged, leaves the branch holding changes the standard no longer allows. ## Who works in the room People - Release manager Owns the admission standard and approves every merge, revert and exception - QA lead Posts CI readbacks and confirms results that look wrong - Engineering leads Ask for exceptions and own the pull requests in the freeze Agents - NovaFreeze triage Decides scope under section 1, dispositions every in-scope pull request with a reason code, and proposes merges, reverts and board updates GitHubClickUpGoogle Drive - FinReadback and revert checker Re-derives pull requests named in a CI readback under the bar in force, checks every revert before the release manager sees it and posts the group closeout GitHubClickUpGoogle Drive[Slack](https://kylon.io/integrations/slack) Each freeze gets its own Kylon room, with Nova as the default agent for scope and dispositions, so every pull request question goes to Nova first. The room guidelines give CI readbacks to Fin, along with a second look at every revert before the release manager sees it, so Nova mentions Fin on each revert it proposes. Both agents use GitHub through a lasting grant the repository owner approved for this room, and every merge and revert still waits for the release manager in the thread. ## Triage under the freeze, scope first Scope always comes first. Out-of-scope pull requests are never touched, and nothing merges, reverts or moves on the board until the release manager approves. ```mermaid flowchart TD scope["Nova sorts open pull requests into
in scope or out under section 1"] sok["Release manager confirms the scope"] disp["Nova admits, defers or rejects
each one with a reason code"] dok["Release manager approves
each merge"] merge["Nova merges admitted ones and
records each on the ClickUp board"] req([An engineering lead
asks for an exception]) rederive["Nova re-derives under the
raised bar, merged ones too"] ci([QA posts a CI readback]) exc["Release manager
grants the exception"] revert["Fin checks each
revert Nova proposes"] readback["Fin re-derives the named
ones under the bar in force"] rerun["Nova re-runs only
that pull request"] rok["Release manager
approves every revert"] qa["QA lead confirms results,
release manager approves"] post["Release manager approves
the group closeout post"] scope --> sok --> disp --> dok --> merge merge --> req & rederive & ci req --> exc --> rerun rederive --> revert --> rok ci --> readback --> qa rerun & rok & qa --> post class scope,disp,merge,rederive,revert,readback,rerun agent class sok,dok,exc,rok,qa,post person class req,ci event classDef agent fill:#FFFFFF,stroke:#DCD3C8,color:#1B1712 classDef person fill:#EEF0E3,stroke:#6E7447,color:#1B1712 classDef event fill:#F4ECDD,stroke:#F4ECDD,color:#564C42 ``` | Stage | What happens | Who acts | Who decides | | --- | --- | --- | --- | | Scope | Section 1 of the standard sorts every open pull request against the release branch into in scope or out | Nova, from GitHub and the standard in Google Drive | The release manager confirms the scope | | Disposition | Each in-scope pull request is admitted, deferred or rejected with a reason code | Nova | The release manager approves | | Merge and record | Admitted pull requests are merged and each decision is recorded on the ClickUp board | Nova | The release manager approves each merge | | Exceptions | A granted exception re-runs only that pull request, and its new reason code goes on the board | Nova | The release manager grants the exception | | Bar change | Every in-scope pull request is re-derived, merged ones included, and merged non-admits get a revert and a revert card | Nova, with Fin checking each revert | The release manager approves every revert | | CI readback | Pull requests named in the readback are re-derived under the bar in force now | Fin | The QA lead confirms the results and the release manager approves | | Closeout | One summary per team group with admitted, deferred, rejected and reverted pull requests | Nova, then Fin for the Slack post | The release manager approves the post | Stages of release freeze triage. Pull request numbers, reason codes and the release in this example are illustrative. ## When the bar moves after merges have landed Raising the bar is the change that catches teams out. The night before release the standard is amended to admit only P0 fixes. Nova re-derives every in-scope pull request, including those merged earlier in the freeze, because a merge under the old bar does not admit a change under the new one. For each merged pull request that no longer admits, Nova proposes a revert pull request and a revert card, Fin checks each one, and the release manager approves them one by one. Each turn's run history records which pull requests were read and which were changed. Reason codes move with the decisions. A deferred pull request that is now rejected, or an admitted one that is now reverted, gets its new code on the ClickUp board as well as in the thread, so the board never disagrees with what happened. When QA posts a CI readback that names only two pull requests, Fin re-derives those two under tonight's bar, not the bar in force when they were opened. Green checks alone do not admit a change the new standard defers. ## What the checks catch - An out-of-scope pull request triaged anyway because it targets the release branch - A pull request merged under the old bar that no longer admits and has no revert - A changed decision whose reason code was updated in the thread but not on the board - A readback re-derived under the bar from the day the pull request was opened ## What stays with people - Approving every merge and every revert before it touches the release branch - Granting an exception to the admission standard - Raising or lowering the bar, which stays with the release manager - Confirming CI results that look wrong, which stays with the QA lead ## Integrations in this workflow Kylon is not a CI service or a release management tool, and it does not replace either. It sits next to the code host, the board and the documents the release team already uses, and is where the triage between them happens. - ClickUp - GitHub - Google Drive - [Slack](https://kylon.io/integrations/slack) - **GitHub** holds the pull requests, their checks, the merges and the revert pull requests - **ClickUp** carries the freeze board, one card per in-scope pull request with its reason code - **Google Drive** keeps the admission standard and every amendment to it - **Slack** is where exceptions are requested, readbacks are posted and the group closeout is shared ## Where to start Your next freeze is the place to begin. Connect the repository and the ClickUp board, put the admission standard in a Drive folder the room can read, and write one rule in the room guidelines: scope is decided first under section 1, and nothing merges or reverts until the release manager approves it in the thread. > “The bar went up the night before release. By morning the two changes it no longer admitted were reverted and on the board with their reason codes.” ## Set it up with your agent Open a new Room, add your agent and paste this prompt. It connects the tools, builds the App with you and asks for your rules one step at a time, and nothing goes out until a person approves it. Set-up prompt Set up our release freeze triage desk in this Room. Take it one step at a time and wait for my OK before you move on. 1. Connect ClickUp, GitHub, Google Drive and Slack. Tell me which ones still need connecting. 2. Ask me who works this desk: the release manager, the QA lead and the engineering leads. Help me invite them to this Room. 3. Build a Freeze Board App with columns In Scope, Admitted, Deferred and Reverted, one card per in-scope pull request with its reason code. 4. Pull every open pull request against the release branch from GitHub and run each one through our scope check in Google Drive. Show me the in-scope list and flag anything triaged that looks out of scope. 5. For each in-scope pull request, propose a disposition and a reason code. If the bar has moved, re-derive every in-scope pull request including merged ones and propose a revert card for each merged pull request that no longer admits. Flag any decision whose reason code was updated in the thread but not on the Freeze Board. 6. Draft every merge, revert and board update for the release manager to approve in the thread before anything touches the release branch. Route each revert for a secondary check first. Route CI readbacks to re-derive under the bar in force now, then flag results for the QA lead to confirm. 7. Write our rules into this Room's guideline: scope is decided first under our checks, nothing merges or reverts until the release manager approves it in the thread, and CI readbacks get a secondary review. 8. After one clean freeze, offer to turn the closeout summary into an Automation. Before you start, ask me for our rules one at a time. [Get started](https://app.kylon.io/sign-up) Your first company harness. Where humans and agents run your business together. [Get started](https://app.kylon.io/sign-up) ## More Use Cases [View all](https://kylon.io/use-cases) [ ### API Deprecation Migration: Cutoff Waves That Stay Right as Integrations Move Retiring an API version runs through one Kylon room. Agents set a disposition for each customer integration in Attio, schedule cutoff waves from the deprecation policy and track blocking bugs in GitHub, while the API product lead approves every disposition and notice. Software & SaaSEngineering operationsEmail operations ](https://kylon.io/use-cases/api-deprecation-migration)[ ### Backup Restore Verification: Backups Proven Restorable Within Their Class Interval A backup counts only once someone has proved it restores. Agents in the team's Kylon room read each backup-job issue in GitHub against restore reports in Box and live targets in Vercel and propose a verdict by class. The reliability lead approves before any issue changes. Software & SaaSIT & security operations ](https://kylon.io/use-cases/backup-restore-verification)