Laravel + Claude Code: how I use it to clean up PRs without slowing down

I like shipping features fast.
I don’t like opening a PR knowing the diff is harder to read than it needs to be.

Not because the code is wrong—but because it’s messy in a very familiar way: extra nesting, temporary variables that survived debugging, AI-generated verbosity, or logic that grew organically during a long session.

Laravel’s official Claude Code plugin repository solves that exact moment for me. Not with another framework, not with magic automation—but with a small, intentional cleanup step at the end of a feature.

This is how I use laravel-simplifier in real Laravel projects.

The real problem: “it works” is not the same as “it’s ready to review”

Most code quality problems don’t start as bad decisions. They start as:

• “I’ll refactor this later”
• “This is clear enough for now”
• “Let’s just get the feature working”
• “The AI output is correct, I’ll clean it up later”

And later rarely comes.

The result isn’t broken code—it’s expensive code:

• reviewers need more mental effort
• intent is harder to spot
• future refactors become riskier

I don’t want tools that replace my judgment.
I want tools that help me finish the job properly.

What laravel/claude-code actually is

laravel/claude-code is an official Laravel repository that provides Claude Code plugins specifically aimed at Laravel/PHP workflows.

Right now, it’s intentionally small:

• a Claude Code marketplace entry
• one plugin: laravel-simplifier

That’s a good thing.

laravel-simplifier doesn’t try to architect your app. It doesn’t introduce new layers or patterns. It focuses on one thing only:

make recently changed Laravel code easier to read, safer to review, and more consistent—without changing behavior.

Concretely, it:

• applies common Laravel conventions
• reduces unnecessary complexity and nesting
• improves naming and structure
• scopes itself to recent changes by default
• preserves functionality

That scope is why I trust it.

Quick start (this really is all you need)

Install the marketplace and plugin:

/plugin marketplace add laravel/claude-code
/plugin install laravel-simplifier@laravel

Then run:

Review recent changes using the laravel-simplifier agent

That’s it. No config files. No repo-wide impact.

How I actually use it (3 workflows)

1. PR polish after a long coding session

When
I’ve finished a feature, tests pass, but I know the diff could be cleaner.

What I do

git add -A
git commit -m "feat: implement X"

Then I run the simplifier and commit again:

git commit -am "chore: simplify recent changes"
php artisan test

Prompt I usually use

Use the laravel-simplifier agent on recent changes. Preserve behavior exactly. Reduce nesting, simplify conditionals, and align with Laravel conventions.

Why this works

Reviewers get two commits:

• one for intent (“what changed”)
• one for clarity (“how it’s expressed”)

If something ever goes wrong, rollback is trivial.

2. Simplifying controllers without breaking contracts

Controllers are where complexity sneaks in fastest.

Goal
Reduce cognitive load while keeping routes, responses, and side effects identical.

Typical flow

php artisan test
# run simplifier
php artisan test

Prompt

Use the laravel-simplifier agent on recent changes. Keep routes, validation, responses, and side effects identical. Prefer early returns and clearer orchestration.

What I look for in the diff

• fewer nested if blocks
• earlier validation failures
• clearer sequencing: validate → authorize → act → respond

If tests pass and the diff reads faster, it’s a win.

3. Cleaning up AI-generated verbosity (without shame)

AI helps me move fast—but it often leaves code that’s technically fine and stylistically off.

This workflow is for that.

git commit -am "feat: implement Y"
# run simplifier
git commit -am "chore: align with Laravel conventions"
php artisan test

Prompt

Use the laravel-simplifier agent on recent changes. Reduce verbosity and redundancy. Do not refactor unrelated files.

Result

The code starts to look like my codebase again:

• fewer temporary variables
• clearer naming
• less noise for reviewers

Guardrails I stick to (and recommend)

This tool works best with discipline:

• always commit feature work first
• keep simplification in a separate commit
• run tests every time
• review the diff like a refactor, not like generated code
• never let it escape “recent changes”

The mental model is simple:

This is a cleanup step, not a design step.

Common pitfalls (and how I avoid them)

Over-simplifying business logic

Some ugly code is ugly for a reason.
If a block feels “too easy to simplify”, I add or re-read the test first.

Subtle Laravel behavior changes

I explicitly scan for:

• has() vs filled()
• truthiness edge cases ('0', 0, null)
• reordered side effects
• moved validation or authorization

Team conventions drift

Laravel conventions are a baseline—not a replacement for team decisions.
If your team prefers Form Requests, actions, or specific naming, reinforce that via prompts.

Final thoughts

laravel-simplifier doesn’t make you a better developer.

But it does make it easier to consistently finish your work at a higher quality bar—without slowing down or starting refactor debates.

My default loop now looks like this:

build feature → run simplifier → run tests → open PR

It’s boring. Predictable. And it scales surprisingly well across teams.

If you try it, do it on a PR you already think is “done”.
That’s where it shines.