Git review
🔧 My DEV env setup
npx -y skills add GrimLink/dotfiles --skill git-reviewAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 8 stars8 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Review code changes, pull requests, or merge requests for bugs, code quality, security, and maintainability. Use when asked to review a PR, MR, diff, or set of changes. Also handles GitHub PRs and GitLab MRs.
SKILL.md
2.0 KB, as published. Nobody here has run it
1. Fetch the changes
If a GitHub PR URL or number is provided, fetch details and diff via gh:
gh pr view <number-or-url> --json title,body,additions,deletions,files,reviews,statusCheckRollup,headRefName,baseRefName
gh pr diff <number-or-url>
If gh cannot access the repository, a GitLab MR is referenced, or no URL is given, ask the user to paste the diff directly. A local diff also works:
git diff main...<branch>
2. Check CI status
If fetched via gh, check statusCheckRollup. If any checks are failing or still pending, inform the user and stop — do not review until CI is green.
3. Review the changes
Review the diff thoroughly and critically. Do not just validate what is there — look for what is wrong or missing.
Cover the following areas, skipping any that are not relevant:
- Bugs and logic errors: incorrect assumptions, edge cases, off-by-one errors, unhandled states
- Code quality: readability, naming, unnecessary complexity, duplication
- Security: injection risks, exposed secrets, improper input handling, unsafe defaults
- Performance: unnecessary work, inefficient patterns, missing caching where appropriate
- Correctness: does the implementation match the intent described in the title or description
Group feedback by file or concern. For each issue, state what the problem is and suggest a concrete fix. If something is genuinely good or well-handled, you may note it briefly, but focus on what needs attention.
Be direct. Do not soften criticism or add filler. If the changes look fine, say so plainly.
4. Post feedback
If the review was fetched via gh and there are issues, post a review comment:
gh pr review <number> --request-changes --body "..."
If the changes look good, say so and leave approval to the user.