Site icon Efficient Coder

How to Automate Pull Request Reviews with GitHub Actions & Cursor CLI Integration

高效码农

Let a Robot Review Your Pull Requests: A Step-by-Step Guide to GitHub Actions + Cursor CLI

Imagine opening a pull request (PR) at 10 p.m. and waking up to concise, line-by-line feedback that flags only the bugs that could crash production—no nit-picks, no noise, just actionable advice.
This guide shows you how to wire GitHub Actions together with the Cursor CLI so that every PR gets an automatic yet human-readable review.
No extra servers, no new branches, and no external knowledge beyond what you already have in your repository.

Table of Contents

  1. What This Setup Does—and Doesn’t Do
  2. How It Works in Plain English
  3. Build the Workflow in Ten Small Steps
  4. Frequently Asked Questions
  5. Level-Up: Custom Rules Your Team Will Love
  6. Final Checklist & Next Moves

1 What This Setup Does—and Doesn’t Do

What It Does What It Never Does
Triggers on every new, updated, or reopened PR Writes or merges code on its own
Flags only high-impact issues (null-pointer dereference, SQL injection, resource leaks, race conditions) Spams you with style or formatting comments
Uses emojis to show severity: ✅ fixed, 🚨 critical, 🔒 security Blocks harmless PRs
Marks old comments as resolved Reads or leaks secrets
Optionally fails the build when a critical issue appears Modifies your main branch

2 How It Works in Plain English

  1. GitHub Actions listens for PR events.
  2. A fresh Ubuntu runner installs the Cursor CLI.
  3. Cursor reads the diff, runs its AI model, and posts line-level comments through GitHub’s public API.
  4. You decide whether the pipeline should simply warn or actually stop the merge.

That is the entire magic.

3 Build the Workflow in Ten Small Steps

Every snippet is copy-paste ready.
Estimated setup time: 30 minutes.

Step 1: Create the Workflow File

In your repository, open or create
.github/workflows/cursor-code-review.yml.

Step 2: Define the Trigger

name: Cursor Code Review

on:
  pull_request:
    types: [opened, synchronize, reopened, ready_for_review]

jobs:
  review:
    if: github.event.pull_request.draft == false
    runs-on: ubuntu-latest
  • draft == false skips work-in-progress PRs.

Step 3: Declare Permissions

permissions:
  pull-requests: write   # post comments
  contents: read         # read source
  issues: write          # link to related issues

Step 4: Check Out the PR’s Full History

    steps:
      - name: Checkout PR
        uses: actions/checkout@v4
        with:
          fetch-depth: 0
          ref: ${{ github.event.pull_request.head.sha }}

Step 5: Install Cursor CLI

      - name: Install Cursor CLI
        run: |
          curl -fsSL https://cursor.sh/install.sh | bash
          echo "$HOME/.cursor/bin" >> $GITHUB_PATH

Step 6: Tell Git Who Is Talking

      - name: Configure Git
        run: |
          git config user.name "Cursor Agent"
          git config user.email "cursoragent@cursor.com"

Step 7: Run the Review

      - name: Run Cursor Review
        env:
          CURSOR_API_KEY: ${{ secrets.CURSOR_API_KEY }}
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: |
          cursor-agent review \
            --github-token="$GITHUB_TOKEN" \
            --repo="${{ github.repository }}" \
            --pr="${{ github.event.number }}" \
            --diff-ref="${{ github.event.pull_request.base.sha }}..${{ github.event.pull_request.head.sha }}" \
            --prompt="Focus only on severe issues that could break production.  
            Limit each comment to 1-2 short sentences.  
            Use 🚨 for fatal bugs, 🔒 for security flaws, ✅ for resolved items.  
            Post at most 10 inline comments total."

Tip: Store your CURSOR_API_KEY in GitHub Secrets under Settings > Secrets and Variables > Actions.

Step 8: Optional—Block the Merge on Critical Issues

      - name: Fail Job on Critical Issues
        if: env.CRITICAL_ISSUES_FOUND == 'true'
        run: |
          echo "Critical issues detected; failing the workflow."
          exit 1

Enable this by adding BLOCKING_REVIEW=true to the previous step’s environment.

Step 9: Lock Down Permissions

Create .cursor/cli.json in the repository root:

{
  "permissions": {
    "git_push": false,
    "pr_create": false
  }
}

This guarantees the AI can read files and post comments but cannot push code or open PRs.

Step 10: Test the Flow

  1. Open any PR that changes a few lines of code.
  2. Wait for the Cursor Code Review check to turn green.
  3. Look for emoji-tagged comments on the Files Changed tab.

4 Frequently Asked Questions

Q1: How is Cursor CLI different from Bugbot?
A: Bugbot runs out of the box with zero setup; Cursor CLI lets you customize prompts, rules, and workflow triggers. Choose CLI if you need flexibility.

Q2: Will secrets leak in the logs?
A: No. GitHub automatically masks anything stored in Secrets.

Q3: Can I limit reviews to certain file types?
A: Yes. Add a line to the prompt: “Only review *.py files.” Cursor will skip everything else.

Q4: My team speaks Spanish. Can the comments be in Spanish?
A: Absolutely. Change the prompt to “Write comments in Spanish.”

Q5: How do I stop the bot from repeating comments?
A: Cursor checks existing comments and marks resolved items with ✅. You will not see duplicates for the same line.

Q6: What if the bot is too noisy?
A: Reduce the max comment count in the prompt or tighten the severity filter.

5 Level-Up: Custom Rules Your Team Will Love

Scenario One-Line Change
Different rules per branch Add if: github.base_ref == 'main' to the job and use a stricter prompt.
Auto-fix CI failures Add a second job that runs cursor-agent fix only when the build is red.
SQL-only security scan In prompt: “Focus on SQL injection risks in *.sql and ORM files.”
Comment templates Use placeholders like {{file}}:{{line}} inside the prompt for consistent formatting.
Ownership routing Combine with GitHub CODEOWNERS so each module owner gets pinged when Cursor finds issues in their area.

6 Final Checklist & Next Moves

  • [ ] Workflow file saved and committed to .github/workflows/cursor-code-review.yml
  • [ ] CURSOR_API_KEY added to GitHub Secrets
  • [ ] .cursor/cli.json created to lock down permissions
  • [ ] First test PR merged after a clean review
  • [ ] Internal wiki updated so teammates know how to read the emoji legend

Once the basics work, consider:

  • Writing a one-page “Cursor Review Legend” that explains each emoji.
  • Scheduling a monthly prompt tune-up based on the bugs you actually see in production.
  • Sharing the YAML template across other repositories in your organization.

You now have a tireless, always-available reviewer whose only job is to stop the next 3 a.m. outage before it ships.

Exit mobile version