home / skills / first-fluke / fullstack-starter / frontend-code-review

frontend-code-review skill

/.agents/skills/frontend-code-review

This skill performs a standardized frontend code review for React and Next.js TypeScript projects, highlighting quality, performance, and accessibility

npx playbooks add skill first-fluke/fullstack-starter --skill frontend-code-review

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
2.1 KB
---
name: frontend-code-review
description: Standardized checklist and process for reviewing frontend code (.tsx, .ts, .js).
---

# Frontend Code Review Skill

**Intent**: Use whenever requested to review frontend code (React, Next.js, TypeScript).

**Supports**:
- **Pending-change review**: Reviewing `git diff` or staged files.
- **File-targeted review**: Reviewing specific existing files.

## Review Process

1. **Scan**: Read the code to identify architectural patterns, hooks usage, and component structure.
2. **Check**: Apply the [Review Checklist](#review-checklist).
3. **Report**: Output findings in the [Required Output Format](#required-output-format).

## Review Checklist

### 1. Code Quality & Style
- [ ] **Naming**: Are variables/functions named descriptively? (e.g., `isLoading` vs `flag`)
- [ ] **Type Safety**: Is `any` avoided? are interfaces defined clearly?
- [ ] **Constants**: Are magic numbers/strings extracted to constants?
- [ ] **Destructuring**: Is consistent destructuring used for props?

### 2. React & Next.js Best Practices
- [ ] **Hooks**: Are hooks used correctly (dependency arrays, rules of hooks)?
- [ ] **Server/Client**: Is `'use client'` used only when necessary?
- [ ] **Memoization**: Are `useMemo`/`useCallback` used appropriately (not prematurely)?
- [ ] **Keys**: Do lists have stable, unique keys?

### 3. Performance
- [ ] **Bundle Size**: Are large libraries imported entirely when tree-shaking is possible?
- [ ] **Images**: Is `next/image` used with proper sizing?
- [ ] **Renders**: Are there obvious unnecessary re-renders?

### 4. Accessibility (a11y)
- [ ] **Semantic HTML**: Are `div`s used where `button`, `section`, etc., are needed?
- [ ] **Attributes**: Do images have `alt` text? Do inputs have labels?

## Required Output Format

```markdown
# Code Review

Found <N> urgent issues:
## 1. <Issue Title>
**File**: `<path>` line `<line>`

```typescript
<snippet of problematic code>
```

**Reason**: <Why is this urgent?>
**Suggested Fix**:
```typescript
<snippet of fixed code>
```

---

Found <M> suggestions:
- **<Refactor/Style>**: <Description>
- **<Optimization>**: <Description>
```

Overview

This skill provides a standardized checklist and process for reviewing frontend code in React/Next.js projects using TypeScript and JavaScript. It focuses on practical, production-oriented concerns: code quality, React/Next.js best practices, performance, and accessibility. The goal is to produce clear, actionable findings for both pending changes and targeted file reviews.

How this skill works

The reviewer scans code to understand architecture, component structure, and hook usage. It then applies a compact checklist for naming, typing, hooks, rendering, bundle concerns, and a11y. Finally, the skill produces a concise report with urgent issues and suggestions, including file, line, code snippets, reasons, and suggested fixes. Reports are formatted to be copy-paste ready for PR comments.

When to use it

  • Review staged changes or diffs before merging a PR.
  • Audit specific frontend files (.tsx, .ts, .js) when investigating bugs or regressions.
  • Verify migration to Next.js app-router or server components.
  • Validate performance-sensitive UI changes (images, lists, heavy libs).
  • Run a focused accessibility pass before release.

Best practices

  • Prefer descriptive names and avoid ambiguous flags like isFlag; prefer explicit boolean naming (isLoading, hasError).
  • Avoid using any; define interfaces and prefer generics to preserve type safety.
  • Use hooks following rules of hooks: stable dependency arrays and no conditional calls.
  • Use 'use client' only on components that require browser APIs; prefer server components where possible.
  • Import only what you need to keep bundle size small and rely on next/image for responsive images.

Example use cases

  • PR review for a feature that adds a complex list and interactions, checking keys and re-rendering issues.
  • Post-merge audit to catch accessibility regressions introduced across multiple files.
  • Pre-release performance sweep focusing on large imports and image handling.
  • Targeted file review when converting components from class to function or enabling server components.
  • Checklist-driven review for onboarding new frontend contributors to maintain consistency.

FAQ

Can this skill review backend or mobile code?

No. It is focused on frontend React, Next.js, and TypeScript/JavaScript files only.

Does it auto-fix issues?

No. It identifies urgent issues and suggests concrete code fixes, but changes must be applied manually or via other tooling.

Will it check every accessibility guideline?

It highlights common a11y problems (semantic HTML, alt text, labels) but does not replace a full automated or manual accessibility audit.