GitHub Copilot CLI for .NET: practical setup and workflow

Run copilot in the repository root to start GitHub Copilot CLI. It reads project instructions from .github/copilot-instructions.md or AGENTS.md and can run dotnet build, dotnet test, and other shell commands on your .NET codebase. This guide focuses on making it reliable for C#, ASP.NET Core, and EF Core work. For command details, see the GitHub Copilot CLI overview.

Where the terminal works well for .NET

GitHub Copilot CLI fits .NET because it is a terminal-native agent: the same place you already run dotnet build, dotnet test, and dotnet format. It can inspect .sln, .csproj, and global.json files, follow MSBuild errors, and read package references. That means it can respond to compiler output directly instead of guessing. .NET projects benefit from explicit, scriptable workflows, and the agent can execute those commands, capture results, and iterate. The key condition is a clear instruction file; without one, a multi-project ASP.NET Core solution will cause the agent to run commands in the wrong folder or misread project conventions.

Configuring the project for reliable agent work

Create .github/copilot-instructions.md at the repository root, or use AGENTS.md if you already have one. GitHub Copilot CLI reads these files automatically. Keep the file short and command-oriented: build, test, and lint commands; solution layout; and .NET-specific rules. Do not paste entire coding guidelines; the agent needs executable constraints more than prose.

A realistic example:

# Project instructions

## Build and test
- Build: `dotnet build MyApp.sln`
- Test: `dotnet test MyApp.sln --no-build`
- Format check: `dotnet format MyApp.sln --verify-no-changes`

## Solution layout
- src/MyApp.Api - ASP.NET Core host and controllers
- src/MyApp.Core - domain models and services
- src/MyApp.Infrastructure - EF Core DbContext and migrations
- tests/MyApp.UnitTests - xUnit unit tests
- tests/MyApp.IntegrationTests - WebApplicationFactory tests

## Rules
- Do not add or update NuGet packages without asking.
- Keep EF Core migrations in src/MyApp.Infrastructure/Migrations.
- Use IOptions<T> for configuration; do not call Configuration directly in services.
- Keep async methods async; never use .Result or .Wait().
- Treat nullable reference type warnings as errors.

After adding the file, when you run copilot, the agent will use these commands to verify changes. In a multi-project solution, listing the solution file prevents the agent from running dotnet test in a random project directory.

A practical loop: plan, implement, test, review

A reliable loop is: ask for a plan, review the plan, let the agent implement a small step, run the tests, inspect the diff, repeat. Do not hand the agent a large feature and expect a correct pull request in one turn. For a step-by-step walkthrough, see how to use GitHub Copilot CLI.

Example prompts for typical .NET tasks:

• Add a POST /api/orders endpoint that validates an OrderCommand with FluentValidation, persists an Order entity through EF Core, and returns 201 with the created resource. Write xUnit tests for the handler.
• Convert the synchronous GetActiveUsers method in UserService to async/await, update all call sites, and run the unit tests.
• Diagnose why the CheckoutService integration test throws DbUpdateException when two requests run in parallel. Fix the code, not the test.
• Generate an EF Core migration for adding Customer.PhoneNumber and update the DbContext model snapshot.
• Refactor OrderController to use MediatR while keeping the existing API contract unchanged. Run tests after each step.

A table can help you match tasks to prompts:

Insist that the agent stop after each step and wait for review. This is especially important when a change touches Program.cs, dependency injection, or EF Core.

Where the agent excels and where to be careful

GitHub Copilot CLI handles boilerplate-heavy .NET work well: CRUD controllers, DTO mapping, validation, xUnit/NUnit test scaffolding, simple refactorings, and EF Core query fixes. It is good at following compiler errors and running unit tests until they pass.

Watch it closely in these .NET-specific areas:

• EF Core migrations: the agent may run dotnet ef migrations add more than once, generate an empty migration, or forget to update the model snapshot. Always review migration files line by line.
• NuGet packages: the agent may add a package with an incompatible version or use a preview package. Require approval for package changes.
• Async and cancellation: it may add .Result or Task.Run to make a sync method work, causing deadlocks or thread-pool starvation.
• Dependency injection lifetimes: it may inject a scoped service into a singleton, or register a DbContext incorrectly.
• Nullable reference types: if your project has <Nullable>enable</Nullable>, the agent must not suppress warnings with ! or #nullable disable without review.
• Multi-project solutions: the agent can run commands from the wrong directory. The instruction file should point to the solution file for every command.

Testing and verifying .NET changes with the agent

Have the agent run dotnet test after each change, not just at the end. Use --no-build when the build is already fresh to save time, but let the agent run a full dotnet build first. Filter tests when only one area changed: dotnet test MyApp.sln --filter FullyQualifiedName~Order. For integration tests, ask the agent to use WebApplicationFactory and avoid starting a real HTTP server unless needed. After a migration, have the agent run dotnet ef migrations script and show you the generated SQL before applying it. Finally, run dotnet format MyApp.sln --verify-no-changes to ensure formatting did not regress. For broader verification workflows, spec-driven development with AI agents describes how to pair a spec with agent checks.

Using multiple agents safely on one .NET project

AgentVera is a desktop app that runs GitHub Copilot CLI and other coding agents side by side in real terminal panels. For .NET projects, the most valuable features are parallel agents in separate git worktrees, which prevent two agents from writing to the same .csproj or migration file; automatic code review by a second model, which can catch EF Core and nullable mistakes with file:line links; checkpoints that let you undo a bad turn such as an unwanted migration or broken DI registration; and token budgets that stop a stuck agent from churning on a large solution. These controls fit the .NET workflow where a single erroneous migration or package change can ripple across the build.

Final notes

GitHub Copilot CLI becomes a dependable .NET assistant when you give it a clear instruction file, work in small verified steps, and review the areas where .NET makes mistakes costly: migrations, packages, async, and dependency injection. Use the working loop above and keep the agent’s changes under version control. With a disciplined process, it can take over much of the repetitive C# and ASP.NET Core work while you stay in control of the solution architecture.