Run any Skill in Manus with one click

make-pr-easy-to-review

Stars0

Forks0

UpdatedJuly 21, 2026 at 09:17

Prepare PRs for review by cleaning noisy history, improving PR descriptions, and adding reviewer guidance without changing code behavior. Use for "make this easy to review", "tidy this PR", "clean up commits", or "annotate the diff".

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

MiquelGomezCorral

MiquelGomezCorral/my-opencode-config

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

name	make-pr-easy-to-review
description	Prepare PRs for review by cleaning noisy history, improving PR descriptions, and adding reviewer guidance without changing code behavior. Use for "make this easy to review", "tidy this PR", "clean up commits", or "annotate the diff".

Make PR Easy to Review

Prepare a PR so a reviewer can quickly understand the intent, important files, and risk. The default goal is reviewability without behavior changes.

Workflow

Resolve the target PR from the user-provided URL or current branch.
Inspect commits, diff size, changed paths, generated files, and PR description.
Identify reviewability issues: noisy commits, stale description, unrelated changes, mixed mechanical and logic changes, missing tests, or unclear reviewer entry points.
Propose a plan before rewriting history or force-pushing.
Apply safe improvements, then verify the tree or diff still matches the intended code.

History Cleanup

Only rewrite history when the user asks for it or agrees to the plan. Before rewriting:

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

Good commit groupings usually follow dependency order:

Schema/storage or generated API definitions.
Core logic.
Wiring and integration.
UI or surface behavior.
Tests.

After rewriting, verify content identity:

echo "Original tree: $ORIGINAL_TREE"
echo "Current tree:  $(git rev-parse HEAD^{tree})"
git diff origin/<headRefName> --stat

Do not push if the tree changed unintentionally.

Reviewer Guidance

When code behavior should stay untouched, prefer PR description and review notes:

Add a TL;DR that matches the actual diff.
Separate core files from generated or mechanical files.
Call out risky behavior changes, migration order, rollout plan, and test coverage.
Link issue trackers, dashboards, or design docs when they explain intent.

Guardrails

Never hide meaningful behavior changes inside "cleanup".
Never bypass hooks. Fix the failure or report the blocker.
If the PR is too large to make reviewable with notes, recommend splitting instead of polishing around the problem.

More from this repository

same repository

caveman-help

MiquelGomezCorral/my-opencode-config

Quick-reference card for all caveman modes, skills, and commands. One-shot display, not a persistent mode. Trigger: /caveman-help, "caveman help", "what caveman commands", "how do I use caveman".

2026-07-210

find-skills

MiquelGomezCorral/my-opencode-config

Helps users discover and install agent skills when they ask questions like "how do I do X", "find a skill for X", "is there a skill that can...", or express interest in extending capabilities. This skill should be used when the user is looking for functionality that might exist as an installable skill.

2026-07-210

review-swarm-upstream

MiquelGomezCorral/my-opencode-config

Review upstream changes to the local my-opencode reviewer swarm before selectively applying them. Use whenever the user asks to pull, sync, inspect, compare, or adopt reviewer or swarm changes from ~/Documents/yo/my-opencode. Never use it to install the upstream configuration wholesale.

2026-07-210

ponytail-help

MiquelGomezCorral/my-opencode-config

Quick-reference card for all ponytail modes, skills, and commands. One-shot display, not a persistent mode. Trigger: /ponytail-help, "ponytail help", "what ponytail commands", "how do I use ponytail".

2026-07-210

ponytail

MiquelGomezCorral/my-opencode-config

Forces the laziest solution that actually works, simplest, shortest, most minimal. Channels a senior dev who has seen everything: question whether the task needs to exist at all (YAGNI), reach for the standard library before custom code, native platform features before dependencies, one line before fifty. Supports intensity levels: lite, full (default), ultra. Use whenever the user says "ponytail", "be lazy", "lazy mode", "simplest solution", "minimal solution", "yagni", "do less", or "shortest path", and whenever they complain about over-engineering, bloat, boilerplate, or unnecessary dependencies.

2026-07-210

agent-prompt-writing

MiquelGomezCorral/my-opencode-config

Use whenever the task involves writing, drafting, revising, or reviewing a system prompt for an AI agent — autonomous or semi-autonomous LLM systems that use tools in a loop, including operator agents, research/sub-agents, tool-using assistants, MCP servers, multi-agent orchestrators, and coding agents. Trigger even when the user says "instructions", "system message", "agent persona", or "rules for the model", not just the word "prompt". Do NOT use for one-shot prompts (classification, single generation, single Q&A) — those need lighter prompt techniques, not the full agent skeleton.

2026-07-210

name	make-pr-easy-to-review
description	Prepare PRs for review by cleaning noisy history, improving PR descriptions, and adding reviewer guidance without changing code behavior. Use for "make this easy to review", "tidy this PR", "clean up commits", or "annotate the diff".

Make PR Easy to Review

Prepare a PR so a reviewer can quickly understand the intent, important files, and risk. The default goal is reviewability without behavior changes.

Workflow

Resolve the target PR from the user-provided URL or current branch.
Inspect commits, diff size, changed paths, generated files, and PR description.
Identify reviewability issues: noisy commits, stale description, unrelated changes, mixed mechanical and logic changes, missing tests, or unclear reviewer entry points.
Propose a plan before rewriting history or force-pushing.
Apply safe improvements, then verify the tree or diff still matches the intended code.

History Cleanup

Only rewrite history when the user asks for it or agrees to the plan. Before rewriting:

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

Good commit groupings usually follow dependency order:

Schema/storage or generated API definitions.
Core logic.
Wiring and integration.
UI or surface behavior.
Tests.

After rewriting, verify content identity:

echo "Original tree: $ORIGINAL_TREE"
echo "Current tree:  $(git rev-parse HEAD^{tree})"
git diff origin/<headRefName> --stat

Do not push if the tree changed unintentionally.

Reviewer Guidance

When code behavior should stay untouched, prefer PR description and review notes:

Add a TL;DR that matches the actual diff.
Separate core files from generated or mechanical files.
Call out risky behavior changes, migration order, rollout plan, and test coverage.
Link issue trackers, dashboards, or design docs when they explain intent.

Guardrails

Never hide meaningful behavior changes inside "cleanup".
Never bypass hooks. Fix the failure or report the blocker.
If the PR is too large to make reviewable with notes, recommend splitting instead of polishing around the problem.