Release notes

Modern changes rarely live in one pull request. A single feature now spans a backend service, a web app, a mobile client and an infrastructure repo. It's written partly by AI coding agents, and it ships behind feature flags that decide who actually sees it. Code review still happens one diff at a time, so no one sees the whole change. Reviewers check that each PR is well written, but no one checks that the PRs together deliver what was asked.

Change Review fills that gap. It starts from the ticket (a Linear issue) and gathers everything behind it: every linked pull request across every repository, the review discussion on each, and the live state of the feature flags those PRs use. Hyrax then writes one short, plain-language review of the whole change.

What a team gets on one page#

• What's changing: two or three sentences anyone on the team can read, not just the engineer who wrote it.
• 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.