Laravel Boost Development Guidelines
Expert Laravel development assistant with integrated Boost MCP tools, designed for Laravel 12 applications with modern PHP, Vue 3, Tailwind CSS, and comprehensive testing practices.
Application Context
This skill is optimized for Laravel applications using:
**PHP 8.3** with modern syntax (constructor property promotion, enums, type hints)**Laravel 12** with streamlined directory structure**Vue 3** frontend with Vite bundling**Tailwind CSS v3** for styling**PHPUnit 11** for testing**Laravel Boost MCP** for enhanced toolingCore Development Principles
1. Follow Existing Conventions
**Always check sibling files** before creating new code to match existing patternsUse descriptive variable and method names (e.g., `isRegisteredForDiscounts`, not `discount()`)Check for existing components to reuse before writing new onesMaintain consistent code style throughout the application2. Use Laravel Boost MCP Tools
**`search-docs`**: Search Laravel ecosystem documentation (Laravel, Inertia, Livewire, Tailwind, etc.) with version-specific results. Use multiple broad queries like `['rate limiting', 'routing']`**`list-artisan-commands`**: Verify available Artisan command parameters before running**`get-absolute-url`**: Generate correct project URLs with proper scheme/domain/port**`tinker`**: Execute PHP code for debugging or querying Eloquent models**`database-query`**: Read from database directly**`browser-logs`**: Read recent browser logs, errors, and exceptions3. Do Things the Laravel Way
**Use `php artisan make:*` commands** to create files (migrations, controllers, models, etc.)Pass `--no-interaction` to Artisan commands to avoid promptsPrefer Eloquent relationships over raw queriesUse `Model::query()` instead of `DB::`Always eager load relationships to prevent N+1 queriesUse Form Request classes for validation (never inline validation)Use environment variables only in config files (`config('app.name')`, not `env('APP_NAME')`)Prefer named routes with `route()` function for URL generationPHP Best Practices
Type Declarations & Constructor Promotion
```php
// Use constructor property promotion
public function __construct(public GitHub $github) { }
// Always use explicit return types and type hints
protected function isAccessible(User $user, ?string $path = null): bool
{
// Implementation
}
```
Control Structures
Always use curly braces for control structures, even single-line statementsNo empty `__construct()` methods with zero parametersDocumentation
Prefer PHPDoc blocks over inline commentsAdd array shape type definitions when appropriateAvoid comments within code unless logic is very complexLaravel 12 Structure
Key Differences from Earlier Versions
**No `app/Http/Middleware/`** directory for middleware files**No `app/Console/Kernel.php`** - use `bootstrap/app.php` or `routes/console.php`Commands in `app/Console/Commands/` auto-register`bootstrap/app.php` registers middleware, exceptions, and routing`bootstrap/providers.php` contains service providersDatabase & Eloquent
Always use proper relationship methods with return type hintsWhen modifying columns in migrations, include all previous attributes to prevent data lossUse native eager loading limits: `$query->latest()->limit(10)`Set model casts in `casts()` method (follow existing conventions)Model Creation Workflow
When creating models:
1. Generate model with `php artisan make:model`
2. Create useful factories and seeders
3. Use `list-artisan-commands` to check available options
APIs & Resources
Default to Eloquent API Resources with versioningFollow existing API conventions if presentQueues & Jobs
Use queued jobs with `ShouldQueue` interface for time-consuming operationsTesting with PHPUnit
Test Requirements
**Every change must be programmatically tested**Write new tests or update existing tests for all modificationsTest happy paths, failure paths, and edge casesUse factories for model creation in testsMost tests should be feature tests (use `--unit` flag for unit tests)Running Tests
```bash
Run all tests
php artisan test
Run specific file
php artisan test tests/Feature/ExampleTest.php
Filter by test name (recommended after changes)
php artisan test --filter=testName
```
Test Workflow
1. Create test: `php artisan make:test --phpunit <name>`
2. After updating a test, run that specific test
3. When feature tests pass, ask user if they want to run the full suite
4. **Never remove tests without approval** - they are core to the application
Faker Usage
Follow existing conventions:
Use `$this->faker->word()` or `fake()->randomDigit()`Check factory custom states before manual model setupTailwind CSS v3
Core Practices
Use Tailwind classes for all stylingCheck existing conventions before writing new patternsOffer to extract repeated patterns into componentsSpacing
Use gap utilities instead of margins for lists:
```html
<!-- Correct -->
<div class="flex gap-8">
<div>Item 1</div>
<div>Item 2</div>
<div>Item 3</div>
</div>
```
Dark Mode
If existing components support dark mode, new components must also support itTypically use `dark:` prefix for dark mode classesClass Organization
Think through placement, order, priority, and defaultsRemove redundant classesGroup elements logicallyAdd classes to parent or child carefully to limit repetitionFrontend Bundling
If frontend changes aren't reflected:
May need to run `npm run build`, `npm run dev`, or `composer run dev`Ask the user which command to runTroubleshooting
Vite Manifest Error
If you see "Illuminate\Foundation\ViteException: Unable to locate file in Vite manifest":
Run `npm run build` or ask user to run `npm run dev` or `composer run dev`Response Guidelines
Be concise - focus on what's important, not obvious detailsDon't create verification scripts when tests already cover functionalityDon't create documentation files unless explicitly requestedStick to existing directory structure - don't create new base folders without approvalDon't change dependencies without approvalSearch Documentation First
Before making code changes:
1. Use `search-docs` tool with broad, simple, topic-based queries
2. Pass multiple queries at once for best results
3. Don't include package names in queries (already filtered by version)
4. Use available syntax: simple words, multiple words (AND logic), quoted phrases, mixed queries
**Example queries**: `['authentication', 'middleware "rate limit"', 'routing']`