You start by running opencode in the solution folder; the agent reads AGENTS.md from that directory and applies the rules you define. See opencode for the baseline behavior, then tailor AGENTS.md to .NET. This guide covers a practical .NET workflow, including C#, ASP.NET Core, Entity Framework Core, and xUnit or NUnit.
Why opencode fits .NET work
opencode runs normal dotnet CLI commands, so it can use the same build, test, and format commands you already run. .NET solutions are explicit: the .sln and .csproj files tell the agent exactly which projects exist, their target frameworks, package references, and dependencies. The compiler is a strong feedback loop; when opencode edits C#, dotnet build and dotnet test return concrete errors and failing tests that the agent can use to correct itself. This works especially well for ASP.NET Core request pipelines, EF Core LINQ queries, and xUnit/NUnit test projects because the structure is predictable once you document your conventions.
Setting up AGENTS.md for a .NET project
Create AGENTS.md at the solution root before serious work. Tell opencode how to build, test, and lint, and what .NET conventions matter in this repository. Include the solution layout, exact commands, target framework settings, and rules for EF Core, DI, async, and test naming. A realistic AGENTS.md for a common solution looks like this:
# AGENTS.md
## Project layout
- src/ contains one class library per bounded context
- tests/ mirrors src with xUnit test projects
- Solution file: MyApp.sln
## Commands
- Build: dotnet build MyApp.sln --no-restore
- Test: dotnet test MyApp.sln --no-build --logger console;verbosity=normal
- Lint: dotnet format MyApp.sln --verify-no-changes
- Restore: dotnet restore MyApp.sln
- Add migration: dotnet ef migrations add <Name> --project src/MyApp.Infrastructure --startup-project src/MyApp.Api
## .NET conventions
- Use file-scoped namespaces; enable nullable and ImplicitUsings in every csproj
- Use primary constructors where available
- Prefer async/await for I/O; return Task<T> from service methods
- Register services in Program.cs via extension methods, one per project
- EF Core: keep DbContext in Infrastructure, entities in Domain, no lazy loading proxies
- Logging via ILogger<T>, not Console.WriteLine in libraries
- Tests: xUnit, one test class per production class, name tests Method_Scenario_ExpectedResult
- Do not change .sln or .csproj unless asked, except adding a project reference
## Rules for agent
- Always run dotnet build after code changes; do not claim success until tests pass
- Prefer minimal diffs; do not reformat untouched filesKeep this file short and specific. If you use Central Package Management, add a note that NuGet versions live in Directory.Packages.props and must not be added directly to csproj files. For ASP.NET Core, mention auth schemes, JSON options, and middleware order if they are non-default.
A safe working loop with example prompts
Work in small steps. Start by asking opencode to inspect the solution and propose a plan. After each change, have it run dotnet build and the relevant dotnet test, then review the git diff yourself. Do not let it accumulate multiple unrelated changes. For the general opencode workflow, see How to use opencode: a step-by-step guide.
Useful prompts for .NET tasks:
Read MyApp.sln and list the projects with their target frameworks and dependencies; suggest an order to add a new order-history feature to the API.Add an endpoint GET /api/orders/{id} in OrdersController that returns OrderDto; write the controller action, service interface, and one xUnit test. Do not modify the DbContext.Create an EF Core migration named AddOrderStatus for the Order entity; run dotnet ef migrations add and show the generated files. Do not update the database.Fix the failing tests in OrderServiceTests; run dotnet test on the test project only and summarize what changed.Refactor the payment processing method into an IPaymentGateway interface with two implementations; update DI registration and existing tests; run the full solution build after each step.
Keep each prompt scoped to one project or one concern. If you must touch multiple projects, say which ones and in what order.
Tasks opencode does well and where to watch
opencode is strong at repetitive .NET work: adding controllers and minimal API endpoints, mapping DTOs, fixing LINQ queries, registering services, and writing xUnit or NUnit tests. It can also read compiler warnings and nullability errors and fix them. However, some .NET areas need close review.
| Task | Where opencode does well | Watch closely |
|---|---|---|
| Add controller endpoint | routing, action return types, model binding | auth filters, Swagger annotations, route conflicts |
| EF Core query | LINQ translation, Include/ThenInclude, AsNoTracking | client evaluation, N+1 queries, disposed DbContext |
| DI registration | adding services, extension methods | lifetime mismatch, captive dependencies, circular references |
| Unit tests | arrange/act/assert, mocking | wrong test framework attributes, async test deadlocks |
Specific pitfalls: opencode may edit generated files such as EF Core migrations and designer snapshots incorrectly; always review those diffs and run dotnet ef migrations script to verify. It may add NuGet packages with incompatible versions; use Central Package Management and pin major versions. It can register a scoped service in a singleton or introduce .Result in ASP.NET Core; ask for a build with warnings as errors if your project enables that. For solution-level work, it sometimes runs dotnet test at the root when only one project changed; specify the test project in your prompt.
Testing and verification with the agent
Make opencode verify its own work. After any code change, ask it to run dotnet build MyApp.sln --no-restore and dotnet test MyApp.sln --no-build. Have it show the command output; if tests fail, it should not claim success. For faster loops, target one test project with dotnet test tests/MyApp.UnitTests --no-build --filter FullyQualifiedName~OrderService. If you use NUnit, make sure the agent uses NUnit attributes and not xUnit, or vice versa; a mismatch is common when both frameworks exist. Use dotnet format MyApp.sln --verify-no-changes as a lint check after a refactor. For ASP.NET Core integration tests, let the agent run the test project that uses WebApplicationFactory rather than starting the full app manually. Review the final git diff before committing: the agent may leave unused usings, generated migration files, or temporary console logging.
Running several agents on one .NET project with AgentVera
For .NET solutions where you want several opencode agents in parallel, AgentVera runs real CLI agents side by side in one window, each in its own terminal panel. Its git worktree support matters most: each agent works in its own worktree, so one agent changing a csproj or Program.cs does not overwrite another’s work. Automatic code review is valuable because a second model checks agent output before you merge, and checkpoints let you undo a bad refactor or EF Core migration in one click. Token budgets keep long-running .NET work from burning through your account unnoticed. See Best tools to run AI coding agents in parallel (2026) for broader options.
Wrap-up
opencode fits .NET work when you give it explicit AGENTS.md rules, keep changes small, and verify with dotnet build and dotnet test after every step. It handles controllers, EF Core, DI, and tests well, but generated files and package versions deserve human review. For parallel work on the same solution, AgentVera adds worktrees, review, and checkpoints that reduce merge pain. Start with a clean AGENTS.md and one scoped prompt; you will quickly find the loop that keeps the solution building.