Review Pull Requests Faster

Introduction

Pull request reviews are one of the highest-leverage activities in software delivery — but they are also easy to rush or defer when diffs are large or context is thin. Dume Cowork can read the full change set, summarize intent and impact, and surface risks so you spend time on the files and decisions that actually need human judgment.

You stay in control: Dume does not replace your sign-off; it accelerates how you get to a confident one.

How It Works

Dume Cowork runs on your desktop with access to your browser, terminal, and connected tools. For PR review, it typically:

• Ingests the diff — file-by-file summaries of what changed and likely intent
• Cross-checks patterns — common failure modes (error handling, auth, migrations)
• Maps tests — what was added or changed vs what the code paths suggest
• Produces a review brief — prioritized list of questions and recommendations

Step 1 — Open the PR in your browser

Navigate to GitHub (or your provider) and open the pull request you want reviewed. Dume Cowork can work from the visible page and linked diffs.

Step 2 — Ask for a structured review

Use a prompt that matches how your team reviews (severity, style, merge policy). See Example prompt below for a strong default.

Step 3 — Triage the output

Start with Dume’s risk summary and missing tests sections. Only then drill into individual files it flags — you avoid reading unchanged boilerplate line by line.

Step 4 — Post your human review

Copy insights into your review comment, or use them as a private checklist before approving. Adjust tone for your team’s norms.

What Dume Can Highlight

• Behavior changes — API contracts, feature flags, rollout risk
• Security-sensitive paths — auth, permissions, PII, secrets
• Data and migrations — schema changes, backfills, rollback considerations
• Performance — N+1 queries, hot paths, unnecessary work in render loops
• Test gaps — new branches without coverage, flaky patterns

Example Prompt

Review this pull request and give me:

1) Executive summary (3–5 bullets): what this PR does and who it affects
2) File-grouped change notes: API / UI / infra / tests
3) Potential bugs or regressions (ranked: high / medium / low)
4) Missing or weak tests — what I should add before merge
5) Breaking-change checklist (if any)
6) Final recommendation: Approve / Request changes / Comment only — with one sentence why

Example Review Brief (Shape)

PR #482 — Rate limiting on /api/search

Summary
• Adds per-IP limits and 429 responses for search endpoint
• Touches middleware, handler, and Redis client wrapper

Risks (medium)
• New limit may affect internal batch jobs using same IP — confirm allowlist
• 429 body shape differs from other errors — clients may parse inconsistently

Tests
• Unit tests for limiter; no integration test for Redis failure path

Recommendation: Request changes — add integration test or documented fallback when Redis is down.

Customization

Tune the review in plain language:

• "Assume reviewers care most about security and data integrity"
• "We never merge without at least one new test for new behavior"
• "Flag anything that could break mobile clients"
• "Compare this branch to main and call out anything that looks like a revert of a recent hotfix"

Tips for Best Results

• Link or paste the PR URL so Dume has full context
• Mention your stack (e.g. Next.js, Rails) so terminology matches your codebase
• For huge PRs, ask for a phase-1 summary first, then deep-dive specific directories
• Use Dume’s output as a starting draft — always apply your team’s standards and domain knowledge

When to Still Review Manually

Dume is strongest at breadth and consistency checks. You should still own:

• Product and UX judgment
• Architectural direction and long-term maintainability
• Compliance and policy decisions
• Final merge and release responsibility