- Code. Bugs, security issues, and risky changes, with inline comments and suggested fixes. Static analysis measures the cognitive and cyclomatic complexity of the code you changed.
- Test impact analysis. The user stories the change touches across web, mobile, and API, how their tests did on this branch, and what still has no test.
Code findings
The agent comments on the lines that matter and suggests the fix. Each finding has a type and a severity, such as Security · High or Bug · Medium, and you can apply a suggested change or send the finding to Linear or Jira.Complexity analysis
The review runs static code analysis on the functions your change adds or edits, and reports two measures:
A function with high complexity is flagged on the lines where it is defined, so reviewers can see where a change is risky and where tests matter most.
The review comment
Each review posts one summary comment. From the top:- The review card, an image that follows your GitHub theme, light or dark. It shows the verdict, one sentence on why, and the numbers, such as
18 of 19 files read · 2 of 4 standards read. Every number comes from the review itself. After a push, it counts the files read across reviews, and how many were read since the last one. - What changed: the reviewer’s summary of the change and, when it can be drawn, Recorded relationships, a diagram of which changed files import which, with new files and files with an open issue marked. It is drawn only when every import between the changed TypeScript or JavaScript files resolves. A large pull request is drawn as folders in lanes.
- Issues, with their count: new findings, earlier issues still open on their threads, and functions the complexity check blocks on, which come first. Each finding shows its severity, its title and what it breaks, then its file and line, and View comment when it has a line comment.
- Complexity, folded: the functions this pull request changed and their scores, when one ends over a limit or was lowered. See the complexity check.
- What Peeps traced, folded: the reviewer’s own reading of the change.
- Review scope, folded: what it read, what it didn’t and why, and the standards it read.
Line comments
Up to eight findings also get a comment on their lines, when the line is in the diff: the severity and title, what it breaks, what the reviewer found, and under Fix, how to fix it. A link at the bottom leads back to the summary. Findings without one have their details in the summary. When the fix is a small, exact change to lines this pull request added, the comment may carry it as a GitHub suggestion: click Apply suggestion to commit it.- It replaces exactly the lines the comment is on, and adds no invisible characters.
- Never on CI configuration, a dependency manifest or a lockfile, and at most three in one file.
- For a finding set to Fix with automatic fixes on, Peeps fixes it instead.
/peeps fix says so: commit the suggestions from their line comments.
To review the latest push again, comment /peeps review on the pull request. It needs write access to the repository.
Test impact analysis
Test impact analysis (TIA) maps the change to the user stories it touches, then:- Runs the affected tests on this branch, on every surface they cover: web, iOS and Android on this branch’s build, and API.
- Flags changed code with no test coverage, naming the files and the story with no test.
- Drafts the missing tests from the story, such as an API test that creates, cancels, and fetches an order. Drafts wait for your team’s review.
It reviews your app, not just the diff
The review reads more than the change:
That is how a change to the API can run a mobile test. If the mobile reorder flow reads the same order response as a changed endpoint, and it has broken on order changes before, TIA runs it. A review of the diff alone would not.