Every new project starts the same way: create a repo, add a .gitignore, set up the folder structure, configure build properties, add an .editorconfig… it’s repetitive work that adds up quickly. GitHub template repositories solve this by letting you create a pre-configured starting point that you (or anyone) can use to spin up new repos with all your boilerplate already in place.

In this article, I’ll walk through how to create a template repository specifically designed for .NET 10 applications that work well with AI coding agents like GitHub Copilot, Claude Code, and others.

You can find the complete template at NimblePros/dotnet-codingagent-template. If you find it useful, leave a ⭐!

What is a GitHub Template Repository?

A template repository is a special type of GitHub repository that serves as a blueprint for new projects. Instead of forking (which maintains a link to the original) or cloning (which copies history), using a template creates a fresh repository with all the files but none of the commit history.

To make any repository a template, go to Settings → General and check the box Template repository. That’s it! Users will now see a green “Use this template” button on your repo page.

The Folder Structure 📁

A well-organized folder structure helps both human developers and AI agents understand where things belong. Here’s the structure used in our template:

├── src/                    # Application source code and projects
├── tests/                  # Test projects (unit tests, integration tests)
├── docs/                   # Documentation including ADRs
│   └── adrs/               # Architecture Decision Records
├── .github/                # GitHub workflows and configuration
├── .editorconfig           # Code style rules
├── .gitignore              # Git ignore patterns
├── AGENTS.md               # AI agent instructions
├── Directory.Build.props    # Shared MSBuild properties
├── Directory.Packages.props # Central Package Management
├── README.md               # Project documentation
└── Template.slnx           # Solution file (in modern xml format)

The separation of src/ and tests/ is a common convention that makes it easy to exclude test projects from production builds. The docs/ folder provides a home for documentation that lives with the code.

The README.md File 📄

Your README.md is the front door to your repository. For a template, it should include:

• Project overview: What this template is for
• Prerequisites: What developers need installed (.NET 10 SDK)
• Getting started: How to build and run
• Project structure: Quick reference for the folder layout
• Development guidelines: Link to detailed conventions

Here’s a snippet from the template’s README:

Getting Started

Prerequisites

• .NET 10 SDK or later

Building the Solution

# Restore dependencies and build all projects
dotnet build

# Build in Release mode
dotnet build -c Release

The key is making it easy for someone (or something) to get productive quickly.

The .slnx Solution File 🗂️

.NET 10 introduces a new XML-based solution file format with the .slnx extension. Unlike the traditional .sln file with its cryptic GUIDs and formatting, .slnx files are clean XML:

<Solution />

Yes, that’s the entire file for an empty solution! The new format is:

• Human-readable: Easy to understand and edit
• Merge-friendly: Better for source control
• Simpler: No more GUID soup

To add projects, you simply include them:

<Solution>
  <Project Path="src/MyApp/MyApp.csproj" />
  <Project Path="tests/MyApp.Tests/MyApp.Tests.csproj" />
</Solution>

Starting with an empty .slnx means AI agents can add projects as they create them without dealing with complex solution file syntax. It’s both human and AI optimized.

Central Package Management with Directory.Packages.props 📦

Central Package Management (CPM) is a game-changer for .NET projects. Instead of specifying versions in every .csproj file, you define them once:

<Project>
  <ItemGroup>
    <!-- Add package versions here -->
    <!-- <PackageVersion Include="Ardalis.GuardClauses" Version="5.0.0" /> -->
  </ItemGroup>
</Project>

Individual projects then reference packages without versions:

<PackageReference Include="Ardalis.GuardClauses" />

Benefits:

• Single source of truth: One place to update versions
• Consistency: All projects use the same versions
• Easier updates: Update once, apply everywhere
• AI-friendly: Agents know exactly where to add new packages

The template starts with an empty ItemGroup ready for packages to be added. Note that some new project templates do not always respect Central Package Management, so you may need to fix up projects when you first add them to the solution. Also, while this approach is appropriate in most solution files, if you have multiplte separate distributable applications or independent modules within your solution, you may want to have the ability to let them modify their package dependencies independently rather than globally.

Shared Build Properties with Directory.Build.props ⚙️

The Directory.Build.props file applies MSBuild properties to all projects in the directory tree. This eliminates repetition across .csproj files:

<Project>
  <PropertyGroup>
    <ManagePackageVersionsCentrally>true</ManagePackageVersionsCentrally>
    <TreatWarningsAsErrors>true</TreatWarningsAsErrors>
    <TargetFramework>net10.0</TargetFramework>
    <Nullable>enable</Nullable>
    <ImplicitUsings>enable</ImplicitUsings>
    <LangVersion>latest</LangVersion>
  </PropertyGroup>
  <PropertyGroup>
    <NoWarn>1591</NoWarn>
  </PropertyGroup>
</Project>

Key settings explained:

• ManagePackageVersionsCentrally: Enables CPM
• TreatWarningsAsErrors: Enforces code quality; much easier to start with than to turn on later
• TargetFramework: Sets .NET 10 for all projects
• Nullable: Enables nullable reference types
• ImplicitUsings: Reduces boilerplate using statements
• LangVersion: Uses the latest C# features
• NoWarn 1591: Suppresses missing XML comment warnings (remove to enforce documentation)

With these settings, new projects automatically inherit sensible defaults.

The .editorconfig File ✨

The .editorconfig file enforces consistent code style across your team—and across AI agents. Here are some highlights from the template:

# Code files
[*.{cs,csx,vb,vbx}]
indent_size = 2
insert_final_newline = true
charset = utf-8-bom

# File-scoped namespaces (enforced as warning)
csharp_style_namespace_declarations = file_scoped:warning

# Braces on new lines (Allman style)
csharp_new_line_before_open_brace = all

# Private fields with underscore prefix
dotnet_naming_style.prefix_underscore.required_prefix = _

Key conventions in the template:

• 2-space indentation (not 4, not tabs)
• File-scoped namespaces enforced with warnings
• Allman-style braces (opening brace on new line)
• Underscore prefix for private fields (_myField)
• PascalCase for constants

When AI agents generate code, they can read the .editorconfig and follow your team’s style. Running dotnet format will automatically fix any deviations. You can even add dotnet format checks/fixes as part of your build pipeline.

The .gitignore File 🙈

A comprehensive .gitignore prevents build artifacts, user settings, and other noise from polluting your repository. The template includes the standard Visual Studio/VS Code/.NET ignores:

• Build outputs (bin/, obj/)
• User files (*.user, .vs/)
• Package caches
• IDE settings
• OS files (.DS_Store, Thumbs.db)

The AGENTS.md File 🤖

This is where things get interesting for AI-assisted development. The AGENTS.md file provides instructions specifically for AI coding agents. While different tools may use different file names (Copilot by default will create a file at .github/copilot-instructions.md but does also support AGENTS.md), the concept is the same: give the AI context about your project. I recommend using AGENTS.md instead of an agent- or model- specific file so individual developers who may use different toolsets will all share the same set of agent instructions.

Here’s what to include:

Project Overview

Project Overview

This is a placeholder. Review the README.md and /src files for details about the repository purpose and structure and update this overview accordingly.

Framework and Language Settings

Target Framework & Language

• Framework: .NET 10.0 (net10.0)
• Language Version: Latest C# features enabled
• Nullable Reference Types: Enabled project-wide
• Treat Warnings as Errors: Enabled globally

Code Style Conventions

Code Style Conventions

Naming Conventions

• Private fields: Use underscore prefix with camelCase (_myField)
• Constants: Use PascalCase
• Interfaces: Prefix interfaces with I (e.g., IRepository)
• Async Methods: Suffix async methods with Async (e.g., GetByIdAsync)

Testing Conventions

Testing Conventions

• Use xUnit for all tests
• Follow Arrange-Act-Assert pattern
• Name test classes ClassName_MethodName.cs
• Name test methods DoesSomething_GivenSomeCondition
• Prefer NSubstitute for mocking
• Prefer Shouldly for assertions

The full AGENTS.md in the template covers:

• Build configuration and Central Package Management
• Code formatting rules
• Modern C# preferences (primary constructors, pattern matching)
• Configuration and logging practices
• Guard clauses and validation
• Security guidelines
• Documentation conventions

This file acts as a coding standards guide that both humans and AI can follow.

Architecture Decision Records (ADRs) 📋

The docs/adrs/ folder provides a home for Architecture Decision Records. The template includes a sample ADR:

ADR 0000: Use .NET 10 for This Solution

Status

Accepted

Context

We need to select a .NET framework version that provides modern language features, long-term support, and performance improvements for this template repository.

Decision

We will use .NET 10.0 as the target framework for all projects in this solution.

Consequences

Projects will benefit from the latest C# language features and runtime performance improvements, but will require developers to have .NET 10 SDK installed.

Alternatives Considered

We considered using .NET 8 LTS but chose .NET 10 for access to the newest framework capabilities and language features.

The naming convention 0000-YYYY-MM-DD-title.md makes it easy to sort decisions chronologically. ADRs help AI agents (and humans!) understand why certain decisions were made, not just what the code does.

Using the Template

Once your template is ready:

1. Mark it as a template: Settings → General → ✅ Template repository
2. Create from template: Click “Use this template” → “Create a new repository”
3. Customize: Update README.md, AGENTS.md project overview, and other files for your specific project
4. Rename the solution: Rename Template.slnx to match your project name

Summary

A well-crafted template repository saves time and enforces consistency across projects. For .NET 10 applications working with AI coding agents, key files include:

• README.md: Human-readable project documentation
• AGENTS.md: AI-readable coding conventions and context
• Directory.Build.props: Shared compiler settings
• Directory.Packages.props: Centralized package versions
• .editorconfig: Code style enforcement
• .gitignore: Clean repository hygiene
• .slnx: Modern solution file format
• docs/adrs/: Decision documentation

The NimblePros/dotnet-codingagent-template provides all of these out of the box. Fork it, customize it, and make it your own!

Further Reading 📖

NimblePros Blog Articles

• Creating Architecture Decision Records
• Streamlining Your NuGet Package Versions - Deep dive into Central Package Management
• Where C# Primary Constructors Make Sense - Best practices for primary constructors referenced in the AGENTS.md
• End of Line Snafu - EditorConfig and line endings in .NET projects

External Resources

• GitHub Template Repositories Documentation
• Central Package Management in NuGet
• .NET SDK-style Solution Files
• EditorConfig Documentation
• NimblePros dotnet-codingagent-template