Summarize a pull request for the team

Cursor reads a PR and writes a summary a non-author can read: what changed, why, and what to test.

A short summary you can post on the PR or in Slack: the change, the reason, and the test cases.

1. 1

   Run this after the PR is ready

   Wait until the author says it is ready for review. A summary of a draft is not useful.

2. 2

   Post the summary as a comment

   Put it at the top of the PR conversation so reviewers see it first. Do not replace the PR description.

3. 3

   Share it in Slack if the PR is high-risk

   For production changes or refactors, paste the summary in your team channel with the PR link.

Summarize this pull request for someone who was not in the room when it was written.

Read the PR diff, the description, and any linked issues. Then write a summary with:

1. What changed: one paragraph describing the change in behavior a user or another engineer would see
2. Why: one sentence on the reason for the change (bug, feature, refactor, dependency)
3. Files touched: list the main files, grouped as "core logic," "tests," and "config/docs"
4. What to test: 3-5 test cases that would catch a regression
5. Residual risk: one thing that could still go wrong after this merges, or "none apparent"

Do not rewrite the pull request. Do not add praise. If the PR description is missing, say so and write the summary from the diff alone.

The summary is not the approval. You still review the code yourself.

Sample case written by Hidden Logic Lab. Not affiliated with Cursor.