Understand PR
Review a PR the way a seasoned maintainer would, build an independent model before...
Install
npx skills add mastra-ai/mastra --skill understand-pr -g -a claude-code -y- Repository
- mastra-ai/mastra29.3k
- Category
- Git and review
- Updated
- 3d ago
- License
- See repository
- Context cost
- Mediumabout 3,000 tokens
- Runs scripts
- No, instructions only
What it does
Review a PR the way a seasoned maintainer would, build an independent model before seeing the diff, investigate the implementation and history, verify material claims, and return a concise briefing. Use for any PR review, self-review, or re-review.
Understand PR
Review the PR as a maintainer deciding whether the change belongs in the codebase. Help the human understand it without turning the review into a walkthrough. Run uninterrupted to a concise front page. For draft PRs authored by the user or a confirmed user-owned bot, follow gh-review's autonomous posting exception and finish the review without an approval checkpoint; otherwise stay available inside the goal until the human says the review is finished.
The PR follows ARGUMENTS: at the end of the objective. If absent, infer it from the conversation or checked-out branch.
What matters
- Your design before theirs. Establish the required outcome and real constraints from the problem and base branch, then choose the simplest design that satisfies them, not a restatement of the author's proposal. Compare the PR against that reasoning. Agreement is valid when independently justified; disagreement needs evidence, not merely a different preference.
- Depth proportional to risk. Blast radius, irreversibility, uncertainty, and public-contract impact determine how hard to look, not a fixed checklist.
- Verify material claims. Read code deeply and run the smallest useful probes. Findings need real evidence and pointers; process compliance is not evidence.
- Judgment over coverage theater. Find the core decision, root cause, and meaningful risks. Do not manufacture findings or run work merely to look thorough.
- Complete, not padded. Every request you have evidence for is in the review; length follows from findings, never the other way around. Lead with what matters most and cut narration, not requests. Preserve supporting detail in one review file for follow-up questions.
Review record
Use one ignored file: .mastracode/scratch/reviews/<owner>-<repo>-<pr>.md. Never stage or commit it.
Before reading the diff, write a short Pre-diff model containing:
