The Laravel Boost guidelines are specifically curated by Laravel maintainers for this application. These guidelines should be followed closely to enhance the user's satisfaction building Laravel applications.
This application is a Laravel application and its main Laravel ecosystems package & versions are below. You are an expert with them all. Ensure you abide by these specific packages & versions.
- php - 8.4.12
- laravel/framework (LARAVEL) - v12
- laravel/prompts (PROMPTS) - v0
- larastan/larastan (LARASTAN) - v3
- laravel/mcp (MCP) - v0
- laravel/pint (PINT) - v1
- rector/rector (RECTOR) - v2
- Prettier - v3
- ESLint - v9
- Bootstrap - v5
- Bun - v1
- Uppy - v5
- Vue.js - v3
- Tiptap - v3
- Lucide Icons
- You must follow all existing code conventions used in this application. When creating or editing a file, check sibling files for the correct structure, approach, naming.
- Use descriptive names for variables and methods. For example,
isRegisteredForDiscounts, notdiscount(). - Check for existing components to reuse before writing a new one.
- Do not create verification scripts or tinker when tests cover that functionality and prove it works. Unit and feature tests are more important.
- Stick to existing directory structure - don't create new base folders without approval.
- Do not change the application's dependencies without approval.
- If the user doesn't see a frontend change reflected in the UI, it could mean they need to run
bun build,bun dev, orcomposer run dev. Ask them.
- Be concise in your explanations - focus on what's important rather than explaining obvious details.
- You must only create documentation files if explicitly requested by the user.
=== boost rules ===
- Laravel Boost is an MCP server that comes with powerful tools designed specifically for this application. Use them.
- Use the
list-artisan-commandstool when you need to call an Artisan command to double check the available parameters.
- Whenever you share a project URL with the user you should use the
get-absolute-urltool to ensure you're using the correct scheme, domain / IP, and port.
- You should use the
tinkertool when you need to execute PHP to debug code or query Eloquent models directly. - Use the
database-querytool when you only need to read from the database.
- You can read browser logs, errors, and exceptions using the
browser-logstool from Boost. - Only recent browser logs will be useful - ignore old logs.
- Boost comes with a powerful
search-docstool you should use before any other approaches. This tool automatically passes a list of installed packages and their versions to the remote Boost API, so it returns only version-specific documentation specific for the user's circumstance. You should pass an array of packages to filter on if you know you need docs for particular packages. - The 'search-docs' tool is perfect for all Laravel related packages, including Laravel, Inertia, Livewire, Filament, Tailwind, Pest, Nova, Nightwatch, etc.
- You must use this tool to search for Laravel-ecosystem documentation before falling back to other approaches.
- Search the documentation before making code changes to ensure we are taking the correct approach.
- Use multiple, broad, simple, topic based queries to start. For example:
['rate limiting', 'routing rate limiting', 'routing']. - Do not add package names to queries - package information is already shared. For example, use
test resource table, notfilament 4 test resource table.
- You can and should pass multiple queries at once. The most relevant results will be returned first.
- Simple Word Searches with auto-stemming - query=authentication - finds 'authenticate' and 'auth'
- Multiple Words (AND Logic) - query=rate limit - finds knowledge containing both "rate" AND "limit"
- Quoted Phrases (Exact Position) - query="infinite scroll" - Words must be adjacent and in that order
- Mixed Queries - query=middleware "rate limit" - "middleware" AND exact phrase "rate limit"
- Multiple Queries - queries=["authentication", "middleware"] - ANY of these terms
=== php rules ===
- Always use curly braces for control structures, even if it has one line.
- Use PHP 8 constructor property promotion in
__construct().- public function __construct(public GitHub $github) { }
- Do not allow empty
__construct()methods with zero parameters.
- Always use explicit return type declarations for methods and functions.
- Use appropriate PHP type hints for method parameters.
- Prefer PHPDoc blocks over comments. Never use comments within the code itself unless there is something very complex going on.
- Add useful array shape type definitions for arrays when appropriate.
- Typically, keys in an Enum should be TitleCase. For example:
FavoritePerson,BestLake,Monthly.
=== laravel/core rules ===
- Pass
--no-interactionto all Artisan commands to ensure they work without user input. You should also pass the correct--optionsto ensure correct behavior.
- Always use proper Eloquent relationship methods with return type hints. Prefer relationship methods over raw queries or manual joins.
- Use Eloquent models and relationships before suggesting raw database queries
- Avoid
DB::; preferModel::query(). Generate code that leverages Laravel's ORM capabilities rather than bypassing them. - Generate code that prevents N+1 query problems by using eager loading.
- Use Laravel's query builder for very complex database operations.
- For APIs, default to using Eloquent API Resources and API versioning unless existing API routes do not, then you should follow existing application convention.
- Always create Form Request classes for validation rather than inline validation in controllers. Include both validation rules and custom error messages.
- Check sibling Form Requests to see if the application uses array or string based validation rules.
- Use queued jobs for time-consuming operations with the
ShouldQueueinterface.
- Use Laravel's built-in authentication and authorization features (gates, policies, Sanctum, etc.).
- When generating links to other pages, prefer named routes and the
route()function.
- Use environment variables only in configuration files - never use the
env()function directly outside of config files. Always useconfig('app.name'), notenv('APP_NAME').
- If you receive an "Illuminate\Foundation\ViteException: Unable to locate file in Vite manifest" error, you can run
bun buildor ask the user to runbun devorcomposer run dev.
=== laravel/v12 rules ===
- Use the
search-docstool to get version specific documentation. - Since Laravel 11, Laravel has a new streamlined file structure which this project uses.
- No middleware files in
app/Http/Middleware/. bootstrap/app.phpis the file to register middleware, exceptions, and routing files.bootstrap/providers.phpcontains application specific service providers.- No app\Console\Kernel.php - use
bootstrap/app.phporroutes/console.phpfor console configuration. - Commands auto-register - files in
app/Console/Commands/are automatically available and do not require manual registration.
- When modifying a column, the migration must include all of the attributes that were previously defined on the column. Otherwise, they will be dropped and lost.
- Laravel 11 allows limiting eagerly loaded records natively, without external packages:
$query->latest()->limit(10);.
- Casts can and likely should be set in a
casts()method on a model rather than the$castsproperty. Follow existing conventions from other models.
=== pint/core rules ===
- You must run
vendor/bin/pint --dirtybefore finalizing changes to ensure your code matches the project's expected style. - Do not run
vendor/bin/pint --test, simply runvendor/bin/pintto fix any formatting issues.