review

Overview of review skill

What the review skill does

review is a pre-landing PR review skill for checking diffs against the base branch before code is merged. It is meant for reviewers who need more than a generic prompt: it focuses on concrete structural risks like SQL safety, trust-boundary violations, conditional side effects, shell injection, and enum completeness.

Who should use it

Use the review skill when you are about to land code, respond to “review this PR,” or want a consistent review for PR Review workflow across repos. It is especially useful for agents that need to flag real defects fast and avoid noisy style-only comments.

Why it is different

The skill is opinionated about review order and severity. It pushes critical safety checks first, then lower-severity issues, and it supports specialist review paths for areas like testing, security, performance, and maintainability. That makes the review guide more actionable than a broad “scan the diff” prompt.

Fit and limitations

This is strongest for code changes with a clear git diff and a meaningful base branch. It is less useful for high-level design critiques, product copy edits, or cases where the user only wants praise or a summary. If you need a lightweight opinion rather than a fix-first review, a generic prompt may be enough.

How to Use review skill

Install and trigger it

Install with npx skills add garrytan/gstack --skill review. The skill is designed to trigger on phrases like “review this PR,” “code review,” “check my diff,” and “pre-landing review,” so the input should name the change and the comparison point whenever possible.

Give the skill a real review target

The best review usage starts with a diff-aware request, not a vague ask. Good inputs include the repo, branch, and intent:

• “Review this PR against origin/main; focus on safety, merge risk, and anything that would block landing.”
• “Review the diff in packages/billing for SQL injection, race conditions, and API contract breaks.”

Read these files first

For practical review install verification, start with SKILL.md, then checklist.md, design-checklist.md, and greptile-triage.md. If you are adapting the workflow, also inspect TODOS-format.md and the specialists/ folder to understand which issues are routed to subagents versus the main checklist.

Use the workflow the skill expects

The repo is built around a two-pass review: critical safety checks first, then informational issues. A strong prompt should ask for actionable output with file/line references and fixes, not just “find bugs.” If you know the change area, include it so the skill can prioritize the relevant specialist path.

review skill FAQ

Is review better than a normal prompt?

Yes, when you need repeatable PR review behavior. A normal prompt can miss scope rules, escalation order, or specialist routing. The review skill bakes those into the workflow, which reduces guesswork on what to inspect first.

Is the review skill beginner-friendly?

Mostly yes, if the user can describe the branch or PR. Beginners benefit from the guided checklist, but they still need to provide a real diff and enough context to distinguish intended behavior from regressions.

When should I not use review?

Do not use it for no-code questions, brainstorming, or abstract architecture discussions without a concrete change set. It is also not the right fit if you only want a quick sanity check and do not need line-level findings.

What should I expect from review for PR Review?

Expect terse, fix-oriented comments with severity prioritization. The skill is designed to surface landing blockers, not to restate the whole repo or produce a celebratory summary.

How to Improve review skill

Give sharper inputs

The strongest review skill inputs name the base branch, the risky subsystem, and the desired standard. Instead of “review my PR,” use “review feature/payment-retry against origin/main; prioritize data safety, idempotency, and any behavior change that could break clients.”

Include the context that changes judgment

If the change is intentionally risky, say so. If a pattern is allowed by project policy, mention it up front. That reduces false positives and helps the review focus on actual tradeoffs rather than re-litigating known decisions.

Ask for the format you need

If you want a landing-oriented output, request findings with file:line, severity, and concrete fixes. If you want only blockers, say that. If you want specialist coverage, ask for it explicitly so the review does not stop at the first pass.

Iterate after the first pass

Use the first review to patch obvious issues, then rerun review on the updated diff. The biggest quality gains usually come from clarifying scope, tightening the comparison branch, and feeding the skill the exact risk area you care about most.