Code Review

• Code Review
  • How It Works
  • Triggering a Review
    • From Chat
    • From Telegram or Teams
    • From GitHub (Review Request)
    • From Automations
  • What You See
    • Real-Time Progress
    • Review Verdict
    • In Your Inbox
    • On GitHub
  • Review Guidelines
  • Self-Review Detection
  • Large PRs
  • Tips
  • Status Reference

Themis can review pull requests on GitHub — analyzing code changes, checking for issues, and posting a structured review with inline comments. It acts as an always-available first reviewer that catches common problems before human reviewers look at the PR.

How It Works

1. You ask Themis to review a PR (by repo and number)
2. Themis fetches the PR diff, existing comments, and CI status
3. It analyzes the changes using your project’s review guidelines
4. It posts a GitHub review with a verdict, summary, and inline comments

The review appears as a normal GitHub pull request review — visible to all PR participants.

Triggering a Review

From Chat

Ask the agent with the repo and PR number:

“Review pipihosting/themis PR #302”

“Review the latest PR on pipihosting/web”

From Telegram or Teams

Mention the bot:

@themis review pipihosting/themis#298

@themis review pipihosting/web PR 45

From GitHub (Review Request)

Request a review from the Themis bot directly on a GitHub PR — the same way you’d request a review from a teammate.

1. Open a pull request on GitHub
2. Click Reviewers in the sidebar
3. Select Themis (or your bot’s GitHub account)
4. Themis receives the review request webhook and starts reviewing

This integrates naturally with your team’s PR workflow. Add Themis to your CODEOWNERS file or default reviewers to get automatic first-pass reviews on every PR.

From Automations

Event-triggered automations on GitHub → PR opened or PR ready for review can also trigger reviews automatically.

Example automation prompt:

Review the pull request at #.
Focus on security issues, performance regressions, and Rails anti-patterns.

What You See

Real-Time Progress

A progress bar appears in chat:

Queued → Fetching PR → Analyzing → Reviewing → Submitting

Review Verdict

Once complete, you’ll see one of three outcomes:

Verdict	Icon	Meaning
Approved	✅	Code looks good, no blocking issues
Changes Requested	⚠️	Issues found that should be addressed before merging
Commented	💬	Observations posted without blocking the PR

In Your Inbox

Reviews appear under Signals > Reviews in your inbox. Each entry shows:

• PR title and repo (owner/repo#number)
• Verdict badge — Approved, Changes Requested, or Commented
• Review summary — structured markdown with key issues, positive aspects, and recommendations
• Inline comments — specific code-level feedback organized by file and line
• Reasoning log — the agent’s analysis process
• Metadata — cost and status

On GitHub

The review is posted as a standard GitHub pull request review:

• Review body with a structured summary (Key Issues, Positive Aspects, Recommendations)
• Inline comments attached to specific lines in the diff
• Verdict set as Approve, Request Changes, or Comment

All PR participants see the review in their normal GitHub workflow.

Review Guidelines

If your project has a .claude/skills/reviewing-code/ skill, Themis uses it during reviews. This skill can define:

• Security checklist items to verify
• Project-specific anti-patterns to flag
• Code style expectations
• Review quality standards

Without a custom review skill, Themis uses general best practices for the detected language and framework.

Self-Review Detection

GitHub doesn’t allow PR authors to approve or request changes on their own PRs. If Themis’s GitHub token belongs to the PR author (common in automated workflows), it automatically downgrades the verdict to Comment instead. The review content stays the same — only the verdict type changes.

Large PRs

For large pull requests, Themis fetches the diff in pages to handle any PR size. Each page includes annotated line numbers so inline comments land on the correct lines.

Very large PRs (1000+ changed lines) may take longer to review. Consider breaking large changes into smaller, focused PRs for faster and more thorough reviews.

Tips

Automate reviews on PR creation for instant feedback. Developers get a first-pass review within minutes of opening a PR, even outside business hours.

Combine with human review. Themis catches mechanical issues (security, style, N+1 queries) so human reviewers can focus on architecture and design decisions.

Check CI status first. Themis reads CI results as part of its review. If tests are failing, the review will flag that — no need to review code that doesn’t pass CI.

Status Reference

Status	Meaning
Pending	Queued for processing
Fetching PR	Loading PR metadata and file list
Analyzing	Reading diff with line-by-line annotations
Reviewing	Agent analyzing code and writing feedback
Submitting	Posting review to GitHub
Approved	Review posted — code approved
Changes Requested	Review posted — changes needed
Commented	Review posted — observations only
Failed	Error occurred — check error message
Dismissed	Review was dismissed on GitHub