Cursor Rules for Laravel: Eloquent, Routes, and Tests

Cursor rules for Laravel tell the AI assistant how Eloquent models are structured in your project, which validation approach to use, whether it may create or run migrations, and which Artisan commands to run for tests. Without them, an assistant following general PHP or Laravel best practices may produce code that violates the specific conventions your team has agreed on.

Tools like fenbs keep the product and database decisions that those conventions are built on — why a particular relationship model was chosen, which fields are stable and which are being migrated — alongside the tasks, so the next assistant starts with the full picture, not just the code.

What Laravel rules should cover

• Eloquent conventions: fillable versus guarded, relationship naming, eager loading rules.
• Validation: Form Requests versus inline validation, which rules are reused across the application.
• Migrations: whether the AI may create or run new migrations, and whether destructive migrations need a manual review.
• Route definitions: named routes, route groups, API versus web routes, route model binding conventions.
• Service and repository patterns: whether the project uses a service layer, repository pattern, or keeps logic in controllers.
• Test commands: the exact Artisan command to run unit and feature tests.

A starting template

# Laravel project rules

## Build and run
- Test: php artisan test
- Unit tests only: php artisan test --testsuite=Unit
- Feature tests: php artisan test --testsuite=Feature
- Dev server: php artisan serve (or use Sail/Valet if configured)

## Eloquent
- Use $fillable, not $guarded = [].
- Define relationships in both directions (hasMany + belongsTo).
- Do not use lazy loading in controllers; eager load with with().

## Validation
- Use Form Request classes for any request with more than two fields.
- Keep shared validation rules in a central Rules/ directory.

## Migrations
- Ask before creating a new migration.
- Ask before running php artisan migrate on any non-dev environment.
- Destructive migrations (dropping columns or tables) always need a manual review.

## Routes
- Use named routes everywhere (route('name')).
- API routes are in routes/api.php; web routes in routes/web.php.

## Service layer
- Business logic belongs in app/Services/, not in controllers.
- Controllers handle HTTP; services handle business rules.

Migration safety rules

Database migrations are the highest-risk action a Cursor assistant can take in a Laravel project. A migration that runs against a production database or drops a column without a rollback plan can cause data loss. Make the migration rules explicit: create is allowed, but running php artisan migrate in any environment other than local requires a person to approve it.

For teams using a review process for schema changes, add that to the rules: "All migrations must be reviewed before merging to main." This turns a code convention into an actionable instruction the assistant can follow, rather than a step it would otherwise skip.

Authentication and authorization conventions

Laravel's policy and gate system is flexible enough to be used in many different patterns. An assistant without specific rules about how your project handles authorization will choose whatever pattern the documentation examples show. If your project uses policies tied to Eloquent models, add that. If it uses a role-based system through a package, note which one.

• Policies live in app/Policies/ and are named after the model they protect.
• Use $this->authorize() in controllers; do not check permissions in Blade templates.
• Gates handle simple boolean checks that do not need a policy; keep them in AuthServiceProvider.
• Do not use routes that bypass authentication middleware without explicitly checking why.

For multi-tenancy or complex permission systems, add the package name and the pattern it uses to the rules. An assistant working on a Spatie Permission project needs different instructions from one working on a custom RBAC implementation. The rules file is where you close that gap between the framework default and your project's specific approach.

Product decisions and fenbs

Why does the project use Form Requests instead of inline validation? Why was a particular service layer pattern chosen? Why are certain Eloquent relationships defined one way instead of another? These decisions were made for reasons that the code does not explain.

Recording them in fenbs as Decisions means an assistant reading the project context before starting can understand why the code is structured the way it is, not just how. When the team changes a convention — adding a repository layer, migrating to a new authentication approach — update the Decision in fenbs so the reasoning stays current.

How to set up Laravel rules with fenbs

1. Create a free account and add your Laravel project to fenbs. Record the architectural decisions: validation approach, service layer choice, migration policy.
2. Add the template above to .cursor/rules/ in your project and fill in the actual Artisan commands your project uses, especially if you use Sail or a custom test command.
3. Connect Cursor to fenbs over MCP from Integrations. Ask the assistant to read the project context at session start, including any Decisions about the database or architecture.
4. When you change a convention or add a new layer to the application, update the Decision in fenbs and the rules file together.

What to watch for

Laravel's directory structure is flexible, and different projects organize things differently. If your project deviates from the standard Laravel layout — a custom services directory, a separate domain structure, feature-based folders — document those paths in the rules file. An assistant that does not know where your code lives will create files in the wrong place.

The Cursor rules examples post has patterns for structuring rules that work well across different PHP projects. The Cursor CLI guide covers terminal access, which is relevant if your Artisan commands are run through the integrated terminal.

Laravel's job queue and scheduler are commonly used but rarely covered in a rules file. If your project dispatches jobs or schedules commands, add a rule that the assistant must not dispatch a job that sends emails, processes payments, or modifies production data without explicit approval. A job dispatched in the wrong environment can have real consequences that are hard to undo.