review-pr
Review a pull request for bugs, security issues, and improvements. Use when the user asks to review a PR, review changes, or check code quality of a branch.
Works with
--- name: review-pr description: Review a pull request for bugs, security issues, and improvements. Use when the user asks to review a PR, review changes, or check code quality of a branch. license: MIT --- # Pull Request Review Review the current branch's changes compared to the base branch. ## Steps 1. Determine the base branch: - Try `main`, then `master`, then ask - Run `git log --oneline <base>..HEAD` to see all commits in this PR 2. Run `git diff <base>...HEAD` to see the full diff 3. For large diffs, review file-by-file using `git diff <base>...HEAD -- <file>` 4. For each changed file, check for: - **Bugs**: logic errors, off-by-one, null/undefined access, race conditions - **Security**: injection, XSS, auth bypass, hardcoded secrets, SSRF - **Performance**: N+1 queries, unbounded loops, missing indexes, memory leaks - **Error handling**: missing try/catch, swallowed errors, unclear error messages - **Style**: inconsistency with the rest of the codebase - **Tests**: missing tests for new functionality or edge cases 5. Provide a structured review: **Summary** — What the PR does (1-2 sentences) **Issues** — Bugs, security, or correctness problems that should be fixed before merge **Suggestions** — Non-blocking improvements worth considering **Verdict** — Approve / Request Changes / Needs Discussion Be specific — reference file paths and line numbers. Suggest concrete fixes, not vague advice. $ARGUMENTS
More Code Review skills
pr-to-video
heygen-com/hyperframes
Turn a GitHub pull request (a PR URL, owner/repo#N, or 'this PR' in a checked-out repo) into a code-change explainer video — changelog, feature reveal, fix, or refactor walkthrough built from the diff, commits, and files: the input is a code change, not a website. Not a product promo (/product-launch-video) or a no-PR topic explainer (/faceless-explainer). Unclear → /hyperframes.
receiving-code-review
obra/superpowers
Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation
public-relations
coreyhaines31/marketingskills
When the user wants help with public relations, earned media, press coverage, journalist outreach, or media strategy (not pull requests). Also use when the user mentions 'PR,' 'public relations,' 'press,' 'press release,' 'press coverage,' 'media outreach,' 'pitch a journalist,' 'get featured,' 'media list,' 'media kit,' 'press kit,' 'newsjacking,' 'news hijack,' 'HARO,' 'Qwoted,' 'Featured,' 'Help A Reporter,' 'reporter request,' 'tech press,' 'TechCrunch,' 'earned media,' 'thought leadership placement,' 'op-ed,' 'guest article,' 'press contacts,' 'podcast prep,' 'going on a podcast,' 'podcast guest,' 'prep me for this podcast,' or 'how do I get press.' Use this for earned media work — finding journalists, pitching stories, newsjacking, prepping podcast appearances, and responding to press requests. For startup/SaaS/AI directory submissions, see directory-submissions. For product launches, see launch. For social-media engagement, see social. For cold-email outreach to prospects, see cold-email.
