An AI PR Review Workflow That Actually Helps

AI review works best when it has a narrow job. I do not ask it to approve a pull request. I ask it to find classes of mistakes that are easy to miss when I already understand the change.

The workflow below keeps the model useful without giving it authority it should not have.

Before running a review prompt, I write down what the PR is supposed to accomplish. This keeps the AI from reviewing every line as if every change has equal importance.

## Intent
Add the articles index and article detail route.

## Review focus
- App Router data loading
- MDX component registration
- Token-only styling
- Empty states and metadata

## Ignore
- Copy edits unless they change meaning

A clear brief turns a generic review into a targeted one.

The most useful prompt shape is risk-oriented. I want the assistant to identify failure modes and support each concern with a file reference.

 1  Review this diff for production risks.
 2  
 3  Return:
 4  1. Blocking issues
 5  2. Non-blocking improvements
 6  3. Tests or checks that would increase confidence
 7  
 8  Do not approve the PR. Do not comment on style unless it affects maintainability.

This keeps the output concrete. It also makes it easier to reject weak suggestions.

AI is helpful for constraint sweeps when the rules are explicit. In this codebase, that means looking for raw color values, accidental any types, missing MDX component registrations, and layout that bypasses Panda patterns.

I group the useful comments into a patch queue: fix now, create follow-up issue, or reject. Most AI review notes belong in the first or third bucket.

## Fix now
- Add generateStaticParams for article routes
- Register CodeInline in the MDX component map

## Follow-up
- Add screenshot tests for article layouts

## Reject
- Rename all tokens in this PR

The final pass is still human: read the rendered page, click the links, scan the diff, and make sure the change matches the intent. The AI can improve that ritual, but it cannot own it.