Requesting Code Review: From Pre-PR Self-Review to Incorporating Feedback

One-Line Summary

Systematize the full review cycle of reviewing your own code with Claude Code before creating a PR, receiving peer feedback, and then applying it.

Target Audience

• College students who are creating a PR for the first time in a team project
• Beginners who are unsure how to incorporate peer review feedback
• Students who want to catch TypeScript strict type errors before code review
• Team members who have the experience of "delaying PRs because code review is scary"

---

Core Workflow

Full Review Cycle

[Development complete]
    ↓
requesting-code-review  → Self-review (bugs, type errors, style)
    ↓
[Create GitHub PR]
    ↓
Receive peer reviewer feedback
    ↓
receiving-code-review   → Classify feedback and plan fixes
    ↓
[Fix commit + PR update]
    ↓
[Merge approval]

Step 1 — Pre-PR Self-Review (requesting-code-review)

When writing is complete, don't upload to GitHub right away — first run the requesting-code-review skill. This skill re-examines the code from a "reviewer's perspective" to catch mistakes early.

claude

> /skill requesting-code-review
> Review the following files. This is a self-review before creating a PR.
> - app/notices/page.tsx
> - app/api/notices/route.ts
> - components/NoticeCard.tsx
> Review criteria:
>   1. TypeScript strict violations (any types, overuse of type assertions)
>   2. Supabase query N+1 problems
>   3. Missing error handling
>   4. Accessibility (aria attributes)
>   5. Mobile responsive layout

Example self-review report generated by the requesting-code-review skill:

## Self-Review Results

### Critical (Required to fix before merge)
- `route.ts:42` — No error handling in `const data = await supabase.from('notices').select('*')`.
  Need to add `if (error) throw error`.
- `NoticeCard.tsx:15` — Remove `props.author as string` type assertion,
  explicitly handle the type as `string | null`.

### Warning (Recommended fix)
- `page.tsx:8` — No skeleton UI while loading notice list (recommended UX improvement)
- `route.ts:60` — No validation of pagination parameters

### Info (Optional improvement)
- `NoticeCard.tsx` — Recommend using Next.js `<Image>` instead of `<img>` tag

Step 2 — TypeScript Strict Error Fix Patterns

When type errors are found in requesting-code-review, fix them using the following patterns.

Pattern A: Remove any types

> Remove all `any` types in route.ts and infer the correct types.
> Import Supabase response types from the Database type file.

Pattern B: Remove type assertions (as)

> Remove the `as string` assertion in NoticeCard.tsx
> and replace with type-safe code including null handling.
> Example: author?.name ?? 'Anonymous'

Pattern C: Handle union types

> Find all cases where Supabase select results can be null
> and handle with optional chaining (?.) and nullish coalescing (??)

Step 3 — GitHub PR Writing Checklist

After self-review is complete, create the PR. Claude Code can automatically generate PR descriptions.

> Write a GitHub PR description based on the work just done.
> Include:
>   - Summary of changes (within 3 lines)
>   - Screenshot insertion location guide
>   - Testing method (local run commands)
>   - Files/functions that reviewers should focus on

Generated PR description example:

## Changes
- Notice list page SSR implementation (Supabase server component)
- Notice CRUD API route added (GET/POST/DELETE)
- NoticeCard component + skeleton loading UI

## Testing Method
1. Run `pnpm dev`
2. Visit `/notices` → verify notice list
3. After login, `/notices/new` → test writing

## Review Points
- `app/api/notices/route.ts:40-65` — Supabase RLS and server authentication logic
- `components/NoticeCard.tsx` — TypeScript type handling approach

Step 4 — Receive and Classify Feedback (receiving-code-review)

When peer reviewer feedback arrives, use the receiving-code-review skill to classify it and create a fix plan.

> /skill receiving-code-review
> Analyze the following review feedback and create a fix plan.
>
> Feedback 1 (Kim): "I think it would be better to separate authentication checks to middleware in route.ts"
> Feedback 2 (Lee): "The date format in NoticeCard is inconsistent. How about using date-fns?"
> Feedback 3 (Park): "Entering a negative number in pagination parameters causes an error"

Fix plan generated by the receiving-code-review skill:

## Feedback Processing Plan

### Fix Immediately (Blocking)
1. Negative pagination parameter → Add validation with Zod schema
   File: app/api/notices/route.ts, Estimated time: 30 minutes

### Include in this PR (Non-blocking, agreed)
2. Unify date format → Install date-fns + apply formatRelative
   File: components/NoticeCard.tsx, Estimated time: 20 minutes

### Move to next PR (Out of scope)
3. Separate authentication middleware → Recommend creating a separate issue
   Reason: Middleware refactoring exceeds the scope of this PR

---

Practical Scenario

Situation: Creating a PR for the notice CRUD feature in the Student Club Notice Board project

Scenario A: Pre-PR Self-Review

# Run self-review after development is complete
claude

> /skill requesting-code-review
> Review the notice API route file.
> File: app/api/notices/route.ts

Problem found by Claude Code:

// Problem found: Missing Supabase error handling
// Before fix
export async function GET(request: Request) {
  const { data } = await supabase
    .from('notices')
    .select('*')
    .order('created_at', { ascending: false });
  return Response.json(data);
}

// After fix (Claude Code suggestion)
export async function GET(request: Request) {
  const { data, error } = await supabase
    .from('notices')
    .select('*')
    .order('created_at', { ascending: false });

  if (error) {
    console.error('Notice list query failed:', error.message);
    return Response.json({ error: 'Unable to load data' }, { status: 500 });
  }

  return Response.json(data ?? []);
}

Scenario B: Applying Peer Review Feedback

# Process peer feedback
> /skill receiving-code-review
> A team member left this feedback:
> "Please add Zod validation for request body.
>  Should return error if title is empty string or exceeds 200 characters."
>
> Add Zod schema to POST handler.

Fix code generated by Claude Code:

import { z } from 'zod';

// Notice creation request schema
const createNoticeSchema = z.object({
  title: z.string().min(1, 'Please enter a title').max(200, 'Title must be within 200 characters'),
  content: z.string().min(1, 'Please enter content'),
  isPinned: z.boolean().default(false),
});

export async function POST(request: Request) {
  const body = await request.json();
  const parsed = createNoticeSchema.safeParse(body);

  if (!parsed.success) {
    return Response.json(
      { error: 'Invalid input', details: parsed.error.flatten() },
      { status: 400 }
    );
  }

  const { data, error } = await supabase
    .from('notices')
    .insert(parsed.data)
    .select()
    .single();

  if (error) {
    return Response.json({ error: 'Failed to register notice' }, { status: 500 });
  }

  return Response.json(data, { status: 201 });
}

Scenario C: Bulk TypeScript Error Fixes

# Paste tsc check results and request bulk fixes
> Analyze the tsc --noEmit results and fix all errors:
>
> error TS2322: Type 'string | null' is not assignable to type 'string'
>   at components/NoticeCard.tsx:23:15
>
> error TS7006: Parameter 'e' implicitly has an 'any' type
>   at app/notices/new/page.tsx:45:34
>
> error TS2339: Property 'author' does not exist on type 'Notice'
>   at components/NoticeCard.tsx:31:22

---

Recommended Skill Combinations

Situation	Skill	Purpose
Pre-PR self-check	requesting-code-review	Catch bugs and type errors early
Process peer feedback	receiving-code-review	Classify feedback and create fix plan
Verify after fix	verification-before-completion	Check fix side effects
Prevent regression	test-driven-development	Add tests after review fix
Fix type errors	systematic-debugging	Systematically resolve tsc errors

---

Cautions

Reviewer Checklist

When reviewing a PR, check the following items in order:

1. TypeScript strict compliance: Check for any types and overuse of as assertions
2. Error handling: Supabase errors, fetch failures, null case handling
3. Security: API endpoints accessible without authentication
4. Performance: N+1 queries, unnecessary re-renders, large bundles
5. UX: Loading states, empty states, error message display

Common Mistakes

1. Impulse to fix all feedback immediately: Classify feedback into Blocking / Non-blocking / Next PR, then move fixes that exceed the current PR scope to new issues.

2. Opening PR without self-review: Creating a PR without requesting-code-review increases review rounds for trivial mistakes, slowing down the whole team.

3. PR too large: Putting 3+ features in one PR makes it hard for reviewers to focus. Split PRs by feature unit.

4. Ignoring review comments: "I'll fix it later" creates technical debt. Specify the processing plan with the receiving-code-review skill and leave issue numbers.

5. Ignoring CI failures: Don't open a PR when pnpm build or tsc --noEmit is failing. Always pass the local build first during the self-review stage.

Tips

• Register PR description template: Saving the template generated by Claude Code in .github/pull_request_template.md allows the whole team to write consistent PRs.
• Copy review feedback as text: Pasting GitHub PR comments directly into a Claude Code session allows the receiving-code-review skill to automatically classify them.

---

Field	Value
Source URL	https://docs.anthropic.com/en/docs/claude-code
License	CC BY 4.0
Explanation Date	2026-04-12
Author	Claude-Code-Study Project