Code review

Syntic Code can review your changes before anyone else sees them: a quick look at a diff, a careful bug hunt, a security audit, or a deep review that runs several specialist passes in parallel. Reviews run on your machine, against your working tree, a branch, or a pull request.

A review agent is not anchored by the reasoning that produced the code, so it catches things the author missed, including when the author was another agent.

Pick a review

Command	Looks for	Runs	Changes files
`/review [PR number or focus]`	General review: correctness, design, readability.	In the conversation.	No
`/code-review [level] [options] [target]`	Correctness bugs, at a depth you choose.	In a background subagent.	Only with `--fix`
`/ultrareview [--fix] [target]`	Correctness, security and test gaps, in three parallel passes, merged.	In a background subagent running a workflow.	Only with `--fix`
`/security-review [focus]`	Security problems in the changes pending on this branch.	In the conversation.	No
`/simplify [focus]`	Clean-ups: reuse, simpler logic, faster paths.	In the conversation.	Yes, it applies them

Background reviews keep the reading and checking out of your conversation. You can keep working; the findings appear when the review finishes.

What gets reviewed

With no target, a review covers what is not merged yet: unstaged and staged changes, plus commits on your branch that are not on the default branch.

Target	Example	Reviews
(none)	`/code-review`	Your pending changes.
A number	`/code-review 482`	Pull request #482 (read with `gh`). On a GitLab repository, merge request !482 (read with `glab`).
A branch or range	`/code-review feature/retries`	That branch, or commit range.
A path	`/code-review src/payments`	Changes under that path.
Anything else	`/code-review the new caching layer`	Your pending changes, focusing on what you named.

Reviewing a pull request needs the gh CLI (or glab for GitLab) installed and signed in.

`/code-review`: a bug hunt at your depth

/code-review high

Level	Reports	Findings shown by default
`low`	Only clear bugs it can show with a concrete failing case.	5
`medium`	Likely bugs: wrong results, crashes, data loss, security holes, broken edge cases. Each with the input that triggers it.	10
`high`	Adds plausible bugs, each marked uncertain with what would confirm it. Checks error paths, concurrency, cleanup and boundaries.	20
`max`	Splits the change into areas, reviews each in its own subagent in parallel, then merges.	40

xhigh is accepted as a spelling of max. With no level, the level you used last in the session is reused (medium the first time).

Each finding comes with a severity (critical, high, medium or low), file:line, what goes wrong, a case that triggers it, and the smallest fix. Style and formatting are never reported.

Options

Option	Effect
`--fix`	After the review, fix each finding with the smallest change, then run the relevant tests or build and report the result.
`--max-findings <n\|all\|default>`	Change how many findings are reported. `default` returns to the level’s own number.
`--comment`	Post the findings as comments on the pull request (needs `gh`).

The session keeps using the level and finding limit you chose last.

/code-review max --max-findings all 482
/code-review medium --fix

`/ultrareview`: three passes, one report

/ultrareview

The deepest review. A background subagent runs a workflow with three passes side by side:

Pass	Looks for
Correctness	Logic errors, wrong results, crashes, unhandled errors, broken edge cases, races, resource leaks.
Security	Injection, unsafe handling of untrusted input, secrets in code or logs, missing authorization or validation, unsafe file or network access, risky new dependencies.
Tests	Changed behavior no test covers, tests that cannot fail or test the wrong thing, missing edge-case and failure tests, flaky patterns.

A final step merges the findings: two findings about the same problem within a few lines of each other become one, keeping the higher severity and noting which passes found it. Anything unsupported is dropped. The report is sorted by severity, then file and line, and ends with a count by severity.

The passes never change files. Add --fix to apply the merged findings in your conversation once the report arrives.

/ultrareview --fix
/ultrareview 482

`/security-review`: an audit of your branch

/security-review
/security-review focus on the new upload endpoint

The review works in three phases:

Scope. It diffs your branch against its upstream and lists only what changed.
Analyze and filter. For each change it checks concrete vulnerability classes: injection, missing authentication or authorization, unsafe deserialization, path traversal, server-side request forgery, committed secrets, weak cryptography or randomness, untrusted input reaching a dangerous call, and resource exhaustion. It keeps a finding only if it can name where the untrusted data comes from, where it ends up, and why the change makes it exploitable.
Report. Each finding gets a severity, file and line, a description, the path from source to sink, and a fix. If nothing survives, it says so instead of inventing findings.

Text after the command steers the focus without replacing the method.

Review in a script or CI

Review commands work in -p runs too:

syntic -p "/code-review high" --permission-mode plan
syntic -p "/security-review" --permission-mode plan --output-format json | jq -r .result

See Run in CI pipelines for posting reviews on every pull request.

After the review

You want to	Do
Fix everything it found	Run the review again with `--fix`, or say “fix findings 1, 3 and 4”.
Read review comments others left on your PR	`/pr-comments` pulls them into the conversation.
Fix a PR’s failing checks and comments in one go	`/autofix-pr [number or url]` starts a subagent that fixes them on the branch and commits locally. Nothing is pushed.
Commit and open a PR	`/commit-push-pr`.

Make reviews fit your project

Reviews read your SYNTIC.md and rules files like any session. Put your standards there:

## Review standards
- Every public API change needs a changelog entry.
- Money is integer cents. Flag any float near a price.
- Database calls in request handlers must have a timeout.
- Do not flag missing comments on private functions.

For checks that must run on every change, not only when you ask, add a hook: for example a Stop hook that runs your linter or a secret scanner before the agent may finish. For a reusable review procedure with your own steps, write a skill or a custom review agent (the built-in code-reviewer agent is a good starting point to compare against).

Cost

Review	Rough cost
`/review`, `/security-review`	One agent reading the diff and the code around it.
`/code-review low` to `high`	One background subagent; more reading at higher levels.
`/code-review max`	Several subagents, one per area.
`/ultrareview`	Three passes plus a merge step. The most thorough and the most expensive.

Per-agent spend shows in /cost.

Troubleshooting

Problem	What to do
”unknown option”	`/ultrareview` accepts only `--fix`; `/code-review` accepts `--fix`, `--comment` and `--max-findings`.
A PR review cannot read the pull request	Install `gh` (or `glab`) and sign in, and run the review inside a checkout of that repository.
`--comment` posts nothing	`gh` must be signed in with permission to comment on the repository.
Too many low-value findings	Use a lower level, or `--max-findings 5`. Add “do not flag…” lines to `SYNTIC.md`.
The review missed something you expected	Use `high` or `max`, or name the area as the target so the review focuses on it.

Run in CI pipelines Overview