How to Review PRs Using Cubyts in Git Repositories?

Introduction

This guide explains how to review pull requests (PRs) using Cubyts directly within your Git repositories. With PR analysis enabled, Cubyts evaluates changes and posts concise, risk-focused comments in the PR—helping reviewers focus on what matters most while retaining full human judgment. Cubyts accelerates reviews; it does not replace reviewers.

Prerequisites

• A Git repository connected to Cubyts (for example, GitHub, GitLab, or Azure DevOps)

• Access to a Cubyts workspace

• Permissions to configure flags and review PRs

Step-by-Step Guide

Step 1: Enable PR Analysis in Cubyts

1. Open Flag Settings in your Cubyts workspace.

2. Expand PR and Code Branch Analysis.

3. Choose either PRs or Both options for this workflow. 

4. Define the time span for which PRs and branches should be analyzed.

These are one-time configurations that determine how and when analysis appears to reviewers.

Step 2: Enable Pre-Merge Visibility in Git

• Turn on View Flag Issues pre-merge.

• This ensures Cubyts writes its findings back to the Git repository as PR comments before merge.

With this enabled, reviewers see Cubyts insights at review time.

Step 3: Open a Pull Request

• Once PR analysis is enabled, Cubyts automatically evaluates new and updated PRs.

• Results are published directly as comments inside the PR.

These comments act as review-time signals—they guide attention without forcing decisions.

Step 4: Review Cubyts PR Comments

Cubyts posts concise, high-level summaries focused on risk and governance, including:

• Severity grouping (Critical, High, Medium)

• Code quality and structure

• Dependencies and logical risks

• Governance-related concerns

This helps reviewers prioritize quickly and avoid low-value manual inspection.

Step 5: Use Dependency Analysis Summaries

• Cubyts may post a Dependency Analysis Summary as a PR comment.

• This highlights dependency-related risks that could impact:

  • Stability

  • Maintainability

The summary is intentionally brief to keep reviews efficient.

Step 6: Deep Dive Only When Needed

• PR comments include deep-dive links back to Cubyts.

• Use these links to:

  • Inspect file-level dependency flags

  • Review detailed code issues

  • Analyze relationships and impact
    
    

Principle:
 Signal in Git → Depth in Cubyts → Judgment with the Reviewer

Step 7: Review the Cubyts Code Review Summary

• Cubyts also posts a Code Review Summary highlighting:

  • Syntax errors

  • Logical flaws

  • Naming inconsistencies

  • Maintainability concerns

• The summary includes:

  • Clear severity distribution

  • Recommendations when immediate action is required

  • Links for deeper investigation in Cubyts

This provides a reviewer-friendly overview without overwhelming detail.

Step 8: Complete the Review with Human Judgment

• Reviewers assess Cubyts findings alongside:

  • Business context

  • Design intent

  • Team standards

• Approvals and merge decisions remain entirely with human reviewers.

Cubyts accelerates insight; reviewers retain accountability.

Optional: Use PR Analysis as Passive Signals

• Git integration is optional.

• Teams that prefer not to surface signals in PRs can:

  • Use code flags as passive indicators

  • Consume insights via Health, Reports, and Delivery Metrics in Cubyts

This supports governance without changing reviewer workflows.

Best Practices

• Enable PR analysis to reduce cognitive load during reviews.

• Focus first on high-severity signals.

• Use deep dives selectively—only when context is required.

• Reinforce that Cubyts augments reviews; it doesn’t automate approvals.

Conclusion

Cubyts enhances PR reviews by surfacing the right signals at the right time—directly in Git—while preserving human judgment. Whether used actively in pull requests or passively as governance signals, Cubyts helps teams achieve faster reviews, stronger consistency, and more predictable delivery outcomes.

Video link: https://www.loom.com/share/550cb57c74be45709a49b88a51c638e1