Release notes

Modern changes rarely live in one pull request. A single feature can span a backend service, a web app, a mobile client and an infrastructure repo. Code review still happens one diff at a time, so no one sees the whole change. Each reviewer checks that their PR is well written; no one checks that all of them, together, do what the ticket asked.

Change Review fills that gap. It starts from an issue (for example, in Linear) and gathers everything behind it: the intent and acceptance criteria in the ticket, every linked pull request across every repository, and the review discussion on each. Hyrax then writes one review of the whole change that answers a single question: is this the change we meant to make?

What a team gets on one page#

• Plain-English summary: the whole change, across every PR and repo, in two or three sentences. Anyone on the team can follow it without opening a diff.
• Asked vs. built: every requirement in the ticket, checked against the code as met, partly met, not met or needs a person. Teams can add their own acceptance criteria in plain words.
• Before and after: what a user or admin will notice, written as a diff in plain English, with sketches of affected screens or system diagrams for backend changes.
• How it ships: which flags gate the change and where each is switched on today, including flags the code reads that were never created.
• Sources for every sentence: each statement links to the PR, ticket or flag it came from, so nothing has to be taken on trust.

Why it matters now#

• AI writes more of the code. Line-by-line review doesn't scale when changes arrive faster than people can read them. Change Review raises the question to "is this the change we meant to make?"
• Work spans repositories. A feature is only done when every part of it is. Change Review sees all the parts at once, including the PR that hasn't merged yet.
• Shipping is decoupled from merging. With flags, "merged" doesn't mean "live". Change Review shows who can see the change today, not just whether the code went in.
• More people need to understand the change. Product managers, QA, support and leadership get a readable account of what's shipping, without reading diffs.
• It helps without getting in the way. Change Review is advisory: it never blocks a merge. It sits alongside existing code review and gives the team a shared picture of the change before it reaches customers.