Setting it up
Turn reviews on per repository in Scan automation. It is independent of your scan schedule, so enabling one never enables the other. With the toggle off, nothing is reviewed until someone asks. Press Review now on a pull request, or ask Amy or your own connected agent to review it. Its current head is reviewed, drafts included, and from then on that pull request is treated as if the toggle were on for it alone: every later push is reviewed, and replies in its threads are answered, after merge too. A draft’s later pushes wait until it is marked ready for review, as with the toggle on. Closing it without merging ends this, and a reopened pull request waits for Review now again. Asking while its current head already has a review adds nothing until its next push, and asking while a review is on its way adds nothing until that review finishes.What triggers a review
A newer push supersedes a queued review of the same pull request, so a rapid series of pushes produces one review of the final state rather than one per commit.
Scope of the review
- The new change only. Not the whole repository.
- Read with the repository around it, so a change is judged in the context of the code it touches, not as a diff in isolation.
- Aware of what was already said. A later push resumes the same review, keeping its prior rounds.
What it posts
Inline comments
Anchored to the exact line, with a severity from Critical to Info and an apply ready suggestion when the fix is a direct edit.
A status check
Reflects every issue still unresolved on the pull request, not only those of the latest push, so branch protection can block an unsafe merge.
The check follows the issues, not the pushes. Resolving an issue’s thread on GitHub updates the check, however old the pull request is. Info comments are advice, not issues: they never count as unresolved and never change the check.
Nothing else. A review never creates or changes Findings. Your findings record describes the state of your systems, and a pull request is a proposal.
Resolving an issue
Amnify does not resolve an issue on your behalf: GitHub owns the thread, and resolving it there carries over to Amnify. A person’s decision holds in both directions. Unresolving the thread on GitHub makes the issue unresolved again, whoever closed it. An issue that a person resolved on GitHub, or that Amnify accepted, is settled: Amnify never raises the same problem again on that pull request. With genuinely new evidence it replies once in the existing thread instead.
Every issue has a thread on GitHub. If GitHub refuses one of a review’s comments, the review fails and its check says so; the comments that did post stay, and Retry review reviews the pull request again.
The Pull Requests page
Pull requests are grouped by what they need from you, most recent activity first.
Every open pull request of a selected repository is always on the page, reviewed or not, including those opened before the repository was selected. Finished pull requests sit behind a link at the bottom and load as you scroll. Filter by title or number, and by one or more repositories and authors; the filters apply to every section, Finished included. When the latest push of a reviewed pull request was not reviewed, its row shows Review failed, Skipped · no credits or Latest push not reviewed beside its count of unresolved issues. In Review failed or skipped and in Not reviewed, a row carries Review now, or Retry review when reviews are on for it and its latest review failed or was skipped while they were off. A row skipped for lack of credits has no button: it is reviewed once credits are added. The page updates live as pull requests open, reviews finish and issues are resolved.
Open a pull request to see its issues, grouped into unresolved, resolved and info, without their code, which stays in the GitHub thread, and every review run with what it raised and resolved. When reviews are on for an open pull request and its latest review failed, or was skipped while they were off, Retry review reviews its current head. Otherwise, when its latest push has no review, Review now reviews its current head and turns reviews on for that pull request.
A review skipped because the organization had no credits left is not lost. Only the organization’s owner can add credits; everyone else is asked to contact them. Once credits are added, every open pull request whose latest push was skipped for that reason is reviewed automatically.
After merge or close
Merging ends the reviews but not the decisions. On a merged pull request with unresolved issues you can still resolve or unresolve an issue’s thread on GitHub, or reply to Amnify in the thread, and Amnify answers as it would on an open pull request. The code has already shipped, so a fix lands in a later pull request and Retry review is not offered. Once its last issue is settled, the pull request moves to Finished. Closing without merging settles nothing and counts nothing. Nothing shipped, so the pull request goes straight to Finished and its issues are kept as history, marked unresolved at close. Thread changes and replies on it are ignored. Reopening the pull request brings it back with its unresolved issues. A merge that leaves issues unresolved is recorded in Activity. Amnify does not hand these issues to your repository scans today.Replying to Amnify
Amnify is a participant, not a one shot bot. Reply in one of its threads or mention it anywhere on the pull request and it answers. On a repository whose toggle is off, it answers on the pull requests someone asked it to review. A round answers. It does not re-review, raises no findings and posts no new status check, though an issue it resolves updates the existing one. A burst of comments becomes one coherent answer rather than one reply per comment, and a review always takes precedence over a conversation round on the same pull request. Rounds per pull request are capped, so a long argument cannot consume unbounded work.Injection resistance
Pull request content and comments are attacker controllable, especially on public repositories.- Comment text is handled strictly as data, kept to a bounded length, and stripped of anything crafted to look like an instruction to the agent.
- Only the conversation Amnify is actually part of is read: its own threads with their replies, plus comments that mention it. Threads between other people are never ingested.
- Comments from bots, and from authors with no relationship to the repository, never trigger a round.
- The reviewer can do two things and nothing else: post comments and post replies. It cannot create findings, context or remediations, so the worst case of a successful injection is an unhelpful comment.
- A reply can only be posted into a thread on the same pull request that Amnify is already part of.