agentleFS
rcdelfinrcdelfin/agentkit/skills/software-development/laravel-best-practices/SKILL.md

laravel-best-practices

Skill2 starsChanged 3 months agoMITView on GitHub

Use when writing, reviewing, or refactoring Laravel PHP code, including Eloquent, controllers, validation, authorization, queues, migrations, and queries.

  • Reads credentials

33 other projects use a version of this, 29 of them edited.

Adopted by

Most recently taken up by

Used with

Projects with it also use socialite-development, inertia-vue-development and 9 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • ownegoSkill

    socialite-development

    Manages OAuth social authentication with Laravel Socialite. Activate when adding social login providers; configuring OAuth redirect/callback flows; retrieving authenticated user details; customizing scopes or parameters; setting up community providers; testing with Socialite fakes; or when the user mentions social login, OAuth, Socialite, or third-party authentication.

    Also in 11 projects that use this

  • syofyanzuhadSkill

    inertia-vue-development

    Develops Inertia.js v2 Vue client-side applications. Activates when creating Vue pages, forms, or navigation; using <Link>, <Form>, useForm, or router; working with deferred props, prefetching, or polling; or when user mentions Vue with Inertia, Vue pages, Vue forms, or Vue navigation.

    Also in 7 projects that use this

  • syofyanzuhadSkill

    wayfinder-development

    Use this skill for Laravel Wayfinder which auto-generates typed functions for Laravel controllers and routes. ALWAYS use this skill when frontend code needs to call backend routes or controller actions. Trigger when: connecting any React/Vue/Svelte/Inertia frontend to Laravel controllers, routes, building end-to-end features with both frontend and backend, wiring up forms or links to backend endpoints, fixing route-related TypeScript errors, importing from @/actions or @/routes, or running wayfinder:generate. Use Wayfinder route functions instead of hardcoded URLs. Covers: wayfinder() vite plugin, .url()/.get()/.post()/.form(), query params, route model binding, tree-shaking. Do not use for backend-only task

    Also in 5 projects that use this

  • datashamanSkill

    passport-development

    Develops OAuth2 API authentication with Laravel Passport. Activates when installing or configuring Passport; setting up OAuth2 grants (authorization code, client credentials, personal access tokens, device authorization); managing OAuth clients; protecting API routes with token authentication; defining or checking token scopes; configuring SPA cookie authentication; handling token lifetimes and refresh tokens; or when the user mentions Passport, OAuth2, API tokens, bearer tokens, or API authentication. Make sure to use this skill whenever the user works with OAuth2, API tokens, or third-party API access, even if they don't explicitly mention Passport.

    Also in 7 projects that use this

  • ownegoSkill

    livewire-development

    Use for any task or question involving Livewire. Activate if user mentions Livewire, wire: directives, or Livewire-specific concepts like wire:model, wire:click, wire:sort, or islands, invoke this skill. Covers building new components, debugging reactivity issues, real-time form validation, drag-and-drop, loading states, migrating from Livewire 3 to 4, converting component formats (SFC/MFC/class-based), and performance optimization. Do not use for non-Livewire reactive UI (React, Vue, Alpine-only, Inertia.js) or standard Laravel forms without Livewire.

    Also in 9 projects that use this

  • datashamanSkill

    configuring-horizon

    Use this skill whenever the user mentions Horizon by name in a Laravel context. Covers the full Horizon lifecycle: installing Horizon (horizon:install, Sail setup), configuring config/horizon.php (supervisor blocks, queue assignments, balancing strategies, minProcesses/maxProcesses), fixing the dashboard (authorization via Gate::define viewHorizon, blank metrics, horizon:snapshot scheduling), and troubleshooting production issues (worker crashes, timeout chain ordering, LongWaitDetected notifications, waits config). Also covers job tagging and silencing. Do not use for generic Laravel queues without Horizon, SQS or database drivers, standalone Redis setup, Linux supervisord, Telescope, or job batching.

    Also in 10 projects that use this

  • +1 more from syofyanzuhad
  • +1 more from ownego

The file

Show its rules and text

We split this skill into the rules it gives an agent

19 rules. 2 are common, 10 are distinctive, and 7 are very specific to this project.

  • 2

    Common

    Most of the 33 edited versions we read keep these.

  • 10

    Distinctive

    This author's own choices. Worth a look.

  • 7

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  • could be automatic: a setting could enforce it
  1. Common:

    Before applying any rule, check what the application already does.

    line 15
  2. Common:

    Check sibling files, related controllers, models, or tests for established patterns.

    line 17
  3. Distinctive:

    Never query in Blade templates

    line 30
  4. Distinctive:

    No raw SQL with user input — use Eloquent or query builder

    line 46
  5. Very specific:

    Never commit .env, use config() for secrets, encrypted cast for sensitive DB fields

    line 49
  6. Very specific:

    Never hardcode table names — use (new Model)->getTable() or Eloquent queries

    line 70
  7. Very specific:

    Use fakes (Event::fake(), Exceptions::fake(), etc.) — but always after factory setup, not before

    line 91
  8. Very specific:

    Always implement failed().

    line 98
  9. Very specific:

    Check response status or use throw()

    line 114
  10. Distinctive:

    Prefer official Laravel packages and follow conventions, don't override defaults

    line 149
  11. Very specific:

    Default to ORDER BY id DESC or created_at DESC.

    line 150
  12. Distinctive:

    Never modify migrations that have run in production

    line 157
  13. Distinctive:

    Add indexes in the migration, not as an afterthought

    line 158
  14. Distinctive:

    Follow Laravel naming conventions for all entities

    line 179
  15. Very specific:

    Prefer Laravel helpers (Str, Arr, Number, Uri, Str::of(), $request->string()) over raw PHP functions

    line 180
  16. Distinctive:

    No JS/CSS in Blade, no HTML in PHP classes

    line 181
  17. Distinctive:

    Read relevant rule files before applying advice.

    line 186
  18. Distinctive:

    Check sibling files for existing patterns — follow those first per Consistency First

    line 189
  19. Distinctive:

    Verify API syntax against the installed Laravel version and available project documentation

    line 190

“Common” is measured: kept by at least 6 in 10 of the 33 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Laravel Best Practices

Best practices for Laravel, prioritized by impact. Each rule teaches what to do and why. Verify exact API syntax against the installed Laravel version and available project documentation.

Consistency First

Before applying any rule, check what the application already does. Laravel offers multiple valid approaches — the best choice is the one the codebase already uses, even if another pattern would be theoretically better. Inconsistency is worse than a suboptimal pattern.

Check sibling files, related controllers, models, or tests for established patterns. If one exists, follow it — don't introduce a second way. These rules are defaults for when no pattern exists yet, not overrides.

Quick Reference

1. Database Performance → rules/db-performance.md

  • Eager load with with() to prevent N+1 queries
  • Enable Model::preventLazyLoading() in development
  • Select only needed columns, avoid SELECT *
  • chunk() / chunkById() for large datasets
  • Index columns used in WHERE, ORDER BY, JOIN
  • withCount() instead of loading relations to count
  • cursor() for memory-efficient read-only iteration
  • Never query in Blade templates

2. Advanced Query Patterns → rules/advanced-queries.md

  • addSelect() subqueries over eager-loading entire has-many for a single value
  • Dynamic relationships via subquery FK + belongsTo
  • Conditional aggregates (CASE WHEN in selectRaw) over multiple count queries
  • setRelation() to prevent circular N+1 queries
  • whereIn + pluck() over whereHas for better index usage
  • Two simple queries can beat one complex query
  • Compound indexes matching orderBy column order
  • Correlated subqueries in orderBy for has-many sorting (avoid joins)

3. Security → rules/security.md

  • Define $fillable or $guarded on every model, authorize every action via policies or gates
  • No raw SQL with user input — use Eloquent or query builder
  • {{ }} for output escaping, @csrf on all POST/PUT/DELETE forms, throttle on auth and API routes
  • Validate MIME type, extension, and size for file uploads
  • Never commit .env, use config() for secrets, encrypted cast for sensitive DB fields

4. Caching → rules/caching.md

  • Cache::remember() over manual get/put
  • Cache::flexible() for stale-while-revalidate on high-traffic data
  • Cache::memo() to avoid redundant cache hits within a request
  • Cache tags to invalidate related groups
  • Cache::add() for atomic conditional writes
  • once() to memoize per-request or per-object lifetime
  • Cache::lock() / lockForUpdate() for race conditions
  • Failover cache stores in production

5. Eloquent Patterns → rules/eloquent.md

  • Correct relationship types with return type hints
  • Local scopes for reusable query constraints
  • Global scopes sparingly — document their existence
  • Attribute casts in the casts() method
  • Cast date columns, use Carbon instances in templates
  • whereBelongsTo($model) for cleaner queries
  • Never hardcode table names — use (new Model)->getTable() or Eloquent queries

6. Validation & Forms → rules/validation.md

  • Form Request classes, not inline validation
  • Array notation ['required', 'email'] for new code; follow existing convention
  • $request->validated() only — never $request->all()
  • Rule::when() for conditional validation
  • after() instead of withValidator()

7. Configuration → rules/config.md

  • env() only inside config files
  • App::environment() or app()->isProduction()
  • Config, lang files, and constants over hardcoded text

8. Testing Patterns → rules/testing.md

  • LazilyRefreshDatabase over RefreshDatabase for speed
  • assertModelExists() over raw assertDatabaseHas()
  • Factory states and sequences over manual overrides
  • Use fakes (Event::fake(), Exceptions::fake(), etc.) — but always after factory setup, not before
  • recycle() to share relationship instances across factories

9. Queue & Job Patterns → rules/queue-jobs.md

  • retry_after must exceed job timeout; use exponential backoff [1, 5, 10]
  • ShouldBeUnique to prevent duplicates; ShouldBeUniqueUntilProcessing for early lock release
  • Always implement failed(); with retryUntil(), set $tries = 0
  • RateLimited middleware for external API calls; Bus::batch() for related jobs
  • Horizon for complex multi-queue scenarios

10. Routing & Controllers → rules/routing.md

  • Implicit route model binding
  • Scoped bindings for nested resources
  • Route::resource() or apiResource()
  • Methods under 10 lines — extract to actions/services
  • Type-hint Form Requests for auto-validation

11. HTTP Client → rules/http-client.md

  • Explicit timeout and connectTimeout on every request
  • retry() with exponential backoff for external APIs
  • Check response status or use throw()
  • Http::pool() for concurrent independent requests
  • Http::fake() and preventStrayRequests() in tests

12. Events, Notifications & Mail → rules/events-notifications.md, rules/mail.md

  • Event discovery over manual registration; event:cache in production
  • ShouldDispatchAfterCommit / afterCommit() inside transactions
  • Queue notifications and mailables with ShouldQueue
  • On-demand notifications for non-user recipients
  • HasLocalePreference on notifiable models
  • assertQueued() not assertSent() for queued mailables
  • Markdown mailables for transactional emails

13. Error Handling → rules/error-handling.md

  • report()/render() on exception classes or in bootstrap/app.php — follow existing pattern
  • ShouldntReport for exceptions that should never log
  • Throttle high-volume exceptions to protect log sinks
  • dontReportDuplicates() for multi-catch scenarios
  • Force JSON rendering for API routes
  • Structured context via context() on exception classes

14. Task Scheduling → rules/scheduling.md

  • withoutOverlapping() on variable-duration tasks
  • onOneServer() on multi-server deployments
  • runInBackground() for concurrent long tasks
  • environments() to restrict to appropriate environments
  • takeUntilTimeout() for time-bounded processing
  • Schedule groups for shared configuration

15. Architecture → rules/architecture.md

  • Single-purpose Action classes; dependency injection over app() helper
  • Prefer official Laravel packages and follow conventions, don't override defaults
  • Default to ORDER BY id DESC or created_at DESC; mb_* for UTF-8 safety
  • defer() for post-response work; Context for request-scoped data; Concurrency::run() for parallel execution

16. Migrations → rules/migrations.md

  • Generate migrations with php artisan make:migration
  • constrained() for foreign keys
  • Never modify migrations that have run in production
  • Add indexes in the migration, not as an afterthought
  • Mirror column defaults in model $attributes
  • Reversible down() by default; forward-fix migrations for intentionally irreversible changes
  • One concern per migration — never mix DDL and DML

17. Collections → rules/collections.md

  • Higher-order messages for simple collection operations
  • cursor() vs. lazy() — choose based on relationship needs
  • lazyById() when updating records while iterating
  • toQuery() for bulk operations on collections

18. Blade & Views → rules/blade-views.md

  • $attributes->merge() in component templates
  • Blade components over @include; @pushOnce for per-component scripts
  • View Composers for shared view data
  • @aware for deeply nested component props

19. Conventions & Style → rules/style.md

  • Follow Laravel naming conventions for all entities
  • Prefer Laravel helpers (Str, Arr, Number, Uri, Str::of(), $request->string()) over raw PHP functions
  • No JS/CSS in Blade, no HTML in PHP classes
  • Code should be readable; comments only for config files

How to Apply

Read relevant rule files before applying advice.

  1. Identify the file type and select relevant sections (e.g., migration → §16, controller → §1, §3, §5, §6, §10)
  2. Check sibling files for existing patterns — follow those first per Consistency First
  3. Verify API syntax against the installed Laravel version and available project documentation

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.