The PR touches 30 files, a teammate wants a review today, and you want a first pass before reading it line by line. Verboo Code ships two commands for this: /review, which reads a GitHub pull request and writes a general review, and /security-review, which looks only at your current branch for high-confidence vulnerabilities.
What does /review do in Verboo Code?
It tells the agent to act as a code reviewer using the GitHub CLI: it lists open PRs with gh pr list, opens the chosen one with gh pr view, reads the diff with gh pr diff and writes a review in sections. Everything runs locally, on your machine, with the model you picked for the session.
The review covers five points, set in the command's prompt: code correctness, project conventions, performance impact, test coverage and security. The output is a PR overview, a quality analysis, specific suggestions and risks.
How do I review a pull request with /review, step by step?
/review needs gh installed and signed in, because that is what fetches the PR. Do this once per machine:
# check whether gh is signed in
gh auth status
# if it is not
gh auth loginThen, inside the session, in the repository folder:
# no number: the agent runs gh pr list and shows open PRs
/review
# with a number: goes straight to PR 42
/review 42
Whatever you type after the command name goes into the prompt as the PR number. If you pass text instead of a number, the agent gets that text in its place, so stick to the number and ask for extra focus in the next message, for example "now look only at the migrations".
What is the difference between /review and /security-review?
/review does a broad review of a GitHub PR. /security-review reviews the branch you are on, with no open PR needed, and looks only for vulnerabilities with a real chance of exploitation.
/review | /security-review | |
|---|---|---|
| What it reviews | A GitHub pull request | The changes on the current branch |
| Where the diff comes from | gh pr diff <number> | git diff origin/HEAD... |
Needs gh | Yes, signed in | No, just git |
| Needs an open PR | Yes | No |
| Focus | Correctness, conventions, performance, tests, security | Only new vulnerabilities introduced by the branch |
| Noise filter | None explicit | Drops findings with confidence below 8 (1 to 10 scale) |
| Allowed tools | The session's, per your permissions | Pre-approved: git diff, git status, git log, git show, git remote show, Read, Glob, Grep, LS and Task |
How do I run a security review before opening the PR?
On the branch with your changes, type /security-review. Before calling the model, the CLI runs four git commands and pastes their output into the prompt:
git status
git diff --name-only origin/HEAD...
git log --no-decorate origin/HEAD...
git diff origin/HEAD...With the diff in hand, the agent starts a subtask to find vulnerabilities and, for each finding, another subtask in parallel just to filter false positives. Only what passes with confidence 8 or higher stays. Each item comes with file and line, severity (High, Medium or Low), a category such as sql_injection or xss, an exploit scenario and a fix recommendation.
The prompt also excludes, on purpose, categories that create a lot of noise: denial of service, rate limiting, secrets stored on disk, outdated libraries, test-only files and memory issues in memory-safe languages. If you need to review one of those, ask in the conversation, outside the command.
Gotcha: without origin/HEAD, /security-review has nothing to compare against. All four commands use origin/HEAD as the base. A repository created with git init and connected to a remote later often lacks that ref, and git answers fatal: ambiguous argument 'origin/HEAD...'. Create the ref pointing to the remote's default branch:
# detect the remote's default branch and write origin/HEAD
git remote set-head origin --auto
# check
git rev-parse --abbrev-ref origin/HEADThe second line should return something like origin/main. Run /security-review again.
How do I bring the PR comments into the session?
Use /pr-comments. It finds the current branch's PR with gh pr view --json number,headRepository, fetches the general comments and the review comments through the GitHub API and shows everything grouped by thread, with file, line and the diff hunk of each comment.
The loop that closes the cycle: /pr-comments to see what the reviewer asked for, a request from you for the agent to fix it, and /diff to check what changed before committing.
Can I rely only on the agent's review?
Not as the only review. /review is a first pass: it flags the obvious, summarizes the PR and finds what jumps out of the diff. It reads the diff that gh returns, so context outside the diff, such as a business rule in another module, only comes in if the agent decides to open that file. Ask for it directly when it matters: "open src/billing/ and check whether this change breaks the discount calculation".
To standardize what the agent checks in every review (test names, error patterns, off-limits folders), write the rules in AGENTS.md with /memory. They enter the context of every session, review sessions included.
A good review needs the agent to open the files around the diff, not just the diff. On Verboo Code plans run with unlimited tokens, so asking it to read the whole module before giving an opinion costs the same as reading only the changed lines.
