Using Copilot Squad with Copilot CLI for Building .NET Web Applications

by Brad Jolicoeur

04/06/2026

I'm writing this article using Copilot Squad. Not as a marketing gimmick, but because I genuinely wanted to see if the tool could handle the meta-challenge of documenting itself while being productive. The answer? It's been surprisingly effective, and that's exactly why I'm sharing this with you.

If you've been exploring AI-assisted development with GitHub Copilot, you've likely experienced the power of AI pair programming. But what happens when you need more than just code completion? What if you could assemble an entire team of AI specialists—each with specific skills and knowledge—to help you build, test, and orchestrate .NET web applications?

That's where Copilot Squad comes in. Squad is an extension of GitHub Copilot CLI—the command-line interface to Copilot—that multiplies what you can accomplish by coordinating multiple AI agents, each focused on specific aspects of your development workflow. I'll show you how I use Squad to build .NET web applications, including how to track progress with GitHub Issues, orchestrate local development with .NET Aspire, test with Playwright through MCP integration, and ensure your Squad has the right skills for the job.

Prerequisites: You'll need GitHub CLI installed and authenticated (gh auth login), GitHub Copilot access, and .NET 8+ for the Aspire examples. Familiarity with ASP.NET Core and C# is assumed.

What is Copilot Squad?

Copilot Squad is a GitHub Copilot CLI feature that lets you create and manage a team of specialized AI agents within your development workflow. An agent is a specialized AI instance configured with specific expertise and context—a teammate with deep knowledge of one area. It's moving from a single AI pair programmer to a coordinated team where each agent has specific expertise, context, and responsibilities.

Squad differs from traditional Copilot chat in a few key ways:

Specialized Agents: Instead of one generalist AI, you define agents with specific roles—like a backend specialist who knows your .NET APIs, a frontend expert familiar with your UI patterns, or a DevOps agent who understands your deployment pipeline.

Persistent Context: Each agent remembers your project's patterns, conventions, and architectural decisions across sessions. This isn't a chat context window that resets—agents build up knowledge as your project evolves. This is what transforms Squad from a tool you fight with into something that actually gets better at your project over time.

Coordinated Workflows: Agents work together on complex tasks. You might have one agent generate API endpoints while another creates the corresponding tests. You coordinate who does what—Squad doesn't magically hand off work, but it makes the division of labor natural.

Skills System: You can define reusable skills—markdown files containing knowledge, patterns, and procedures—that agents reference across sessions and projects. These skills become your team's institutional knowledge.

The power isn't in any single agent doing something amazing; it's in the orchestration. When you need to add a new feature to a .NET web application, one agent might update the domain model, another modifies the API endpoints, a third adjusts the Aspire configuration, and a fourth generates integration tests using Playwright—all coordinated through natural conversation with you as the conductor.

Setting Up Your Squad for .NET Web App Development

The first step is defining your Squad with agents who have the right skills for .NET web development. Specialized agents handle coordination more effectively than generic capabilities—they know your patterns and conventions instead of guessing.

Here's the Squad setup I typically use for .NET web applications:

Core Development Agents

Backend Agent (Bender): This agent specializes in C# and .NET backend development. It knows about ASP.NET Core, Entity Framework, dependency injection patterns, and middleware pipelines. When I ask "Add a new API endpoint for user preferences," Bender handles the controller, service layer, and data access code.

Frontend Agent (Fry): Handles everything client-side—whether it's Blazor, Razor Pages, or a separate SPA. This agent knows about component patterns, state management, and frontend build tooling.

Testing Agent (Hermes): Focused exclusively on testing strategies. It writes unit tests, integration tests, and understands how to structure test projects in .NET. It knows xUnit, NUnit, Moq, and testing best practices.

Infrastructure Agents

DevOps Agent (Leela): Manages Aspire configuration, Docker files, CI/CD pipelines, and deployment manifests. When the app needs a new Redis cache or message queue, Leela adds it to the Aspire AppHost and configures service discovery.

Documentation Agent (Professor): Maintains API documentation, architectural decision records, and inline code comments. This agent ensures that as the codebase evolves, documentation stays current.

Creating Agent Skill Files

Skill files are markdown documents that give each agent expertise in your domain. These live in your project's .squad/ directory structure—typically one file per agent (e.g., agents/bender/skills.md). Here's what Bender's backend skills look like:

# Bender - Backend Development Skills

## Expertise
- ASP.NET Core Web APIs
- Entity Framework Core
- Domain-Driven Design patterns
- CQRS and MediatR
- Minimal APIs and controller-based endpoints
- Authentication and authorization with ASP.NET Core Identity

## Coding Conventions
- Use minimal APIs for simple CRUD operations
- Apply controller-based APIs for complex workflows
- Always inject dependencies through constructors
- Use async/await for all I/O operations
- Follow RESTful principles for endpoint design
- Return appropriate HTTP status codes (200, 201, 400, 404, etc.)

## Project Structure Patterns
- `/src/Domain` - Domain models and interfaces
- `/src/Application` - Application services and DTOs
- `/src/Infrastructure` - Data access and external services
- `/src/Api` - Controllers and API configuration

## When Adding New Endpoints
1. Define the domain model if needed
2. Create request/response DTOs
3. Implement service layer logic
4. Add API endpoint with proper validation
5. Update Swagger documentation
6. Consider authorization requirements

This skill file gives Bender context about not just what to build, but how to build it according to project conventions. When Bender creates a new API endpoint, it automatically follows these patterns without me having to explain them each time.

Skills for .NET Aspire Integration

Since we're using Aspire for local development orchestration, your DevOps agent needs specific Aspire knowledge:

# Leela - DevOps and Aspire Skills

## .NET Aspire Knowledge
- AppHost project structure and purpose
- Service discovery and named resources
- Adding databases (SQL Server, PostgreSQL, Redis)
- Message queues (RabbitMQ, Azure Service Bus)
- Configuring connection strings through service defaults
- Health checks and dashboard integration
- Service bindings and environment variables
- Orchestrating containerized services locally

## When Modifying AppHost Configuration
1. Understand current service topology
2. Add resource to AppHost with descriptive name
3. Configure appropriate bindings and environment variables
4. Update any dependent services' connection strings
5. Document changes in ADR if significant
6. Test through Aspire dashboard before committing

Leela uses this to confidently modify your Aspire configuration, add services, and ensure everything connects properly.

Skills for Testing with Playwright MCP

The Testing Agent needs to understand not just testing patterns but how to interact with your running application through Playwright:

# Hermes - Testing and Playwright MCP Skills

## Testing Frameworks & Tools
- xUnit for unit testing
- Integration tests with TestContainers
- Playwright for browser automation
- Moq for mocking dependencies
- Integration with Aspire for service URLs

## Playwright Best Practices via MCP
- Get application URLs from Aspire MCP context
- Use locators consistently (by role when possible)
- Verify behavior through UI and database assertions
- Capture screenshots on failure
- Test critical user flows end-to-end
- Clean up test data after scenarios

## When Writing Tests
1. Understand feature requirements from issue context
2. Write unit tests for isolated logic
3. Write integration tests for multi-layer scenarios
4. Use Playwright for critical UI workflows
5. Verify data persistence through direct DB queries
6. Document expected behavior in test names

These skills transformed into actual instruction guides agents reference while working.

Integrating GitHub Issues into Your Squad Workflow

GitHub Issues is where your Squad lives. Issues track features, bugs, and investigations—and Squad agents reference issues when deciding what to work on, update issues with progress, and link their work back to the original request.

Setting Up Issues for Squad

Create issues with clear acceptance criteria:

## Product Review Feature Implementation

### Description
Add the ability for customers to leave reviews on product detail pages.

### Acceptance Criteria
- [ ] Product model has Reviews collection
- [ ] API endpoint supports GET reviews and POST new review
- [ ] New review form on product detail page
- [ ] Reviews display newest first
- [ ] Database persists reviews correctly

### Technical Notes
- Use Entity Framework for data access
- Review form uses Blazor component
- Use Aspire for local dev environment

### Related Skills
- Backend API patterns (Bender)
- Blazor UI patterns (Fry)
- Integration testing (Hermes)
- Aspire configuration (Leela)

Squad agents read these issue descriptions and acceptance criteria to understand scope and requirements. The "Related Skills" section tells agents which of your team members should work on which parts.

The Squad Workflow on an Issue

Here's how a real feature request flows through a coordinated Squad:

Step 1: Scoping

$ gh copilot squad "Implement issue #104 - product reviews"

The squad reads the issue, breaks it into components:

Backend Agent identifies database schema changes and API endpoints
Frontend Agent sees the review form component needed
Testing Agent plans integration tests and UI scenarios
DevOps Agent checks if Aspire needs any new services

Step 2: Database and API Layer

$ gh copilot squad "Issue #104 - add Review entity and API endpoints"

Backend agent (Bender):

Creates Review entity with ProductId, UserId, Rating, Comment, CreatedDate
Adds Entity Framework migration
Creates ReviewsController or minimal API endpoints
Implements GET /products//reviews and POST /reviews
Generates Swagger documentation
Reports: "✅ Review API ready. Created endpoints and migration."

Step 3: Frontend Implementation

$ gh copilot squad "Issue #104 - build review UI components"

Frontend agent (Fry):

Creates ReviewForm Blazor component
Implements star rating UI
Adds review list display component
Integrates with review API endpoint

Step 4: Automated Testing

$ gh copilot squad "Implement issue #105 - test the complete review submission flow"

Testing agent (Hermes):

Gets application URLs from Aspire MCP
Launches Playwright browser
Navigates to a product page
Fills in review form (rating + comment)
Submits review
Verifies review appears in the review list
Checks database to confirm review was persisted
Examines Aspire traces to verify API calls
Reports: "✅ Review flow working. Review ID 42 created successfully."

Step 5: Verification and Refinement

You review the implementation and notice the review list isn't sorted by date. Instead of manually fixing it:

$ gh copilot squad "Reviews should display newest first"

Backend agent updates the API endpoint query:

var reviews = await _dbContext.Reviews
    .Where(r => r.ProductId == productId)
    .OrderByDescending(r => r.CreatedDate)  // Added ordering
    .ToListAsync(cancellationToken);

Testing agent re-runs the Playwright test and confirms the change works.

The Meta Experience

Remember, I mentioned at the start that I'm writing this article using Squad. Here's what that's looked like:

Research Phase: I asked my research agent to gather information about Squad's MCP integrations, Aspire capabilities, and best practices for agent skills.

Drafting Phase: My content writer agent (Fry, appropriately enough) drafted sections based on the research, following the style guide for Brad's blog.

Code Examples: The backend agent generated realistic C# code snippets that follow .NET conventions.

Review Phase: My documentation agent checked for clarity, structure, and completeness.

It's been genuinely useful. Not because Squad wrote perfect prose on the first try, but because it handled the mechanical parts—research, code examples, structure—while I focused on the narrative and ensuring technical accuracy. I've edited, refined, and added personal perspective throughout, but Squad eliminated the blank-page problem and accelerated the process significantly.

When to Use Copilot Squad for .NET Development

Squad isn't the right tool for every scenario. Here's my honest assessment of when it shines and when it doesn't:

Where Squad Excels

Building greenfield applications: When starting a new .NET project, Squad can scaffold structure, set up Aspire, create initial services, and establish patterns quickly.

Adding well-defined features: If you can describe a feature clearly ("Add user authentication with JWT" or "Implement product search with filtering"), Squad handles the implementation across multiple layers efficiently.

Exploratory testing: Using Aspire + Playwright MCP to verify behavior, test edge cases, and debug issues is genuinely faster than writing tests manually.

Maintaining consistency: With good skills defined, Squad applies patterns consistently across your codebase—something that's hard to achieve even with experienced human teams.

Documentation: Squad excels at keeping documentation current, generating API docs, and writing architectural decision records as you work.

Where Squad Struggles

Complex business logic: Squad is great at following patterns but can struggle with nuanced domain logic that requires deep business understanding. You'll need to provide detailed specifications or implement critical business rules yourself.

Performance optimization: While Squad can write performant code following best practices, identifying and fixing subtle performance issues requires human expertise and profiling tools.

Debugging obscure issues: Squad is helpful for common problems but can get lost with complex, multi-layered bugs that require intuition and deep system knowledge.

Design decisions: Architectural choices—like whether to use CQRS, how to structure your domain model, or which caching strategy to employ—require human judgment. Squad can implement decisions, not make them.

The Right Mindset

Think of Squad as a very capable team of junior developers who:

Follow instructions extremely well
Work incredibly fast
Never get tired or frustrated
Know patterns and syntax perfectly
But lack deep domain expertise and intuition

Your role shifts to architect and lead developer. You make the important decisions, provide context, review output, and guide the overall direction. Squad handles the implementation details, maintains consistency, and accelerates the mechanical parts of development.

Conclusion

Using Copilot Squad for .NET web development has fundamentally changed how I approach building applications. The combination of specialized agents, GitHub Issues integration, Aspire orchestration, and Playwright testing creates a workflow that feels less like coding and more like conducting a team.

The key to success is investing in skills. Generic AI can write generic code, but Squad with well-defined skills writes your code, following your conventions, integrated with your architecture. The skills system transforms Squad from a curiosity into a genuinely productive development partner.

.NET Aspire deserves special mention as an enabler. By handling local orchestration so elegantly, Aspire removes friction from the development loop. Squad can make changes and immediately verify them through the Aspire dashboard. The MCP integration means Squad understands the runtime environment, not just the code. This tight feedback loop is what makes the whole system work.

The Playwright MCP integration is the cherry on top—giving Squad the ability to interact with your running application creates testing capabilities that would otherwise require significant infrastructure. Being able to say "verify the checkout flow works" and getting an answer in seconds is transformative.

Is Squad perfect? No. You'll still write critical business logic yourself, make architectural decisions, and debug complex issues. But for the 70% of development work that's implementing well-understood patterns, Squad is remarkably effective.

The meta-experience of using Squad to write about Squad has been enlightening. It's shown me that the technology is mature enough for real work, but more importantly, it's revealed the human role: providing direction, making judgments, and ensuring quality. Squad amplifies your capabilities; it doesn't replace your expertise.

If you're building .NET web applications, give Copilot Squad a try. Start small—create a simple Squad with one or two agents, define basic skills, build a feature. As you get comfortable with the workflow, expand your Squad's capabilities. You might find, like I did, that it changes how you think about development entirely.