Skip to main content
Verdent includes a built-in subagent called Reviewer, whose sole responsibility is to review your code. After you finish writing, just tag @Reviewer and it will scan your changes from multiple angles and output a structured list of issues sorted by severity. Click any item you want to fix and it will automatically apply the changes—no need to write comments or search documentation manually.

​
How to Trigger Code Review

The most direct way is to type @Reviewer in chat, just like mentioning a teammate in a group: 
@Reviewer please review the authentication logic I just wrote
Reviewer automatically reads the current context and starts reviewing. You can also simply call @Reviewer without instructions—it will decide what to inspect on its own. In addition to manual triggering, the Agent can automatically invoke Reviewer as a final VERIFY step in the workflow. Once code is written, you don’t need to worry about it—the system brings Reviewer in to validate the result.

​
What the Review Output Looks Like

After review, you’ll see a structured list of Findings. Each item includes:
  • Title — a one-line description of the issue
  • Detailed explanation — why it’s a problem and its potential impact
  • File path + line number — click to jump directly to the code
  • Confidence score — how certain Reviewer is (0–1)
Issues are categorized into three severity levels:
PriorityMeaningTypical examples
P0Critical, must fixLogic errors, SQL injection, privilege escalation
P1Important, should fixMissing edge cases, potential performance issues
P2SuggestionCode style, readability improvements
At the top, a summary like P0: 1 / P1: 3 / P2: 5 gives an instant overview of severity distribution. At the end, an overall_explanation provides a high-level evaluation of the changes.

​
One-Click Fix

No need to manually edit each issue. Each Finding includes a checkbox:
  1. Select the issues you want to fix (supports select all)
  2. Click Fix
  3. Reviewer automatically applies the changes
  4. Status updates to Fix done
In some cases, if Reviewer determines the changes are low-risk, it may automatically select all issues and trigger the fix without requiring confirmation.

​
Multi-Model Collaborative Review

One of Reviewer’s most powerful features is multi-model code review—multiple AI models reviewing the same code in parallel, like having three engineers from different backgrounds independently evaluate your implementation. How to enable it Go to Settings → Chat → Reviewer → enable “Multi-model review”. Model selection modes
ModeDescription
Default modeVerdent automatically selects the best model combination based on task complexity
User modeManually choose 1–3 models (Claude, GPT, Gemini can be mixed)
You can select up to 3 models. The first is the primary reviewer; the others are secondary reviewers. More models mean broader coverage but slower execution. For simple changes, a single model is usually enough.

​
Review Rules (Custom Review Policies)

Reviewer catches many common issues by default, but every team has its own standards. Review Rules let you define your engineering guidelines directly. Where to configure Settings → Chat → Reviewer → Review Rules editor (Monaco editor with Markdown support). What you can define
  • All SQL queries must use parameterized statements, no string concatenation
  • Async operations must include proper try/catch error handling
  • React components should use memo when props are stable
  • All public APIs must validate user permissions
These rules are automatically injected into Reviewer’s context and checked during every review. Updates take effect automatically after ~500ms—no manual saving required.

​
Real-Time Workflow

During review, you can observe Reviewer’s Working Tree Stream in real time—showing which file it is reading and which logic it is analyzing. Expanding it reveals a full task tree. You can collapse it if you prefer a simpler view without affecting results.

​
Use Cases

​
Final Quality Check

After implementing complex logic, run @Reviewer to catch edge cases and subtle bugs you may have missed due to fatigue.

​
Pre-PR Validation

Run a review before submitting a pull request. Fix all P0/P1 issues first to reduce back-and-forth and ease the review burden on teammates.

​
Security Auditing

Add security-focused Review Rules (e.g. “all inputs must be XSS-sanitized”) to ensure every change is automatically checked against security policies.

​
Enforcing Team Standards

Encode ESLint rules, API design conventions, and naming standards into Review Rules so even new contributors follow team guidelines automatically.

​
Multi-perspective Architecture Decisions

For major changes, enable multi-model review to get independent evaluations and uncover blind spots.

​
Learning Tool for Beginners

Use Reviewer feedback as learning material—understanding why P0 issues matter teaches core engineering principles faster than reading documentation.

​
Notes

  • Single vs multi-model: multi-model provides broader coverage but is slower and more expensive. For simple or urgent tasks, single model is usually sufficient.
  • Free tier limitation: free users in User mode can only select models from the Eco Mode pool; premium models require a subscription.
  • Model deprecation: if a selected model is retired, it will be disabled and must be replaced.
  • Review Rules are global: they apply across all projects. If a rule is project-specific, add a note or remove it after use.
  • BYOK status: if using your own API key, expired or insufficient balance will disable corresponding models and cause review failures until updated.

​
See Also

Subagents

Learn about built-in subagents

BYOK

Use your own API keys

Plan Mode

Plan before implementing