make-pr-easy-to-review

Cleans up pull request history and descriptions to improve reviewer comprehension.

3|Updated Apr 8, 2025
One-click install
npx skills add https://github.com/ZanzyTHEbar/dragonarchy --skill make-pr-easy-to-review-zanzythebar
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: make-pr-easy-to-review
Source: https://github.com/ZanzyTHEbar/dragonarchy/tree/main/packages/opencode/.config/opencode/skills/make-pr-easy-to-review
Command: npx skills add https://github.com/ZanzyTHEbar/dragonarchy --skill make-pr-easy-to-review-zanzythebar

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Pull requests often arrive with noisy commit history, stale descriptions, and mixed changes that make review slow and error-prone. This Skill prepares a PR so reviewers can quickly understand intent, important files, and risk without changing code behavior. ## Core Features & Use Cases - History Cleanup: Reorganizes commits into logical groups (schema, core logic, wiring, UI, tests) and verifies tree identity after rewriting so no code changes slip in. - Reviewer Guidance: Adds TL;DR summaries, separates generated files from core logic, and calls out risky changes, migration order, and test coverage in the PR description. - Guardrails: Proposes a plan before force-pushing, refuses to hide behavior changes in cleanup, and recommends splitting oversized PRs instead of polishing them. - Use Case: You have a branch with 20 messy commits and an outdated PR description. Ask the Skill to tidy the PR, and it will propose a commit grouping, rewrite history safely, verify the tree matches, and rewrite the description with reviewer entry points. ## Quick Start Ask the assistant to make the current branch's pull request easy to review by cleaning up commits and improving the PR description.

Frequently Asked Questions about make-pr-easy-to-review

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I clean up commit history before a PR review?

Fetch the head and base branches, record the original tree hash, then group commits in dependency order: schema, core logic, wiring, UI, tests. After rewriting, compare the new tree hash against the original to confirm no code changed before pushing.

How do I make a large pull request easier to review?

Add a TL;DR matching the actual diff, separate generated or mechanical files from core logic, and call out risky changes and test coverage in the description. If the PR is too large for notes alone, split it into smaller PRs instead.

Is it safe to force-push after rewriting PR history?

It is safe only after verifying content identity by comparing git tree hashes before and after the rewrite. The Skill proposes a plan first and refuses to push if the tree changed unintentionally.

Does this work with the GitHub CLI and jj version control?

Yes, it uses gh pr view to inspect PR metadata and standard git commands for history work. It also respects repository-preferred VCS workflows, including jj where configured.

When should I not rewrite PR commit history?

Avoid rewriting when the user has not agreed to it, when it would hide meaningful behavior changes inside cleanup, or when hooks would need bypassing. In those cases, improve the PR description and reviewer notes instead.