# GitHub Copilot CLI Laravel: Practical Agent Guide

URL: https://agentvera.dev/en/blog/copilot-cli-for-laravel/ · Published: 2026-11-01

Learn how to set up GitHub Copilot CLI for Laravel: project instructions, example prompts, testing with PHPUnit/Pest, and pitfalls with Eloquent and migrations.

**In short:**

- Put Laravel-specific build, test, and migration rules in .github/copilot-instructions.md so the agent follows your conventions.
- Use small steps, run PHPUnit/Pest after each change, and review git diff to catch Eloquent and migration mistakes early.
- For parallel Laravel work, use git worktrees, automatic code review, and checkpoints to avoid conflicts and recover safely.

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](/en/agents/copilot-cli/) for the tool and [How to use GitHub Copilot CLI: a step-by-step guide](/en/blog/how-to-use-copilot-cli/) 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](/en/blog/codebase-map-for-ai-agents/).

```
# 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.

| Check | Command |
|---|---|
| Full test suite | `php artisan test --parallel` |
| Single test | `php artisan test --filter=UserTest` |
| Style | `./vendor/bin/pint --test` |
| Static analysis | `./vendor/bin/phpstan analyse` |
| Route list | `php artisan route:list --except-vendor` |

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.

## Frequently asked questions

**What is GitHub Copilot CLI and how do I start it in a Laravel project?** GitHub Copilot CLI is a terminal coding agent from GitHub. In a Laravel project folder, run copilot to start a session; it reads .github/copilot-instructions.md or AGENTS.md for project context. You can ask it to edit files, run php artisan commands, and execute tests.

**Can GitHub Copilot CLI create Laravel migrations and models?** Yes. It can generate migrations, Eloquent models, factories, and tests. Give it the existing schema and ask for a specific change; restrict it from editing applied migrations.

**How do I make GitHub Copilot CLI run my Laravel test suite?** Put the exact test command in your project instructions, usually php artisan test --parallel. Ask the agent to run a specific failing test after each change, then the full suite before finishing.

**How can I prevent GitHub Copilot CLI from running destructive Laravel commands?** Add rules in .github/copilot-instructions.md such as 'never run migrations without explicit approval' and 'never edit existing migration files.' Review the diff before committing and use checkpoints if you work with multiple agents.

---

**About AgentVera.** AgentVera is a desktop app for macOS, Windows and Linux, built by Solviera Teknoloji. It runs 18 AI coding agents (Claude Code, Codex, Gemini CLI, Copilot, Cursor, Antigravity, opencode, Hermes, Qwen Code, Kimi Code, Kiro, Amp, Droid, Goose, Vibe, Crush, Aider, Cline) side by side, per project, in real terminals with the user's own CLI installs and logins. The free plan has unlimited agents. Download: https://agentvera.dev/en/download/ · Pricing: https://agentvera.dev/en/pricing/