quick-review
npx skills add https://github.com/skobak/quick-review --skill quick-review
Agent 安装分布
Skill 文档
/quick-review: Categorical PR Review
Large PRs â especially AI-generated ones â are impractical to review line-by-line. This skill reads the full diff, clusters changes into semantic categories, and presents a structured review.
Invocation
The user provides one of:
- A GitHub PR URL (e.g.,
https://github.com/org/repo/pull/123) - A PR number (assumes current repo)
- Nothing (reviews the current branch’s diff against the base branch)
Phase 1: Gather the Diff
Option A â PR URL or number:
gh pr diff <number> --repo <owner/repo>
Also fetch PR metadata for context:
gh pr view <number> --repo <owner/repo> --json title,body,baseRefName,headRefName,files
Option B â Current branch (no PR):
git diff $(git merge-base HEAD main)..HEAD
If main doesn’t exist, try master. Use the branch the user specifies if they provide one.
Also gather:
- List of changed files with stats:
git diff --stat <base>..HEADorgh pr diff <number> --stat - Recent commit messages on the branch:
git log --oneline <base>..HEAD
Phase 2: Classify Changes
Read through the entire diff. Classify every changed file (and significant hunks within files) into one or more of these categories:
Categories
| Category | What belongs here |
|---|---|
| Database & Data | Schema migrations, model/entity changes, query modifications, seed data, ORM config |
| Architecture & Structure | New patterns introduced, folder restructuring, module boundaries, dependency injection changes, middleware additions |
| API & Contracts | Endpoint additions/changes, request/response shape changes, GraphQL schema, OpenAPI spec, serializers |
| Dependencies | Packages added/removed/bumped in lockfiles and manifests, new imports of external libraries |
| UI & Components | New components, layout changes, styling updates, CSS/Tailwind changes, asset additions |
| Business Logic | Core domain logic, algorithms, validation rules, state machines, calculations |
| Configuration & Infra | CI/CD changes, Docker, env vars, deployment config, build settings, linter/formatter config |
| Tests | New tests, modified tests, test utilities, fixtures, mocks |
| Best Practices & Concerns | Security issues, performance concerns, anti-patterns, missing error handling, hardcoded secrets, TODOs |
A file can appear in multiple categories if it contains changes spanning different concerns. Not every category will be present â only include categories that have actual changes.
Phase 3: Produce the Review
Output the review in this exact structure:
PR Overview
One paragraph: what this PR does at a high level, inferred from the diff and commit messages. State the scope (number of files changed, insertions/deletions).
Category Sections
For each category that has changes, output:
Category Name (N files)
- Bullet summary of what changed and why (infer intent from the code)
- Call out specific files when relevant:
path/to/file.ts - Flag anything notable: breaking changes, new patterns, risks
Potential Concerns
Separate section aggregating anything that warrants attention:
- Security issues (hardcoded credentials, SQL injection, XSS vectors, missing auth checks)
- Performance risks (N+1 queries, missing indexes, unbounded loops, large payloads)
- Missing tests for new logic
- Breaking API changes without migration path
- Inconsistencies with existing patterns in the codebase
- Dead code or unused imports introduced
- TODO/FIXME/HACK comments added without tracking
If there are no concerns, say so explicitly â don’t fabricate issues.
Verdict
A one-line summary: is this PR ready to merge, or does it need changes? Be direct.
Rules
- Read everything. Don’t skim. The value of this skill is comprehensive coverage.
- Be specific. Reference file paths. Quote code when it clarifies a point.
- Infer intent. Don’t just say “changed X” â say why it was likely changed based on context.
- Don’t nitpick style. Formatting, naming preferences, and linter-fixable issues are noise. Focus on substance.
- Don’t fabricate. If you’re unsure about something, say so. Don’t invent concerns.
- Scale the review. A 5-file PR gets a concise review. A 50-file PR gets thorough category breakdowns.
- Respect the codebase. If you need to understand existing patterns to judge the PR, read the relevant source files â don’t guess.
Examples
Invocation:
/quick-review
> https://github.com/acme/app/pull/42
Invocation (current branch):
/quick-review
Invocation (PR number in current repo):
/quick-review 42