Frontend PR Review

Engineering

/frontend-pr-review

Reviews a frontend PR for DRY, reusable components and consistent patterns across Next.js, React, and TypeScript.

Anatomy of a skill

A skill is just a markdown file. The frontmatter at the top — a name and a description — tells the assistant when to reach for this skill. Everything below is the body: the instructions, workflow, and know-how it follows once loaded. That is the whole idea — capture expertise once, in plain text, and summon it by name.

The full skill

---
name: frontend-pr-review
description: Reviews a frontend pull request for code quality, patterns, and best practices. Focuses on Next.js, React, TypeScript — checking for DRY code, modular/reusable components, consistent patterns, and proper commenting. Use when the user says "review this frontend PR", "frontend review", "review the UI changes", "check this PR", "look at this frontend code", "review the React changes", "how does this PR look", or shares a PR with frontend file changes (.tsx, .ts, .css, .scss, components/, pages/, app/).
argument-hint: [pr-number-or-url]
---

# Frontend PR Review

Review a frontend pull request with focus on quality, consistency, and maintainability.

## Workflow

1. **Fetch PR context**
   - Run `gh pr view $ARGUMENTS --json title,body,additions,deletions,changedFiles,baseRefName,headRefName` to get PR metadata
   - Run `gh pr diff $ARGUMENTS` to get the full diff
   - Run `gh pr diff $ARGUMENTS --name-only` to get changed file list

2. **Identify frontend files**
   - Filter to frontend-relevant files: `.tsx`, `.ts`, `.css`, `.scss`, `.module.css`, and files under `components/`, `pages/`, `app/`, `hooks/`, `utils/`, `styles/`, `lib/`, `public/`
   - If no frontend files found, inform the user and stop

3. **Read project standards** (if available in the repo)
   - Check for `eslint` config, `tsconfig.json`, `.prettierrc` — note active rules
   - Check for existing component patterns in the codebase for consistency comparison

4. **Review the diff against the checklist**
   - Read [references/review-checklist.md](references/review-checklist.md) for the full checklist
   - Evaluate each changed file against the criteria

5. **Present the review**

   Format as:

   ### Frontend Review — {PR title} (#{number})
   **Files changed:** {count} | **+{additions} / -{deletions}**

   #### Summary
   2-3 sentence overview of what the PR does.

   #### Findings
   For each finding, use:
   - **file:line** — Description of the issue or suggestion
   - Categorize as: `[must-fix]`, `[suggestion]`, `[nit]`, or `[praise]`

   #### Verdict
   One of: **Approve**, **Approve with suggestions**, **Request changes**
   Brief rationale.

## Tone

Direct, professional, constructive. Brief praise where deserved. Humor is fine sparingly — never sarcastic about someone's code. Focus on the code, not the author. Frame suggestions as improvements, not criticisms.

Some skills also bundle reference files (checklists, templates) alongside this SKILL.md. Want to build your own? Start with the Skill Builder skill.