agentleFS
Sign inStart free
malinskibeniaminmalinskibeniamin/skills/make-pr-easy-to-review/SKILL.md

make-pr-easy-to-review

Skill4 starsChanged 13 days agoMITView on GitHub

Clean noisy PR history and add reviewer guidance without changing code behavior.

6 other projects use a version of this, 6 of them edited.

Adopted by

Most recently taken up by

Used with

Projects with it also use loop-on-ci, run-smoke-tests and 1 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • cogine-aiSkill

    loop-on-ci

    Monitor PR checks and fix failures until green. Uses gh pr checks as the source of truth for PR-attached checks.

    Also in 3 projects that use this

  • MicrosoftSkill

    run-smoke-tests

    Run smoke tests to verify extension functionality in a real VS Code environment. Use this when checking if basic features work after changes.

    Also in 3 projects that use this

  • ElyzeSolutionsSkill

    control-ui

    Build or adapt a local browser/CDP harness to drive and inspect a web, IDE, or Electron UI. Use for local UI verification, screenshots, accessibility snapshots, perf profiles, visual diffs, or reproducing UI bugs.

    Also in 3 projects that use this

The file

We split this skill into the rules it gives an agent

6 rules. 1 is common, 3 are distinctive, and 2 are very specific to this project.

  • 1

    Common

    Most of the 6 edited versions we read keep these.

  • 3

    Distinctive

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Common:

    Only rewrite history when the user asks or agrees to the plan.

    line 19
  2. Distinctive:

    Prefer dependency order: schema/generated API -> core logic -> wiring -> UI -> tests.

    line 27
  3. Very specific:

    After rewrite print Original tree: $ORIGINAL_TREE and Current tree: $(git rev-parse HEAD^{tree}).

    line 29
  4. Very specific:

    Put meaningful /quantify-impact ## Proven impact (Metric | Before | After | Delta) first with command/environment.

    line 35
  5. Distinctive:

    Add accurate TL;DR; separate core from generated/mechanical files.

    line 36
  6. Distinctive:

    Never hide behavior as cleanup or bypass hooks without explicit request.

    line 41

“Common” is measured: kept by at least 6 in 10 of the 6 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Target reviewability without behavior changes; prefer PR description/review notes over code edits.

Workflow

  1. Resolve PR from URL/current branch.
  2. Inspect commits, diff size, paths, generated files, and description. For stacks, compare baseRefName, record adjacent layers, and operate only on the owning branch.
  3. Find noise: stale description, unrelated changes, mixed mechanical/logic commits, missing tests, unclear entry points.
  4. Propose before history rewrite/force-push; reorder/fold/cascade needs explicit whole-stack approval.
  5. Apply safe improvements; prove tree/diff still matches intent.

History

Only rewrite history when the user asks or agrees to the plan. Capture identity first:

gh pr view <PR> --json title,headRefName,baseRefName,state,commits --jq '{title,headRefName,baseRefName,state,commits}'
git fetch origin <headRefName> <baseRefName>
ORIGINAL_TREE=$(git rev-parse origin/<headRefName>^{tree})

Prefer dependency order: schema/generated API -> core logic -> wiring -> UI -> tests.

After rewrite print Original tree: $ORIGINAL_TREE and Current tree: $(git rev-parse HEAD^{tree}); inspect git diff origin/<headRefName> --stat. Never push unintended tree changes.

Guidance

Visual diagrams/file maps belong to /visual-recap; this skill edits PR text only.

  • Put meaningful /quantify-impact ## Proven impact (Metric | Before | After | Delta) first with command/environment. Otherwise use normal value summary; no fake empty table. Below threshold says Value not proven.
  • Add accurate TL;DR; separate core from generated/mechanical files.
  • Name risky behavior, migration order, rollout, tests, and useful issue/dashboard/design links.

Guardrails

Never hide behavior as cleanup or bypass hooks without explicit request. If notes cannot make the PR reviewable, recommend splitting it.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free