Not every pull request risk looks dramatic. Some of the highest-impact changes are small: one package script, one workflow line, one Docker command, one deploy file, one path that should never contain secrets.
That is why AI review cannot only summarize code. A useful agent has to notice which files can change how the project runs.
A one-line change to package.json, .github/workflows, a shell script, or a Dockerfile can change what runs during install, CI, release, or deploy.
The Risk Surfaces
Most repositories have a few file classes that deserve more attention than ordinary source files. They are not always bad changes. They are simply higher leverage.
| Surface | Why It Matters | Example |
|---|---|---|
| Package scripts | Can run commands during local dev, CI, and release | `scripts.build`, `scripts.postinstall` |
| NPM lifecycle hooks | Can execute during install or publish paths | `preinstall`, `postinstall`, `prepare` |
| GitHub workflows | Can change CI permissions and release behavior | `.github/workflows/*.yml` |
| Shell and deploy files | Can run infrastructure or secret-touching commands | `deploy.sh`, `Dockerfile` |
| Sensitive paths | Can leak or modify credentials and config | `.env`, keys, tokens |
What Good AI Review Should Do
Good review is not about sounding smart. It is about finding the small changes that matter.
For an AI agent, that means separating ordinary source edits from command-affecting edits. It should be calm about a normal TypeScript utility change. It should be much louder about a package lifecycle hook or a workflow permission change.
mythos verify --ciThat command exists for the boring but important part of CI: inspect the diff, flag repo changes that can affect installs or automation, and fail when the risk is real enough to require human attention.
Why This Is Different From Generic Linting
Linters check style and syntax. Test suites check expected behavior. Security scanners check known signatures. A PR risk scanner checks the shape of the change itself.
The question is not only "does this compile?" The question is "did this PR modify something that changes what commands run, what secrets are reachable, or what the release pipeline does?"
AI agents should not be trusted because they sound careful. They should earn trust by making high-leverage changes visible before merge.
The Practical Standard
A professional CLI should make the safe path easy and the risky path obvious. That does not mean blocking every change to workflows or scripts. It means treating them as privileged surfaces.
If a PR changes a deploy file, the reviewer should see it. If it adds an npm lifecycle hook, CI should not shrug. If it touches a sensitive path, the agent should not bury that inside a friendly paragraph.
This is the realistic version of agent safety: not magic, not paranoia, just better defaults around the files that can hurt you most.