GitHub Copilot CLI Laravel: Practical Agent Guide

GitHub Copilot CLI is a terminal coding agent you start with copilot inside a Laravel project. It reads project instructions from .github/copilot-instructions.md or AGENTS.md, then edits files, runs php artisan commands, and executes your test suite. For a Laravel developer, treat it as a pair programmer that can work across Eloquent models, migrations, Blade views, and tests if you give it clear boundaries. See GitHub Copilot CLI for the tool and How to use GitHub Copilot CLI: a step-by-step guide for setup basics.

Why Laravel conventions make a CLI agent effective

Laravel’s conventions make it a good fit for a CLI agent. File locations are predictable: models in app/Models, controllers in app/Http/Controllers, migrations in database/migrations, tests in tests/Feature or tests/Unit. The agent can read existing migrations to infer schema and relationships, then add a new Eloquent model with the correct casts, $fillable, and relationships. It can also use php artisan make:model or make:migration to generate files that match Laravel’s own output, reducing the chance of syntax drift. Because PHP has explicit types and Laravel’s container and facades are widely known, the agent can produce concrete, testable code instead of vague suggestions. The biggest practical wins are boilerplate CRUD actions, form request validation, policy methods, and Pest/PHPUnit tests. It is less useful for decisions that require product context, such as which data to hide from an API response or how to sequence queued jobs.

Configuring your Laravel project for Copilot CLI

Create or edit .github/copilot-instructions.md in the repository root, or use AGENTS.md if you prefer a single source. The file is read at the start of a session and gives the agent your local commands, folder conventions, and rules. Keep it short and concrete; long prose invites the agent to skim. For a Laravel project, put the exact commands you use for installation, testing, styling, and static analysis. State where folders live, not just the default because some teams put form requests in app/Http/Requests and actions in app/Actions. Most importantly, set rules for destructive operations: never run migrations without asking, never change migration files unless explicitly requested, and never start a server. If the agent struggles to locate files consistently, a codebase map can help; see Codebase map for AI agents: find code without grep.

# Laravel project instructions

## Commands
- Install dependencies: `composer install`
- Run tests: `php artisan test --parallel`
- Run a single test: `php artisan test --filter=UserTest`
- Lint: `./vendor/bin/pint --test`
- Static analysis: `./vendor/bin/phpstan analyse --memory-limit=1G`

## Folders
- Models: `app/Models`
- Controllers: `app/Http/Controllers`
- Form requests: `app/Http/Requests`
- Services/actions: `app/Services`, `app/Actions`
- Migrations: `database/migrations`
- Blade: `resources/views`
- Tests: `tests/Feature`, `tests/Unit`

## Rules
- Use Eloquent relationships and query scopes; avoid raw `DB::table` unless performance demands it.
- Every migration must have a working `down()` or be declared irreversible.
- Use Form Requests for validation in controllers.
- Add factories for every new model and use them in seeders.
- Never run `php artisan migrate`, `migrate:fresh`, or `db:seed` without explicit approval.
- Do not edit existing migration files; create new migrations instead.
- Keep Blade templates logic-light; move repeated logic to View Composers.

A repeatable loop for Laravel changes

Treat each task as a small, reviewable change. Ask the agent to state a plan first, then implement only that plan. After each change, run the relevant test subset before moving on. Use git diff to inspect every modified file; the agent may touch composer.lock or config/app.php if you let it. A practical loop:

1. Give the agent the current goal and constraints, for example: ‘Do not change migrations, only add a model and a test.’
2. Ask it to show the plan as a list of file changes before editing.
3. Tell it to implement.
4. Run the tests yourself or ask the agent to run the exact command.
5. Review git diff and either commit or ask for a correction.

Example prompts for typical Laravel work:

• ‘Read app/Models/User.php and the migrations in database/migrations, then add a one-to-many posts relationship with a new migration and a Post model. Write a failing feature test first.’
• ‘Create a Form Request for the store method in PostController using the same validation rules as UpdatePostRequest. Add the relevant Pest test.’
• ‘Refactor the queued job app/Jobs/SendWelcomeEmail.php to handle soft-deleted users without sending an email. Keep the job’s public API and run its existing test.’
• ‘Add a Blade component alert that accepts a type and message, then replace the three duplicate alert blocks in resources/views/posts/index.blade.php and resources/views/dashboard.blade.php.’
• ‘After reading the migration and existing tests, write a Pest test for the store endpoint that covers validation errors and an authenticated user creating a post.’

Laravel tasks that work well and where to double-check

Handled well: generating migrations and Eloquent models with relationships, creating resource controllers with validation and authorization, writing feature/unit tests, refactoring closures into invokable controllers or action classes, adding queue jobs and mailable classes, and updating Blade components. These tasks follow Laravel conventions and can be verified by tests.

Watch closely in these areas:

• Eloquent queries: the agent may introduce N+1 queries in loops or forget with() on a relationship. Always review controller loops and API resources.
• Mass assignment: it might add a new column to a migration but forget to add it to $fillable, or use create($request->all()) without validation. Check form requests and model fillable arrays.
• Migrations: the agent may edit an existing migration instead of creating a new one, or write an irreversible down(). Keep the rule to never touch applied migrations.
• Service providers and config: it sometimes registers bindings or adds config entries for a small change. Prefer letting it write explicit classes instead of container magic.
• Queues and jobs: adding a new job may require a ShouldQueue contract, and the agent can miss public $tries or delay logic. Review dispatch calls and job signatures.
• Blade: it may embed complex PHP logic in templates. Reject that; ask for a view composer or a helper.

The biggest Laravel-specific pitfalls are schema changes that break existing seeders, soft-delete interactions with unique indexes, and route caching. If the agent suggests php artisan route:cache or config:cache, make sure it also knows to clear those caches after edits.

How to verify agent changes in Laravel

Make the agent run tests after each change, not just at the end. Start with the failing test for new features, then run that specific test with php artisan test --filter=NameOfTest. For a bug fix, ask it to add a regression test first. Then run the full suite with php artisan test --parallel before committing. For style, use ./vendor/bin/pint --test; for static analysis, ./vendor/bin/phpstan analyse. These commands are cheap and catch issues like undefined methods on Eloquent models or missing relationships.

The table below shows the verification commands worth putting in your project instructions.

Also inspect git diff for unintended changes. Pay attention to composer.lock, config/cache.php, compiled views in storage/framework/views, or generated IDE helper files. Review migrations with php artisan migrate:status in a local environment to see if the batch is correct. When the agent runs tests, ask it to report the exact command and output; do not accept ‘tests passed’ without seeing the summary.

Using AgentVera for parallel Laravel work

For Laravel projects with multiple workstreams, AgentVera runs GitHub Copilot CLI alongside other coding agents in separate git worktrees, so parallel work doesn’t overwrite shared files. Automatic code review after each turn flags Eloquent N+1 problems, missing $fillable, or migration issues with links to file:line. Checkpoints allow one-click undo of a risky schema change or a botched refactor, then replay the session step by step. Token budgets stop a stuck agent from draining your daily allowance while preserving the conversation. Together these controls make multi-agent Laravel work safer because you can isolate changes, review them with a second model, and recover cleanly.

Final recommendations for Laravel and Copilot CLI

Start with a tight .github/copilot-instructions.md that captures your Laravel commands and rules. Keep every task small, run tests constantly, and review the diff before you commit. Use targeted verification commands such as Pint and PHPStan. When you scale to several agents, use git worktrees and a review step so no one breaks the schema. With that discipline, GitHub Copilot CLI becomes a valuable Laravel pair programmer rather than a source of migration rollbacks.