Code Review

Macroscope automatically reviews every pull request for correctness. When it finds an issue, it leaves a comment on the PR describing the problem and suggesting a fix. You can also configure fully customizable AI agents that trigger on every pull request open, push, and manual check rerun by setting up Check Run Agents. You can reply to any comment, give 👍 or 👎 feedback to help Macroscope learn, or ask it to fix the issue for you.

Code Review Settings

Enabled by default on every linked repo.
Toggle on/off per repo in Settings → Repos.
Change the default for new repos in Settings → Repos → Defaults.
Set always-review labels to force a review even when automatic review is off, skip labels to prevent review even when automatic review is on, mode labels to run a review in a specific Detection Mode. Learn more about Magic PR Labels.

Go to Settings → Repos in the Macroscope web app to edit code review settings per-repo or in batch.

Detection Mode

Detection Mode tunes how Macroscope correctness review balances recall, precision, and latency. Detection Modes can be set per developer or per repo, or overridden for a single PR or single review run.

Mode	What it does
Budget	Fast, low cost bug detection. Lower bug detection and precision compared to more premium modes.
Balanced (default)	Industry leading high bug detection. Recommended for teams who use Agents to review PR comments, where the inconvenience of occasional false positives is minimal.
Precise	Similar bug detection as Balanced mode, but higher confidence findings due to additional agentic validation to reduce noise from false positives and low-value findings. Recommended for teams who prefer to spend more budget (dollars and latency) to ensure high precision findings.
Ultra	Frontier bug detection for the most consequential reviews. Leverages a much higher number of parallel agents using more advanced coding models. Useful when maximizing bug detection matters more than cost.

Each Detection Mode is billed at its own per-KB rate per review, based on the byte size of the diff that Macroscope reviews. See Pricing for the rate of each mode.

We regularly assess the performance of these modes using an internal benchmark to give you the best understanding of the tradeoffs.

Adjusting Detection Modes

There are a few ways to configure which Detection Mode is used during a review:

At the repository level: Configure the Detection Mode in Settings → Repos → Detection Mode. This applies to every PR in the repository. The default mode is Balanced.
At the developer level: Configure your personal Detection Mode in Settings → Personal → Code Review → Detection Mode. This setting allows a developer to override the Detection Mode configured on the repository for all of authored PRs.
For a single review: Comment @macroscope-app review using <mode> mode on the PR. This applies only to that review and bypasses per-review and per-PR spend caps.
For a single PR: Add one of Macroscope’s Magic PR labels (macroscope-<mode>) to the PR—for example, macroscope-ultra, macroscope-balanced, macroscope-precise, or macroscope-budget. Every review of that PR will use the selected mode until the label is removed.

PR Labels

Always-review Force a review even when automatic review is off. Configurable in Settings → Repos. Skip labels Prevents review even when automatic review is on. Skip labels take precedence over always-review labels. Configurable in Settings → Repos. Detection Mode labels Runs a review in a specified mode.

Available modes: macroscope-budget, macroscope-balanced, macroscope-precise, macroscope-ultra
Every later review of that pull request runs in the same mode until the label is removed.
A mode label acts as an always-review label. It runs a review even on a pull request that a skip label would otherwise exclude, and it triggers the Check Run Agents and Approvability check alongside the correctness review. Skip authors are the one filter it never overrides.
Removing a label does not trigger a review; the next review returns to the configured mode.
If a PR carries two labels naming different modes, no reviews will run.

Minimum Severity to Comment

Minimum Severity to Comment sets how severe a correctness finding must be before Macroscope comments on it. Findings at or above it are posted; findings below it are withheld, as are findings with no recorded severity. Choose Low, Medium, High, Critical, or Off — the default is Off, which posts everything. See Issue Severity Levels for what each level means. Set it in Settings → Repos, per repo or across several at once, and under Defaults for newly added repos. Changing the default does not move repos that already exist. Developers can set a personal floor in Settings → Personal, which overrides the repo for PRs they author; Repo Default defers to the repo. The PR author’s setting is the one that applies, not that of whoever pushed last. CLI reviews honor both tiers. Three things it does not do:

Change what the review looks for. That is Detection Mode; this only decides which findings become comments.
Apply beyond correctness. Check Run Agents and summaries are unaffected.
Hide the withheld findings. They are listed on the correctness check run, under the dropdown Filtered Issues Details with a tag [Below severity threshold], and Approvability still weighs them as risk signals.

It is separate from Approvability’s Minimum Blocking Severity, which decides which comments block auto-approval rather than which get posted.

Manually Triggering a Review

Comment “@macroscope-app review” on any PR in GitHub to trigger a review, even if automatic code review is disabled for that repo. Unless a Detection Mode is explicitly mentioned (or the author has a personal override configured), the review will use the repository’s configured Detection Mode.

A manual review is an explicit request, so it bypasses the limits that gate automatic reviews:

Max Automatic Runs per PR: a PR that has already hit its run cap is still reviewed.
Per-review and per-PR spend caps: the $10-per-review and $50-per-PR caps — or whatever your workspace has set — are not applied.

Two limits are never bypassed: your workspace’s monthly spend limit, which is an absolute ceiling whatever the trigger, and Max Reviewable File Size, so oversized files stay excluded.

Code Review Activity Log

The Code Review activity log in the Macroscope web app shows all review comments across your repositories.

Source Column and Filtering

Each comment displays a Source column indicating where the feedback originated (e.g. Correctness, Check Run Agent). Use the source filter to focus on comments from a specific review type. Filters persist in the URL, so you can bookmark or share filtered views. When exporting to CSV, the export respects your current filters.

Review Type Filtering in Feedback Metrics

Feedback metrics pages support filtering by review type. Select a specific type to see metrics for that review source, or view a cross-type overview to compare feedback across all review types.

How Reviews Appear in GitHub

Check Runs

When issues are found, the GitHub check run completes with NEUTRAL instead of SUCCESS. Check run details show per-file exclusion reasons.

Comment Resolution

Comments link to the commit where they were resolved. Macroscope re-evaluates automatically when new code is pushed.

Issue Severity Levels

CRITICAL: data loss, security breach
HIGH: production crashes, security degradation
MEDIUM: broken functionality (recoverable)
LOW: cosmetic, edge-case issues

Excluding Files with `.macroscope/ignore.md`

You can tell Macroscope to skip specific files during code review by adding a .macroscope/ignore.md file to your repository. The file uses a simplified glob pattern syntax, one pattern per line. Lines starting with # are comments, blank lines are ignored.

Setup

Create a file named .macroscope/ignore.md in your repository.
Add one file path pattern per line.
Commit and push. Macroscope picks it up automatically on the next review.

On pull request reviews, the file is read from the PR’s most recent commit, so pushing it to a PR takes effect on that PR right away; other open PRs pick it up once they include the change. Pull requests from external forks always read it from your default branch, and Macroscope CLI reviews read it from the most recent commit on the branch you’re reviewing.

Macroscope looks for three paths, in this order, and the first one that exists wins — even if it is empty: .macroscope/ignore.md, then the extensionless .macroscope/ignore, then the legacy .macroscope-ignore at the repo root. The older two are supported for backward compatibility, but .macroscope/ignore.md is the recommended location, since it consolidates all Macroscope configuration into the .macroscope/ directory.

Example

# Vendor dependencies
vendor/**

# Generated code
*.pb.go
*.generated.go

# Lock files
*.lock

# Documentation assets
docs/**/*.pdf

# Log directories
logs/**

Use ** to match across directories, * to match within a single path segment, and ? to match a single character. Patterns without a / match at any depth. Maximum 1,000 patterns.

Default Ignore Patterns

Macroscope ships with a built-in set of ignore patterns covering vendored dependencies, generated code, binary assets, and test files. These are applied automatically when no .macroscope/ignore.md file exists in your repo.

Creating your own .macroscope/ignore.md replaces these defaults rather than extending them. To preserve the defaults, copy the patterns below into your .macroscope/ignore.md file and add your own on top.

Default base patterns (vendored, generated, binary, etc.)

# === Vendored / dependency directories ===
**/.git/**
**/__pycache__/**
**/.pytest_cache/**
**/.mypy_cache/**
**/.ruff_cache/**
**/venv/**
**/.venv/**
**/node_modules/**
**/site-packages/**
**/.pnpm-store/**
**/__Snapshots__/**
**/__snapshots__/**
**/.agents/skills/**
**/.claude/skills/**
**/.github/skills/**
**/bower_components/**
**/jspm_packages/**
**/.next/**
**/.svelte-kit/**
**/.nuxt/**
**/.output/**
**/.vercel/**
**/.angular/**
**/vendor/**
**/_vendor/**
**/third_party/**
**/Pods/**
**/.bundle/**

# === Root-anchored ambiguous directories ===
build/**
out/**
env/**
ENV/**

# === Generated / build-output directories (match anywhere) ===
**/target/**
**/dist/**
**/generated/**
**/intermediates/**
**/generated_sources/**
**/generated-sources/**
**/generated-src/**
**/src/main/generated/**

# === Minified build output ===
**/*.min.js
**/*.min.css
**/*.bundle.js

# === Yarn PnP loader files ===
**/.pnp.cjs
**/.pnp.loader.mjs

# === Generated protobuf / codegen files ===
**/*_pb.d.ts
**/*_pb.js
**/*.pb.go
**/*_pb2.py
**/*_pb2_grpc.py
**/*_pb2.pyi
**/*.grpc.swift
**/*.pb.swift
**/*.sql.go
**/*.designer.cs
**/*.g.dart
**/*.pb.dart
**/*_pb.rb
**/*.d.ts
**/*.gen.ts
**/*.gen.tsx
**/*.gen.js
**/*.gen.jsx

# === Package manager files ===
**/go.mod
**/package.json
**/*.pbxproj
**/*.xcstrings
**/*.strings
**/*.properties
**/pom.xml
**/Package.swift
**/bun.lock
**/.eslintrc
**/.eslintignore

# === Lock / sum files ===
**/go.sum
**/package-lock.json
**/pnpm-lock.yaml
**/yarn.lock
**/Package.resolved

# === Images ===
**/*.jpg
**/*.jpeg
**/*.png
**/*.gif
**/*.svg
**/*.ico
**/*.webp
**/*.bmp
**/*.tiff

# === Fonts ===
**/*.woff
**/*.woff2
**/*.ttf
**/*.eot
**/*.otf

# === Media ===
**/*.mp3
**/*.mp4
**/*.wav
**/*.avi
**/*.mov
**/*.mkv
**/*.flac
**/*.ogg
**/*.srt

# === Archives ===
**/*.zip
**/*.tar
**/*.gz
**/*.rar
**/*.7z
**/*.bz2

# === Documents ===
**/*.pdf
**/*.doc
**/*.docx
**/*.xls
**/*.xlsx
**/*.ppt
**/*.pptx

# === Data / serialized ===
**/*.db
**/*.sqlite
**/*.sqlite3
**/*.parquet
**/*.avro
**/*.arrow
**/*.npy
**/*.pkl
**/*.jsonl

# === ML models ===
**/*.onnx
**/*.tflite
**/*.h5
**/*.safetensors

# === Compiled / binary ===
**/*.exe
**/*.dll
**/*.so
**/*.dylib
**/*.bin
**/*.pyc
**/*.class
**/*.o
**/*.a
**/*.wasm

# === Certificates / keys ===
**/*.cer
**/*.pem
**/*.p12

# === Platform-specific / non-reviewable ===
**/*.stringsdict
**/*.snap
**/*.adoc
**/*.arb
**/*.lock
**/*.po
**/*.fbx
**/*.log
**/*.xib
**/*.meta
**/*.kml
**/*.prefab
**/*.eml
**/*.csv
**/*.grpc.reflection
**/*.js.map

Default test file patterns

# === Go ===
**/*_test.go

# === TypeScript / JavaScript ===
**/*.test.ts
**/*.test.tsx
**/*.test.js
**/*.test.jsx
**/*.test.mjs
**/*.test.cjs
**/*.test.mts
**/*.test.cts
**/*.spec.ts
**/*.spec.tsx
**/*.spec.js
**/*.spec.jsx
**/*.spec.mjs
**/*.spec.cjs
**/*.spec.mts
**/*.spec.cts
**/*.e2e.ts
**/*.e2e.tsx
**/*.e2e.js
**/*.e2e.jsx
**/*.e2e.mjs
**/*.e2e.cjs
**/*.integration.ts
**/*.integration.tsx
**/*.integration.js
**/*.integration.jsx
**/*.integration.mjs
**/*.integration.cjs
**/__tests__/**

# === Python ===
**/test_*.py
**/*_test.py

# === Java / Kotlin ===
**/*Test.java
**/*Tests.java
**/*Spec.java
**/*IT.java
**/*ITCase.java
**/*Test.kt
**/*Tests.kt
**/*Spec.kt
**/*IT.kt
**/*ITCase.kt
**/src/test/java/**
**/src/test/kotlin/**
**/src/androidTest/**
**/src/integrationTest/**

# === Swift ===
**/*Tests.swift
**/*UITests.swift
**/*Tests/**
**/*UITests/**

# === Rust ===
**/tests/*.rs
**/*_test.rs
**/test_*.rs

# === Ruby ===
**/*_test.rb
**/*_spec.rb
**/test_*.rb

# === Generic test directories ===
**/test/**
**/tests/**
**/spec/**
**/specs/**
**/e2e/**

Reviewing Your Test Code

By default, Macroscope ignores files it identifies as test files. Identification is by file path: Macroscope matches each language’s test-file naming and directory conventions — a Go _test.go suffix, a test-like directory, and the equivalent for each other supported language. It does not read a file’s contents to decide. To opt out of test detection, add a YAML front-matter block at the very top of your .macroscope/ignore.md:

---
ignoreTests: false
---
# Everything below the front matter is unchanged: one pattern per line
vendor/**
*.lock

ignoreTests states whether to ignore tests — the same direction as every other line in the file. true means ignore them, so they are not reviewed. false means don’t ignore them, so they are reviewed like any other code.
Omitting the key, or having no front matter at all, means tests are not reviewed.
Because identification is by path and not by content, this toggle moves whole files in and out of review. A test function that lives in a file whose path does not look like a test is unaffected by it — that function is already reviewed as ordinary code.
The block is treated as front matter only if it sets a recognized key. A --- block used as a horizontal rule, or one with only unrecognized keys, is read as an ignore pattern. If a block looks like it was meant as front matter but isn’t usable, the check run conclusion says so and the review continues.

Behavior

Pattern matching is deterministic. If a file matches, it is always skipped, including on manual invocations. There is no override mechanism.
Skipped files are listed in the check run details.
Some file types are always excluded. Genuinely unreviewable, non-text files — images, fonts, archives, compiled binaries, and the like — are skipped whether or not you have an ignore file, and an include pattern never brings them back. The patterns above are the overridable defaults; this always-on exclusion sits underneath them, so replacing the defaults with your own file cannot pull a binary into review or into what you’re billed for.

.macroscope/ignore.md affects code review — on GitHub and in the Macroscope CLI — and Check Run Agents. It does not affect commit summaries, status, or the Slack agent.

How Does Code Review Work?

Macroscope reviews every file in a PR. For ten natively-supported languages, dedicated AST codewalkers build a reference graph for lower-latency reviews. All other languages — including Elixir, Starlark, C/C++, PHP, and more — are fully reviewed via Macroscope’s agentic analysis engine.

Native AST Codewalkers

For natively-supported languages, Macroscope’s code walkers parse the Abstract Syntax Tree to build a graph-based representation of your codebase. This enables deep, language-aware review with per-language model tuning and framework-specific handling (e.g. parsing .vue single-file components and Nuxt conventions). Pre-building the reference graph makes these reviews lower-latency. Languages with native AST codewalkers: Go, Python, TypeScript, JavaScript, Vue.js (including Nuxt), Java, Rust, Kotlin, Swift, Ruby.

Agentic Analysis

All other languages — including Elixir, Starlark, C/C++, PHP, and more — are fully reviewed via Macroscope’s agentic analysis engine with full cross-file codebase context. Review latency is slightly higher than native-AST-walked languages, which pre-build the reference graph.

Universal File Support

Config files, documentation, scripts, and other non-code files are also reviewed. Every file in a PR gets examined. Macroscope also uses web search during review to pull in up-to-date context, such as latest library documentation, API signatures, and deprecation notices.

Models

Macroscope’s auto-tune system tests multiple model, prompt, and parameter combinations per language to find the best config. An LLM-driven curator analyzes failures and proposes improvements each iteration. Learn more about our auto-tune system.

Getting Started

Agent

Status

Support

Code Review

Code Review Settings

Detection Mode

Adjusting Detection Modes

PR Labels

Minimum Severity to Comment

Manually Triggering a Review

Code Review Activity Log

Source Column and Filtering

Review Type Filtering in Feedback Metrics

How Reviews Appear in GitHub

Check Runs

Comment Resolution

Issue Severity Levels

Excluding Files with `.macroscope/ignore.md`

Setup

Example

Default Ignore Patterns

Reviewing Your Test Code

Behavior

How Does Code Review Work?

Native AST Codewalkers

Agentic Analysis

Universal File Support

Models

​Code Review Settings

​Detection Mode

​Adjusting Detection Modes

​PR Labels

​Minimum Severity to Comment

​Manually Triggering a Review

​Code Review Activity Log

​Source Column and Filtering

​Review Type Filtering in Feedback Metrics

​How Reviews Appear in GitHub

​Check Runs

​Comment Resolution

​Issue Severity Levels

​Excluding Files with .macroscope/ignore.md

​Setup

​Example

​Default Ignore Patterns

​Reviewing Your Test Code

​Behavior

​How Does Code Review Work?

​Native AST Codewalkers

​Agentic Analysis

​Universal File Support

​Models

Code Review Settings

Detection Mode

Adjusting Detection Modes

PR Labels

Minimum Severity to Comment

Manually Triggering a Review

Code Review Activity Log

Source Column and Filtering

Review Type Filtering in Feedback Metrics

How Reviews Appear in GitHub

Check Runs

Comment Resolution

Issue Severity Levels

Excluding Files with `.macroscope/ignore.md`

Setup

Example

Default Ignore Patterns

Reviewing Your Test Code

Behavior

How Does Code Review Work?

Native AST Codewalkers

Agentic Analysis

Universal File Support

Models