Skip to content

Assign Reviewer

Find the people behind the code.

The owner. The author. The person who fixed it last time.
Find the right expertise, see the workload, and decide who to ask.

Book a demo See the connection

Every recommendation has a history.

GitHub Handle partial refunds billing-api / PR #412
The changed code 3 files
billing/refunds.pyRefund calculations
+24 -8
payments/retry.pyRetry behavior
+12 -4
tests/test_refunds.pyRegression coverage
+38 -0

OWNERS.md + contribution history

The people who know it Open reviews

Why Maya?

Owns the refund module and fixed its last rounding regression.

Ownership + prior bug fix

What to inspect

Refund totals, currency rounding, and retry behavior.

Current queue2 open reviews

Relevant context. A lighter queue.

Recommended, not requested. The final choice stays with you.

Expertise is not
a job title.

A familiar name can get you a quick approval.
The right expertise brings meaningful scrutiny.

Beyond your usual circle.

Asking friends by default can encourage rubber-stamping. Choose people for their knowledge of the changed code, with a clear reason to inspect it.

Beyond the busiest lead.

Sending every PR to the tech lead or senior architect creates a bottleneck. Find qualified teammates with more capacity instead of leaving their expertise unused.

Beyond manual detective work.

Reconciling git blame, the PR diff, and past discussions is hard. CloudAEye connects those patterns with ownership and review queues to surface relevant candidates.

Different changes.
Different kinds of context.

Poor reviews can let regressions reach production, damage customer trust, and contribute to churn. Match each change to people who can challenge it.

Find the best-fit reviewer.

Reviewer selection · For developers opening a pull request

Recommend people by ownership, code familiarity, and contributions. See why each person fits and what they should inspect, not just a name on an ownership list.

  • Code ownershipThe relevant area
  • Contribution historyWhy this person
  • Review focusWhat to inspect
Explore a recommendation

Bring experts to high-risk changes.

Domain expertise · For sensitive and production-critical code

Match security-sensitive logic, critical services, shared components, and complex flows to people with relevant ownership and experience.

  • AuthorizationAccess boundaries
  • Complex control flowEdge cases
  • Shared componentsService interactions
Start with a pull request

Recover the code's human history.

Prior contributions · For changes with hidden context

Find the developers who wrote, reviewed, or fixed the affected code. Their experience can help uncover subtle bugs, regressions, and design inconsistencies.

  • Previous authorsOriginal implementation
  • Past reviewersEarlier review context
  • Bug fixersKnown failure modes
See the evidence behind a name

Balance expertise with capacity.

Review workload · For teams with overloaded leads

Prefer qualified reviewers with lighter queues. Distribute work without sending every PR to the same tech lead or senior architect.

  • Knowledge of the changeRelevant expertise
  • Existing review queueCurrent workload
  • Qualified alternativesRoom to review
Compare fit and review queues

Cover a cross-team change.

Multi-component coverage · For changes across team boundaries

Map affected files, components, and responsibilities to complementary reviewers. Make clear who should inspect each area and the behavior between them.

  • Changed modulesOwners and maintainers
  • Shared interfacesCross-team context
  • Review responsibilitiesA focus for each person
Explore review coverage

Start without an ownership file.

Claude Code plugin · For repositories missing ownership context

Use git history to generate an initial root OWNERS.md in your local working tree, then use it for recommendations. The hosted PR integration does not create this file in your checkout.

  • Starting evidenceRepository git history
  • Generated fileRoot OWNERS.md
  • Local working treeNo automatic commit or push
Start in Claude Code

Spend less time finding a reviewer.

Review preparation · For developers piecing together the evidence

Connect git blame, the PR diff, ownership rules, and earlier PR discussions without a manual search. Bring expertise and workload together so the review can get moving sooner.

See the connected context
Diff + git blame Earlier PR discussions Ownership + review queues
Informed
shortlist

Keep the final decision human.

Explicit confirmation · For every review request

Read the rationale and inspection focus, then consider the team's circumstances. Reviews are requested only after you explicitly name the people. Appearing in a recommendation is not permission to send a request.

See the confirmation workflow
  1. Read the recommendationWhy each person fits and what they should inspect
  2. Name the people to askYour explicit selection, not an automatic assignment
  3. Request only after confirmationRecommendations and review requests stay separate

CloudAEye connects the dots.
You make the call.

A recommendation is the start of a decision, not permission to act on your behalf.

  1. 1

    Ask about an open PR

    Start with the change and its affected code.

  2. 2

    Read the recommendation

    Compare the fit, review focus, and current queue.

  3. 3

    Name the people to ask

    Reviews are requested only after your explicit choice.

GitHubHandle partial refunds#412
YOU@cloudaeye /assign_reviewer
CloudAEye

Maya brings refund ownership. Jon brings context on the retry path.

People to include in your preview
No reviewers selected
No automatic requests. No implicit selection.

The next review.
The right people.

Start in Claude Code or on your GitHub pull request.

Claude Code/cloudaeye:assign-reviewer #412
Pull request@cloudaeye /assign_reviewer

Get started Read the documentation

A few things worth knowing.

What happens when ownership is missing?

The Claude Code workflow can create an initial OWNERS.md at the repository root using git history. That file stays in your local working tree, with no automatic commit or push. The hosted PR integration does not create files in your local checkout.

Where is the pull request command available?

The GitHub App workflow requires repository write access and the enabled Assign Reviewer feature. Token-only, GitLab, and Bitbucket connections are not supported for this workflow. After choosing reviewers, confirm with @cloudaeye /assign_reviewer --apply @alice @bob, using chosen names from the latest recommendation on this PR.

Does this replace the review itself?

No. It recommends people and the areas they should inspect. It can reuse existing risk, slop, and review evidence rather than running those analyses again. The selected people still perform the review.

What if a review request has an uncertain outcome?

Check the PR before submitting another confirmed request. An interrupted job does not automatically resend the write, and queue completion is not proof that reviews were requested.