---
name: turn-noisy-commits-into-clean-history-prompt
description: A prompt that makes a big or messy pull request easier to review without changing its code - regroup noisy commits in order with a tree check proving nothing changed, split mechanical from logic edits, refresh the description and point reviewers to the files that matter. Use when the user wants to tidy a PR, clean up commits before review, or a reviewer says the PR is too hard to follow.
license: MIT
metadata:
  category: coding-prompts
  tags: "git,github,pull-request"
  author: johnny-bravo
  version: "1.0"
  updated: "2026-11-03"
  status: published
  aliases: "make pr easy to review, tidy this pr, clean up commits, squash and reorder commits, reviewer guide, annotate the diff"
  source_url: "https://github.com/cursor/plugins/blob/ae5650febf4320793844c12c4adaa937f417f8da/cursor-team-kit/skills/make-pr-easy-to-review/SKILL.md"
  source_license: MIT
  copyright: "Copyright (c) 2026 Cursor"
  original_author: "Eric Zakariasson (Cursor, cursor/plugins cursor-team-kit, make-pr-easy-to-review)"
  modified: "Adapted by TheSkillVault on 2026-11-03: rewritten as one copy-paste prompt with a plan-first rule, a backup branch, a tree-identity check and a keep-the-existing-description rule; the Cursor-specific PR summary block was dropped; added steps, adapt notes, gotchas and done-when. Not the original file."
  imported_on: "2026-11-03"
---

# Turn a noisy PR into tidy commits (prompt)

A pull request with 40 commits named "wip" and formatting mixed into logic is slow and risky to review. This prompt cleans up how the PR reads, not what it does, and proves the code is untouched.

## When to use
- Your PR has noisy history: "fix", "wip", "oops" and reverts.
- Renames or formatting are mixed into the real logic change.
- A reviewer asked where to start, or the description no longer matches the diff.

## When not to use
- You only need a PR description written. Use write-pull-request-description-prompt.
- You want the code itself reviewed for bugs. Use review-code-prompt.

## Steps
1. Push your branch so a copy exists on the server, and tell your teammates if they share it.
2. Paste the prompt below into your AI coding tool in the repo, with the PR number or URL.
3. Read the plan it proposes. Say yes only to the history changes you want.
4. After it finishes, check that it showed matching tree hashes before anything was pushed.
5. Ask a reviewer whether the new layout helps. Split the PR if it is still too big.

## Prompt
```text
Make pull request [number or URL] easy to review. Do not change what the code does.

1. Inspect: commits, diff size, changed paths, generated or lock files, and the current description. Use gh if it is available.
2. List the reviewability problems you see: noisy commits, mixed mechanical and logic changes, unrelated changes, stale description, missing tests, no clear starting point.
3. Propose a plan and WAIT for my OK before rewriting history or force-pushing.
4. If I approve a history rewrite:
   - Create a backup branch first, and record the original tree: git rev-parse <branch>^{tree}
   - Regroup commits in dependency order: schema or generated code, core logic, wiring, UI, tests. Keep mechanical changes (renames, formatting) in their own commits.
   - Compare the new tree hash with the original. If they differ, stop and show me the diff. Do not push.
   - Push with --force-with-lease, never plain --force. Do not skip hooks.
5. Update the description without deleting what is already there: a TL;DR that matches the real diff, core files vs mechanical or generated files, risky changes, migration or rollout order, how it was tested, and links to issues or design docs.
6. If the PR is too big to fix with notes, recommend a split and say where.
```

## How to adapt
- Not allowed to rewrite history on your team? Tell it to skip step 4 and add reviewer notes only.
- Not on GitHub? Replace gh with your host's CLI, or paste the commit list and description.
- Want a guided tour? Ask it to add short review comments on the two or three most important lines.

## Gotchas
- A rewrite can silently drop or change code. The tree-hash check is the safety net; do not skip it.
- Force-pushing a branch others have pulled breaks their copies. Agree first.
- Never hide a behaviour change inside a "cleanup" commit.
- Do not paste tokens or private customer data into the description or the chat.

## Portability
Works with any language, any git host and any AI coding tool that can run git. In a plain chat AI, paste the commit list and diff stats and apply the plan yourself.

## Done when
- The tree hash after cleanup matches the original exactly.
- Commits tell the story in order, with mechanical changes separate.
- The description has a TL;DR, a starting point for reviewers and the risks.

## Example prompt
"Make PR 482 easy to review: regroup the commits, keep the formatting changes separate, prove the tree did not change, and update the description so reviewers know where to start."

---
Adapted from "make-pr-easy-to-review" in cursor/plugins (cursor-team-kit, MIT, Copyright (c) 2026 Cursor). Original: https://github.com/cursor/plugins/blob/ae5650febf4320793844c12c4adaa937f417f8da/cursor-team-kit/skills/make-pr-easy-to-review/SKILL.md. See LICENSE.txt.