> ## Content Index > Fetch the complete content index at: https://www.artisancraft.dev/llms.txt > Use this file to discover other available public pages before exploring further. # Laravel + Claude Code: how I use it to clean up PRs without slowing down - URL: https://www.artisancraft.dev/laravel-claude-code-how-i-use-it-to-clean-up-prs-without-slowing-down/ - Published: 2026-01-12T08:56:55.000Z - Updated: 2026-02-16T22:32:20.000Z - Description: I like shipping fast—but I hate messy PRs. Laravel’s official Claude Code plugin adds laravel-simplifier: a focused, behavior-preserving way to clean up recent Laravel changes before you open a PR. - Author: Daniel Plomp - Tags: laravel, php, developers, developer-tools, claude, dx, ai-assisted-development 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: ```bash /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** ```bash git add -A git commit -m "feat: implement X" ``` Then I run the simplifier and commit again: ```bash 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** ```bash 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. ```bash 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.