> ## Documentation Index > Fetch the complete documentation index at: https://docs.peepsai.com/llms.txt > Use this file to discover all available pages before exploring further. # Code review > Peeps posts one review on each pull request: code findings, cognitive and cyclomatic complexity analysis, and test impact analysis across web, mobile, and API. Peeps code review posts one review on each pull request in the GitHub repositories you turn on. The review has two parts that arrive together, on the lines and stories they belong to: * **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. Peeps never merges. Your team does. Peeps approves or requests changes only if you turn that on in [review settings](https://docs.peepsai.com/code-review/settings.md#verdict). ## 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: | Measure | What it counts | Why it matters | | - | - | - | | **Cyclomatic complexity** | The number of independent paths through a function: each branch, loop, and condition adds one | More paths need more tests to cover them | | **Cognitive complexity** | How hard a function is for a person to follow: nesting, breaks in linear flow, and mixed logical operators add to it | Code that is hard to read is easy to break when someone changes it | 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](https://docs.peepsai.com/code-review/complexity-check.md) 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](https://docs.peepsai.com/code-review/complexity-check.md#in-the-code-review). * **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. If the images can't be made, the comment says the same in text, without the diagram. Peeps' check on the pull request always shows it as text. The images expire after 90 days; the comment's text stays. Anyone with an image's link can open it without signing in to GitHub, because GitHub fetches images without your credentials. The links are long, random and appear only in the comment. On a private repository, whoever has an image's link can see what it shows: the verdict, the counts, file and function names, which files import which, and complexity scores. ### 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. If every finding set to **Fix** already has a suggestion, `/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: 1. **Runs the affected tests** on this branch, on every surface they cover: web, iOS and Android on this branch's build, and API. 2. **Flags changed code with no test coverage**, naming the files and the story with no test. 3. **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: | Source | What Peeps uses it for | | - | - | | **The change** | The files and lines to review | | **The story map** | Which stories the change touches, and which have no test | | **Existing tests** | Which code each test exercises | | **Past failures** | Which tests have broken on similar changes before | 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. ## Reviews on new commits With the **Every push** trigger, Peeps reviews again whenever new commits are pushed. It reads the files the push changed and lists its earlier findings on the other files again. A push that changes nothing Peeps reviews keeps the earlier verdict. The newest review on the pull request always matches its latest commit. Each review also looks again at the conversations Peeps started on the pull request, replies included. When the code now fixes an issue, a reply shows it is intended, or the issue no longer applies, Peeps resolves the conversation, replies with why, and lists it in the review. If you disagree, unresolve the conversation: Peeps doesn't resolve it again. Findings go to Linear or Jira, and to Slack or Teams, like every other Peeps result. ## Turn on code review Code review uses the [Peeps GitHub App](https://docs.peepsai.com/integrations/github.md) you already installed. An Owner turns it on one repository at a time, under **Settings** > **Code review** > **Review settings**, and chooses when it reviews and which findings it comments on. See [code review settings](https://docs.peepsai.com/code-review/settings.md). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.