Boost-generated CLAUDE.md guidelines contain redundant/wasteful tokens

[leek]

Note

This analysis was performed using Claude (Opus 4.6), so the "already in training data" observations are specific to Claude's knowledge. However, the duplication and verbosity issues apply universally, and most modern LLMs share similar baseline knowledge of Laravel/PHP conventions — so the savings would likely benefit other models too.

Summary

The <laravel-boost-guidelines> injected into CLAUDE.md contain a significant amount of content that is either already in Claude's training data, duplicated across sections, or overly verbose. This burns context window tokens every conversation without improving output quality.

Rough estimate: ~220 of ~510 lines (~43%) (in my personal generated file) could be removed or compressed without losing any behavioral benefit.

1. Content Claude Already Knows (Training Data)

These are standard Laravel/PHP conventions that don't need to be stated:

PHP rules section:

• "Always use curly braces for control structures" — standard, and already enforced by the Pint rule
• "Use PHP 8 constructor property promotion" — well-known since PHP 8.0
• "Always use explicit return type declarations" / "Use appropriate PHP type hints" — standard practice
• The code example showing a typed method signature — unnecessary illustration of basic PHP
• "Prefer PHPDoc blocks over inline comments" — generic best practice

Laravel/core rules section:

• "Use Eloquent models and relationships before raw queries"
• "Avoid DB::, prefer Model::query()"
• "Prevent N+1 with eager loading"
• "Use Form Request classes for validation"
• "Use gates, policies, Sanctum"
• "Prefer named routes and route()"
• "Use ShouldQueue for long operations"
• "Never use env() outside config files"
• "Use factories in tests"

Livewire/core rules section — entirely redundant. "Livewire allows you to build dynamic, reactive interfaces using only PHP" is explaining what Livewire is to a model that already knows. The only useful line ("activate the skill") is already stated in the Skills Activation section.

Laravel 12 Structure — the middleware/Kernel/bootstrap changes have been standard since Laravel 11 and are well within training data.

2. Content Duplicated Across Sections

Instruction	Occurrences
"Use search-docs tool"	5x — boost rules, Laravel 12, Pest, Tailwind, Filament sections
"Activate [skill-name] skill"	2x each — Skills Activation section + individual package section (Livewire, Pest, Tailwind, AI SDK, Prism)
"Use list-artisan-commands"	3x — boost, laravel/core, filament sections
"Pass --no-interaction"	2x — laravel/core, filament sections
"Use get-absolute-url"	2x — boost, herd sections
Frontend bundling / Vite error advice	2x — foundation section, laravel/core section

3. Verbose / Compressible Content

• Boost search-docs syntax (7 lines) — could be 1 line: "Supports stemming, AND logic, quoted phrases, and multiple queries"
• Skills Activation descriptions (~7 lines per skill) — each skill has a multi-line description of when to activate, but these descriptions are already present in the skill system prompts. A simple list of skill names would suffice.
• Filament code snippets (~100 lines) — helpful for v5, but the testing examples are standard Livewire testing patterns. These could be moved to a separate reference file rather than injected into every conversation. The Common Mistakes section (incorrect namespaces, breaking changes) is the actual high-value content here.

Suggestions

1. Remove standard PHP/Laravel knowledge — trust the model's training data for basics; only include project-specific conventions or non-obvious choices
2. Deduplicate — state each instruction once (e.g., "use search-docs" at the top, skill activations in one place only)
3. Move Filament code snippets to a reference file that can be loaded on demand, keep only the Common Mistakes / namespace corrections inline
4. Compress verbose descriptions — the Skills Activation section could be just skill names since the skill prompts already contain activation triggers
5. Delete the Livewire/core section entirely — adds nothing beyond what's in training data + the skill activation already mentioned elsewhere

Environment

• Laravel Boost v2
• Claude Code (Opus 4.6)
• Filament v5, Laravel 12, Livewire 4, Pest 4

[pushpak1300]

I agree with this. I think there is a real opportunity now to remove some of the redundant rules. Models have significantly improved and already have much of this knowledge built in, especially with the additional data we have added into the skill.

One important point is that this was measured on Cloud Opus 4.6, which is currently one of the strongest state of the art models. Our broader goal with Boost is to make it genuinely useful for smaller models as well, such as Kimi, GLM5, and others. We do not want it to be something that only benefits top tier models.

With something like Cloud Opus 4.6, you can often get comparable results even without Boost, simply because the model is already very capable. That said, I agree there is room to simplify and remove redundancy where it no longer adds value.

Thanks a lot for opening this issue. I will review the rules and clean things up accordingly.

[leek]

One important point is that this was measured on Cloud Opus 4.6, which is currently one of the strongest state of the art models. Our broader goal with Boost is to make it genuinely useful for smaller models as well, such as Kimi, GLM5, and others. We do not want it to be something that only benefits top tier models.

I appreciate you taking a look and considering!

Without adding too much complexity I wonder if it is possible to offer a "slim" install option or perhaps a specific output just for CLAUDE.md. Just thinking out loud...

Thanks for your work on a great tool!

[oskobri]

I completely agree with the points raised here. The CLAUDE.md file generated by Laravel Boost ends up far too verbose. In my view, most of what Boost currently injects into CLAUDE.md should not be there at all. These details should be moved into dedicated skills, each focused on a specific area (testing, Livewire, PHP, ...). CLAUDE.md should stay lightweight and contain only high‑level.

[iddo7]

I totally agree as well. On a brand new project with barely 2 small custom guidelines I get a warning from Claude Code saying the CLAUDE.md is too large and could hinder performance.

[carlosvaldesweb]

Agree

[bdlowery]

I disagree, having those rules ensures the model follows them.

[MechJosh0]

Extending off glennjacobs in #738, he's suggested utilising .claude/rules but I also think making use of child directory CLAUDE.md as well.

[glennjacobs]

Extending off glennjacobs in #738, he's suggested utilising .claude/rules but I also think making use of child directory CLAUDE.md as well.

Yeah you're right, it is the same problem. Rules are just a specific solution to it, instead of one massive CLAUDE.md where everything competes for attention, you split instructions into focused files that can be scoped to specific file types or directories, so they only load when relevant. Less noise, better context.

[glennjacobs]

It's worth noting Claude, Cursor and Codex all support rules now.

How do you envisage child directory CLAUDE.md files working?

I am coming from the perspective of a package developer primarily and wanted to offer rules, as the CLAUDE.md was massive when all merged in, and because of that a lot of it was getting missed/ignored.

[ItsReddi]

The idea of #733, The idea stems from best practice skill and would give project owners the ability to determine how context is grouped.