How I use Claude for PRs as a frontend engineer

Dev.to / 5/15/2026

💬 OpinionDeveloper Stack & InfrastructureTools & Practical Usage

共有:

Key Points

The author configures CLAUDE.md rules to keep Claude from touching production or pushing to the remote GitHub repo, ensuring all work stays local until approved.
They use a “local review” command to have Claude review a feature branch’s staged diff against the remote base branch before opening a PR.
When the local review flags blockers or must-fixes, they resolve the issues and rerun the local review until it passes.
After code review, they use a “pr-summary” command to generate a PR description including What, Why, and a Test plan, plus a suggested commit message.
They maintain a single source of guidance by asking Claude to consolidate the workflow into DEV_GUIDE.md to make the process repeatable for themselves (and potentially others).

So I implement features or fix bugs pretty obvious, that's the job. But I follow a few steps so PR reviews don't eat up too much of my colleagues' time.

Before any of this, I added a rule to the global CLAUDE.md for the workspace saying Claude isn't allowed to touch production or push to the remote GitHub repo. Everything stays local until I say so.

Step 1: Local review

I asked Claude to build something called local review. I run it before raising any PR. It takes my feature branch staged changes, pulls the remote base branch, and starts reviewing the diff. The command looks like:

/local-review <repo> <base-branch> <feature-branch>

If it flags any blockers or must-fixes, I resolve those and run it again.

Step 2: PR summary

Then I ask it to write a PR summary with:

/pr-summary <repo> <base-branch> <feature-branch>

It gives me a commit message and a proper summary with What, Why, and a Test plan. Output looks something like this:

Add a loading state to the search dropdown and fix a race condition where stale results were overwriting newer ones on fast typing.

    What
    - Add a spinner inside the input while results are being fetched
    - Cancel in-flight requests when a new query is typed
    - Show an empty state when the query returns nothing (was rendering a blank box before)

    Why
    - Typing fast surfaced older results on top of newer ones, which was confusing
    - Users had no signal that a request was in progress
    - Empty results looked like the component was broken

    Test plan
    - Build passes
    - Type slowly, confirm spinner shows and results render
    - Type fast, backspace, type again — only the latest query's results should show
    - Search for something with no matches — empty state should render

    <ticket link>
    <asset link>

And just so I don't forget any of these, I asked Claude to put everything in one place in DEV_GUIDE.md, and my life has been easier so far.

Let me know if anyone has any suggestions to make it better.