One programmer, one business analyst, and several fullstack "AI co-developers" — all running through GitHub Copilot with Claude models. Here is the setup, from .md configuration files to team workflow, for both greenfield and brownfield .NET projects.
Prerequisites
- Copilot Business/Enterprise license (coding agent, code review, org-level instructions).
- A .NET repository (e.g., ASP.NET Core, Clean Architecture:
src/Api, src/Application, src/Domain, src/Infrastructure, tests/).
- VS Code or Visual Studio with Copilot; select a Claude model in the Copilot Chat model picker.
Step 1 - Foundation: .github/copilot-instructions.md
The repo-wide "working contract," automatically injected into every Copilot request (Chat, Code Review, Coding Agent):
# Copilot Instructions — <ProjectName> ## Context ASP.NET Core 8 (Clean Architecture). Blazor frontend. SQL Server via EF Core. ## Conventions - C# 12, nullable enabled, file-scoped namespaces. - MediatR for use cases in src/Application; keep controllers thin. - FluentValidation only — no manual validation in controllers. - Data access only through src/Infrastructure. - Async end-to-end; never .Result / .Wait(). ## Build & Test - Build: dotnet build - Test: dotnet test (xUnit + FluentAssertions); every new use case needs a unit test. ## Constraints - No new NuGet packages without flagging them in the PR description. - Do not touch /legacy unless instructed. - Secrets via user-secrets / Azure Key Vault only.
Keep it short, factual, verifiable — overly long files reduce accuracy.
Brownfield tip Let the Copilot agent "onboard" the repo using GitHub's official prompt to generate a draft copilot-instructions.md, then curate it manually.
Step 2Path-Scoped Rules: .github/instructions/*.instructions.md
A fullstack repo needs different rules per layer, via applyTo frontmatter:
.github/instructions/ ├── api.instructions.md # applyTo: "src/Api/**" ├── domain.instructions.md # applyTo: "src/Domain/**" ├── frontend.instructions.md # applyTo: "src/Web/**" └── testing.instructions.md # applyTo: "tests/**"
Example testing.instructions.md:
--- applyTo: "tests/**" --- - Naming: MethodName_Scenario_ExpectedResult. - Prefer builders/fixtures; avoid over-mocking the Domain. - Integration tests use Testcontainers for SQL Server.
Step 3Team SOPs: .github/prompts/*.prompt.md
Prompt files are reusable slash commands — shared "recipes" for analyst and programmer alike:
new-usecase.prompt.md — scaffold a MediatR command/query + validator + test.spec-to-issue.prompt.md — the analyst pastes a business need; Copilot structures it into a user story with Given/When/Then acceptance criteria, ready to become a GitHub Issue.review-security.prompt.md — OWASP checklist for new endpoints.explain-legacy.prompt.md — brownfield: explain an old module before changing it.
Step 4 AGENTS.md for the Coding Agent
When an issue is assigned to the Copilot coding agent (works autonomously and opens a PR), AGENTS.md at the root is its operational guide: how to build, how to test, and the definition of done (green build + passing tests + zero analyzer warnings). It's also read by other AI tools, so the repo isn't vendor-locked.
Step 5. The Hybrid Workflow
- Business states the need.
- Analyst runs
spec-to-issue.prompt.md → a GitHub Issue with measurable acceptance criteria. A good issue is a good prompt.
- Programmer triages: well-defined tasks (CRUD, small refactors, adding tests, reproducible bugs) go to the coding agent; architectural work stays in the IDE with Copilot Chat/agent mode.
- AI co-developers open PRs; Copilot Code Review gives the first pass, using the same instructions from Steps 1–2.
- The programmer is the final reviewer — every AI PR requires human review before merge.
"Several AI co-developers" = several issues running in parallel under the coding agent, with one programmer acting as tech lead/reviewer.
Step 6. Guardrails and Governance
- Branch protection: no direct pushes to
main; PR + at least one human approval.
- CI as referee: GitHub Actions runs
dotnet build, dotnet test, dotnet format --verify-no-changes, plus CodeQL/SonarQube. AI may be wrong; the pipeline must not stay silent.
- Org-level instructions: cross-repo policy — security standards, approved tech list, no secrets in code.
- PR convention: label AI PRs
ai-generated for auditing and metrics (lead time, rework rate).
Step 7. Greenfield vs Brownfield
| Aspect | New Project | Existing Repo |
|---|
| Start with |
Write instructions alongside scaffolding |
Agent-generated draft, then curate |
| Instruction focus |
Conventions you want |
Conventions actually in use + no-go zones (/legacy) |
| First AI tasks |
Scaffold use cases, tests, CI |
Add tests to critical code, document modules, small refactors |
| Main risk |
Over-engineering |
AI guessing inconsistent conventions |
Closing
The key isn't the model — it's the written context: copilot-instructions.md as the contract, .instructions.md as per-layer rules, prompt files as shared SOPs, and AGENTS.md as the autonomous agent's guide. Start with one file, one prompt, one small issue — then measure.
· · ·
Running a similar human + AI setup on your .NET team? I'd be curious how you split work between the coding agent and your reviewers — reach out via ridilabs.net.