Copilot and Claude review each PR for bugs, missing tests and risky changes before a human looks, so reviewers can focus on design.
Senior engineers spend hours a week pointing out the same issues in pull requests: unhandled errors, missing tests, leftover debug code. Small PRs wait a day for a first look because everyone is busy. By the time a human reviews, the author has moved on, and the context switch costs both sides.
In the repository settings, open Rules > Rulesets and add a branch ruleset for your default branch with 'Automatically request Copilot code review' enabled. Copilot now reviews every new PR and each new push to it.
Create .github/copilot-instructions.md with your team conventions: error handling style, logging library, test file naming. Keep it short and specific so the comments stay focused.
Create .github/workflows/claude-review.yml triggered on pull_request (opened, synchronize). Use anthropics/claude-code-action with ANTHROPIC_API_KEY stored as a repository secret and pass the risk summary prompt below.
Add paths-ignore for docs/** and **/*.md, and an if: condition that skips PRs labelled 'trivial'. This keeps API spend near $20 a month for a team of five.
The Claude comment ends with RISK: LOW, MEDIUM or HIGH. A follow-up job checks for RISK: HIGH and posts the PR link to #eng-review using slackapi/slack-github-action.
Ask reviewers to react with a thumbs-down to unhelpful bot comments. Once a week, turn the most common complaints into new lines in the instructions file.
You are a senior engineer doing a first-pass review of pull request #{{pr_number}} in {{repo_name}}.
Read the full diff and the PR description. Then write one review comment with three sections:
1. What changed: two sentences in plain language.
2. Issues: a numbered list of concrete problems (bugs, unhandled errors, missing input validation, missing or weak tests, leftover debug code). For each, give file:line and a one-line fix. Skip style nits that a linter would catch.
3. Questions for the author: up to three, only if something is genuinely unclear.
End with exactly one line: "RISK: LOW", "RISK: MEDIUM" or "RISK: HIGH". Use HIGH for changes to auth, payments, database migrations or anything that deletes data.When reviewing pull requests in this repository: - Flag any async function that does not handle a rejected promise. - Flag new API routes that do not validate the request body with the zod schemas in src/schemas. - Flag console.log calls outside the scripts/ folder. - Flag new modules in src/lib that have no matching test file in tests/. - Do not comment on formatting; Prettier handles it. - Prefer one clear comment per issue over several small ones. - When suggesting a fix, show the corrected code, not just a description.
Plan, execute and review a cross-cutting refactor in small batches, with Claude Code making the edits and GitHub Copilot reviewing each PR.
Score every demo request against your ICP, update HubSpot and ping the right rep in Slack within a minute of the form submit.
Every new Zendesk ticket gets a category, priority and sentiment tag plus a draft reply in an internal note before an agent opens it.