Agent skill

Dotnet Project Structure

by Aaronontheweb in Aaronontheweb/dotnet-skills

Modern .NET project structure including .slnx solution format, Directory.Build.props, central package management, SourceLink, version management with RELEASENOTES.md, and SDK pinning with global.json.

MITAuto-check passedDevelopment

Install Dotnet Project Structure

skills CLI
$ npx skills add Aaronontheweb/dotnet-skills --skill dotnet-project-structure -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install Aaronontheweb/dotnet-skills dotnet-project-structure --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/Aaronontheweb/dotnet-skills.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/project-structure .claude/skills/dotnet-project-structure && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
dotnet-project-structure
GitHub stars
1.2k
Used in
1 other repo
Token cost
~3.8k tokens
SKILL.md length
579 words
Files
1
Skills in repo
33
Repo updated
First seen
Licence
MIT

At a glance

Modern .NET project structure including .slnx solution format, Directory.Build.props, central package management, SourceLink, version management with RELEASENOTES.md, and SDK pinning with global.json.

  • Works in 4 steps: Open the solution → Select the Solution in Solution Explorer → Go to File > Save Solution As... → …
  • Tasks that involve Changelog and release notes
  • SKILL.md covers When to Use This Skill, Related Skills, Solution File Format (.slnx) and Directory.Build.props, plus 6 more sections
  • Calls dotnet; reaches github.com and api.nuget.org; needs NUGET_API_KEY

What it does

Dotnet Project Structure is an agent skill from Aaronontheweb/dotnet-skills. Modern .NET project structure including .slnx solution format, Directory.Build.props, central package management, SourceLink, version management with RELEASENOTES.md, and SDK pinning with global.json.

Its SKILL.md is about 3.8k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Development, covering Changelog and release notes. It works with .NET. The repository describes itself as: Claude Code skills and sub-agents for .NET Developers. The licence is MIT.

When your agent uses it

  • Tasks that involve Changelog and release notes

Example prompts

  • “/dotnet-project-structure”

Workflow steps

4 steps, taken from the first numbered list in SKILL.md.

  1. Open the solution
  2. Select the Solution in Solution Explorer
  3. Go to File > Save Solution As...
  4. Change "Save as type" to Xml Solution File (*.slnx)

What it can do on your machine

Read from SKILL.md and the folder at commit e426ed9. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • dotnet

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    Hosts in commands or code, which the agent is likely to contact:

    • github.com
    • api.nuget.org
    • pkgs.dev.azure.com

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names these keys or tokens, usually read from environment variables:

    • NUGET_API_KEY

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Dotnet Project Structure loads about 3.8k tokens when it runs. Until then it costs about 57 tokens; SKILL.md has 579 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~57
When it runs · the whole SKILL.md, loaded when a task matches
~3.8k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from Aaronontheweb/dotnet-skills at commit e426ed9, republished under its MIT licence (© Aaronontheweb). 579 words, ~3,792 tokens.

Download SKILL.mdSave it as .claude/skills/dotnet-project-structure/SKILL.md (or your agent's skills folder).
name
dotnet-project-structure
description
Modern .NET project structure including .slnx solution format, Directory.Build.props, central package management, SourceLink, version management with RELEASE_NOTES.md, and SDK pinning with global.json.
invocable
false

.NET Project Structure and Build Configuration

When to Use This Skill

Use this skill when:

  • Setting up a new .NET solution with modern best practices
  • Configuring centralized build properties across multiple projects
  • Implementing central package version management
  • Setting up SourceLink for debugging and NuGet packages
  • Automating version management with release notes
  • Pinning SDK versions for consistent builds
  • dotnet-local-tools - Managing local .NET tools with dotnet-tools.json
  • microsoft-extensions-configuration - Configuration validation patterns

Solution File Format (.slnx)

The .slnx format is the modern XML-based solution file format introduced in .NET 9. It replaces the traditional .sln format.

Benefits Over Traditional .sln
Aspect.sln (Legacy).slnx (Modern)
FormatCustom text formatStandard XML
ReadabilityGUIDs, cryptic syntaxClean, human-readable
Version controlHard to diff/mergeEasy to diff/merge
EditingIDE requiredAny text editor
Version Requirements
ToolMinimum Version
.NET SDK9.0.200
Visual Studio17.13
MSBuildVisual Studio Build Tools 17.13

Note: Starting with .NET 10, dotnet new sln creates .slnx files by default. In .NET 9, you must explicitly migrate or specify the format.

Example .slnx File
xml
<Solution>
  <Folder Name="/build/">
    <File Path="Directory.Build.props" />
    <File Path="Directory.Packages.props" />
    <File Path="global.json" />
    <File Path="NuGet.Config" />
    <File Path="README.md" />
  </Folder>
  <Folder Name="/src/">
    <Project Path="src/MyApp/MyApp.csproj" />
    <Project Path="src/MyApp.Core/MyApp.Core.csproj" />
  </Folder>
  <Folder Name="/tests/">
    <Project Path="tests/MyApp.Tests/MyApp.Tests.csproj" />
  </Folder>
</Solution>
Migrating from .sln to .slnx

Use the dotnet sln migrate command to convert existing solutions:

bash
# Migrate a specific solution file
dotnet sln MySolution.sln migrate

# Or if only one .sln exists in the directory, just run:
dotnet sln migrate

Important: Do not keep both .sln and .slnx files in the same repository. This causes issues with automatic solution detection and can lead to sync problems. After migration, delete the old .sln file.

You can also migrate in Visual Studio:

  1. Open the solution
  2. Select the Solution in Solution Explorer
  3. Go to File > Save Solution As...
  4. Change "Save as type" to Xml Solution File (*.slnx)
Creating a New .slnx Solution
bash
# .NET 10+: Creates .slnx by default
dotnet new sln --name MySolution

# .NET 9: Specify the format explicitly
dotnet new sln --name MySolution --format slnx

# Add projects (works the same for both formats)
dotnet sln add src/MyApp/MyApp.csproj
Recommendation

If you're using .NET 9.0.200 or later, migrate your solutions to .slnx. The benefits are significant:

  • Dramatically fewer merge conflicts (no random GUIDs changing)
  • Human-readable and editable in any text editor
  • Consistent with modern .csproj format
  • Better diff/review experience in pull requests

Directory.Build.props

Directory.Build.props provides centralized build configuration that applies to all projects in a directory tree. Place it at the solution root.

Complete Example
xml
<Project>
  <!-- Metadata -->
  <PropertyGroup>
    <Authors>Your Team</Authors>
    <Company>Your Company</Company>
    <!-- Dynamic copyright year - updates automatically -->
    <Copyright>Copyright © 2020-$([System.DateTime]::Now.Year) Your Company</Copyright>
    <Product>Your Product</Product>
    <PackageProjectUrl>https://github.com/yourorg/yourrepo</PackageProjectUrl>
    <RepositoryUrl>https://github.com/yourorg/yourrepo</RepositoryUrl>
    <PackageLicenseExpression>Apache-2.0</PackageLicenseExpression>
    <PackageTags>your;tags;here</PackageTags>
  </PropertyGroup>

  <!-- C# Language Settings -->
  <PropertyGroup>
    <LangVersion>latest</LangVersion>
    <Nullable>enable</Nullable>
    <ImplicitUsings>enable</ImplicitUsings>
    <TreatWarningsAsErrors>true</TreatWarningsAsErrors>
    <NoWarn>$(NoWarn);CS1591</NoWarn> <!-- Missing XML comments -->
  </PropertyGroup>

  <!-- Version Management -->
  <PropertyGroup>
    <VersionPrefix>1.0.0</VersionPrefix>
    <PackageReleaseNotes>See RELEASE_NOTES.md</PackageReleaseNotes>
  </PropertyGroup>

  <!-- Target Framework Definitions (reusable properties) -->
  <PropertyGroup>
    <NetStandardLibVersion>netstandard2.0</NetStandardLibVersion>
    <NetLibVersion>net8.0</NetLibVersion>
    <NetTestVersion>net9.0</NetTestVersion>
  </PropertyGroup>

  <!-- SourceLink Configuration -->
  <PropertyGroup>
    <PublishRepositoryUrl>true</PublishRepositoryUrl>
    <EmbedUntrackedSources>true</EmbedUntrackedSources>
    <IncludeSymbols>true</IncludeSymbols>
    <SymbolPackageFormat>snupkg</SymbolPackageFormat>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.SourceLink.GitHub" PrivateAssets="All" />
  </ItemGroup>

  <!-- NuGet Package Assets -->
  <ItemGroup>
    <None Include="$(MSBuildThisFileDirectory)logo.png" Pack="true" PackagePath="\" />
    <None Include="$(MSBuildThisFileDirectory)README.md" Pack="true" PackagePath="\" />
  </ItemGroup>

  <PropertyGroup>
    <PackageIcon>logo.png</PackageIcon>
    <PackageReadmeFile>README.md</PackageReadmeFile>
  </PropertyGroup>

  <!-- Global Using Statements -->
  <ItemGroup>
    <Using Include="System.Collections.Immutable" />
  </ItemGroup>
</Project>
Key Patterns
xml
<Copyright>Copyright © 2020-$([System.DateTime]::Now.Year) Your Company</Copyright>

Uses MSBuild property functions to insert current year at build time. No manual updates needed.

Show full SKILL.md (232 more words)Show less
Reusable Target Framework Properties

Define target frameworks once, reference everywhere:

xml
<!-- In Directory.Build.props -->
<PropertyGroup>
  <NetLibVersion>net8.0</NetLibVersion>
  <NetTestVersion>net9.0</NetTestVersion>
</PropertyGroup>

<!-- In MyApp.csproj -->
<PropertyGroup>
  <TargetFramework>$(NetLibVersion)</TargetFramework>
</PropertyGroup>

<!-- In MyApp.Tests.csproj -->
<PropertyGroup>
  <TargetFramework>$(NetTestVersion)</TargetFramework>
</PropertyGroup>

SourceLink enables step-through debugging of NuGet packages:

xml
<PropertyGroup>
  <PublishRepositoryUrl>true</PublishRepositoryUrl>
  <EmbedUntrackedSources>true</EmbedUntrackedSources>
  <IncludeSymbols>true</IncludeSymbols>
  <SymbolPackageFormat>snupkg</SymbolPackageFormat>
</PropertyGroup>

<ItemGroup>
  <!-- Choose the right provider for your source control -->
  <PackageReference Include="Microsoft.SourceLink.GitHub" PrivateAssets="All" />
  <!-- Or: Microsoft.SourceLink.AzureRepos.Git -->
  <!-- Or: Microsoft.SourceLink.GitLab -->
  <!-- Or: Microsoft.SourceLink.Bitbucket.Git -->
</ItemGroup>

Directory.Packages.props - Central Package Management

Central Package Management (CPM) provides a single source of truth for all NuGet package versions.

Setup
xml
<Project>
  <PropertyGroup>
    <ManagePackageVersionsCentrally>true</ManagePackageVersionsCentrally>
  </PropertyGroup>

  <!-- Define version variables for related packages -->
  <PropertyGroup>
    <AkkaVersion>1.5.35</AkkaVersion>
    <AspireVersion>9.1.0</AspireVersion>
  </PropertyGroup>

  <!-- Application Dependencies -->
  <ItemGroup Label="App Dependencies">
    <PackageVersion Include="Akka" Version="$(AkkaVersion)" />
    <PackageVersion Include="Akka.Cluster" Version="$(AkkaVersion)" />
    <PackageVersion Include="Akka.Persistence" Version="$(AkkaVersion)" />
    <PackageVersion Include="Microsoft.Extensions.Hosting" Version="9.0.0" />
  </ItemGroup>

  <!-- Build/Tooling Dependencies -->
  <ItemGroup Label="Build Dependencies">
    <PackageVersion Include="Microsoft.SourceLink.GitHub" Version="8.0.0" />
  </ItemGroup>

  <!-- Test Dependencies -->
  <ItemGroup Label="Test Dependencies">
    <PackageVersion Include="xunit" Version="2.9.3" />
    <PackageVersion Include="xunit.runner.visualstudio" Version="3.0.1" />
    <PackageVersion Include="FluentAssertions" Version="7.0.0" />
    <PackageVersion Include="Microsoft.NET.Test.Sdk" Version="17.12.0" />
    <PackageVersion Include="coverlet.collector" Version="6.0.3" />
  </ItemGroup>
</Project>
Consuming Packages (No Version Needed)
xml
<!-- In MyApp.csproj -->
<ItemGroup>
  <PackageReference Include="Akka" />
  <PackageReference Include="Akka.Cluster" />
  <PackageReference Include="Microsoft.Extensions.Hosting" />
</ItemGroup>

<!-- In MyApp.Tests.csproj -->
<ItemGroup>
  <PackageReference Include="xunit" />
  <PackageReference Include="FluentAssertions" />
  <PackageReference Include="Microsoft.NET.Test.Sdk" />
</ItemGroup>
Benefits
  1. Single source of truth - All versions in one file
  2. No version drift - All projects use same versions
  3. Easy updates - Change once, applies everywhere
  4. Grouped packages - Version variables for related packages (e.g., all Akka packages)

global.json - SDK Version Pinning

Pin the .NET SDK version for consistent builds across all environments.

json
{
  "sdk": {
    "version": "9.0.200",
    "rollForward": "latestFeature"
  }
}
Roll Forward Policies
PolicyBehavior
disableExact version required
patchSame major.minor, latest patch
featureSame major, latest minor.patch
latestFeatureSame major, latest feature band
minorSame major, latest minor
latestMinorSame major, latest minor
majorLatest SDK (not recommended)

Recommended: latestFeature - Allows patch updates within the same feature band.


Version Management with RELEASE_NOTES.md

Release Notes Format
markdown
#### 1.2.0 January 15th 2025 ####

- Added new feature X
- Fixed bug in Y
- Improved performance of Z

#### 1.1.0 December 10th 2024 ####

- Initial release with features A, B, C
Parsing Script (getReleaseNotes.ps1)
powershell
function Get-ReleaseNotes {
    param (
        [Parameter(Mandatory=$true)]
        [string]$MarkdownFile
    )

    $content = Get-Content -Path $MarkdownFile -Raw
    $sections = $content -split "####"

    $result = [PSCustomObject]@{
        Version      = $null
        Date         = $null
        ReleaseNotes = $null
    }

    if ($sections.Count -ge 3) {
        $header = $sections[1].Trim()
        $releaseNotes = $sections[2].Trim()

        $headerParts = $header -split " ", 2
        if ($headerParts.Count -eq 2) {
            $result.Version = $headerParts[0]
            $result.Date = $headerParts[1]
        }

        $result.ReleaseNotes = $releaseNotes
    }

    return $result
}
Version Bump Script (bumpVersion.ps1)
powershell
function UpdateVersionAndReleaseNotes {
    param (
        [Parameter(Mandatory=$true)]
        [PSCustomObject]$ReleaseNotesResult,
        [Parameter(Mandatory=$true)]
        [string]$XmlFilePath
    )

    $xmlContent = New-Object XML
    $xmlContent.Load($XmlFilePath)

    # Update VersionPrefix
    $versionElement = $xmlContent.SelectSingleNode("//VersionPrefix")
    $versionElement.InnerText = $ReleaseNotesResult.Version

    # Update PackageReleaseNotes
    $notesElement = $xmlContent.SelectSingleNode("//PackageReleaseNotes")
    $notesElement.InnerText = $ReleaseNotesResult.ReleaseNotes

    $xmlContent.Save($XmlFilePath)
}
Build Script (build.ps1)
powershell
# Load helper scripts
. "$PSScriptRoot\scripts\getReleaseNotes.ps1"
. "$PSScriptRoot\scripts\bumpVersion.ps1"

# Parse release notes and update Directory.Build.props
$releaseNotes = Get-ReleaseNotes -MarkdownFile (Join-Path -Path $PSScriptRoot -ChildPath "RELEASE_NOTES.md")
UpdateVersionAndReleaseNotes -ReleaseNotesResult $releaseNotes -XmlFilePath (Join-Path -Path $PSScriptRoot -ChildPath "Directory.Build.props")

Write-Output "Updated to version $($releaseNotes.Version)"
CI/CD Integration
yaml
# GitHub Actions example
- name: Update version from release notes
  shell: pwsh
  run: ./build.ps1

- name: Build
  run: dotnet build -c Release

- name: Pack with tag version
  run: dotnet pack -c Release /p:PackageVersion=${{ github.ref_name }}

- name: Push to NuGet
  run: dotnet nuget push **/*.nupkg --api-key ${{ secrets.NUGET_API_KEY }} --source https://api.nuget.org/v3/index.json

NuGet.Config

Configure NuGet sources and behavior:

xml
<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <solution>
    <add key="disableSourceControlIntegration" value="true" />
  </solution>

  <packageSources>
    <clear />
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" />
    <!-- Add private feeds if needed -->
    <!-- <add key="MyCompany" value="https://pkgs.dev.azure.com/myorg/_packaging/myfeed/nuget/v3/index.json" /> -->
  </packageSources>
</configuration>

Key Settings:

  • <clear /> - Remove inherited/default sources for reproducible builds
  • disableSourceControlIntegration - Prevents TFS/Git integration issues

Complete Project Structure

MySolution/
├── .config/
│   └── dotnet-tools.json           # Local .NET tools
├── .github/
│   └── workflows/
│       ├── pr-validation.yml       # PR checks
│       └── release.yml             # NuGet publishing
├── scripts/
│   ├── getReleaseNotes.ps1         # Parse RELEASE_NOTES.md
│   └── bumpVersion.ps1             # Update Directory.Build.props
├── src/
│   ├── MyApp/
│   │   └── MyApp.csproj
│   └── MyApp.Core/
│       └── MyApp.Core.csproj
├── tests/
│   └── MyApp.Tests/
│       └── MyApp.Tests.csproj
├── Directory.Build.props           # Centralized build config
├── Directory.Packages.props        # Central package versions
├── MySolution.slnx                 # Modern solution file
├── global.json                     # SDK version pinning
├── NuGet.Config                    # Package source config
├── build.ps1                       # Build orchestration
├── RELEASE_NOTES.md                # Version history
├── README.md                       # Project documentation
└── logo.png                        # Package icon

Quick Reference

FilePurpose
MySolution.slnxModern XML solution file
Directory.Build.propsCentralized build properties
Directory.Packages.propsCentral package version management
global.jsonSDK version pinning
NuGet.ConfigPackage source configuration
RELEASE_NOTES.mdVersion history (parsed by build)
build.ps1Build orchestration script
.config/dotnet-tools.jsonLocal .NET tools

© Aaronontheweb, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in skills/project-structure of Aaronontheweb/dotnet-skills.

Open the folder on GitHubat commit e426ed9

Used in 1 other repository

We found 1 copy of this SKILL.md (exact, near-identical or edited) in other folders, from 1 other GitHub owner. This page covers the copy in Aaronontheweb/dotnet-skills, which our catalogue first saw on October 7, 2026.

Compare with similar skills

Dotnet Project Structure next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Dotnet Project Structure compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Dotnet Project Structure this skillAaronontheweb/dotnet-skills1.2k1 repos~3.8kAutomated safety check: PassMIT
.NET Release Verificationdotnet/core22k—~1.8kAutomated safety check: PassMIT
Add Analyzerdotnet/roslynator3.5k—~1.3kAutomated safety check: PassCustom licence
Generate .NET Release changes.jsondotnet/core22k—~1.7kAutomated safety check: PassMIT
Release Feature Scoringdotnet/core22k—~2.2kAutomated safety check: PassMIT
Release Notes Editorial Reviewdotnet/core22k—~1.6kAutomated safety check: PassMIT

Similar skills

  • Official

    Validates .NET release data with the release-notes CLI: download URL liveness, SHA512 hashes, CDN latest.version files and aka.ms redirects.

    22k GitHub stars~1.8k tokensUpdated yesterday
    DevelopmentAuto-check passed
  • Add Analyzer

    dotnet/roslynator

    Official

    A skill your agent uses when adding a new RCS diagnostic in roslynator (RCS0 formatting, RCS1 general, RCS9 code-analysis), wiring roslynator EditorConfig options, or when docs say CHANGELOG.md…

    3.5k GitHub stars~1.3k tokensUpdated 4 days ago
    DevelopmentAuto-check passed
  • Produces the changes.json manifest for a .NET preview, RC or GA milestone by choosing the right VMR base and head refs and running release-notes generate changes.

    22k GitHub stars~1.7k tokensUpdated yesterday
    DevelopmentAuto-check passed
  • Official

    Ranks the changes in a release manifest and writes a scored features file that release notes, docs and blog posts can each cut at their own threshold.

    22k GitHub stars~2.2k tokensUpdated yesterday
    DevelopmentAuto-check passed
  • Official

    Audits a scored features.json file and its draft release notes against editorial examples to catch over-scored, under-scored, or missing entries.

    22k GitHub stars~1.6k tokensUpdated yesterday
    DevelopmentAuto-check passed
  • Release Roslynator

    dotnet/roslynator

    Official

    A skill your agent uses when shipping a roslynator release, rolling CHANGELOG.md [Unreleased], updating the VS Code extension changelog, creating a GitHub v release, or optionally tagging cli-v.

    3.5k GitHub stars~1k tokensUpdated 4 days ago
    DevelopmentAuto-check passed

More from Aaronontheweb/dotnet-skills

All 33 skills in this repo
  • .NET API Compatibility Design

    Aaronontheweb/dotnet-skills

    Applies extend-only design rules to NuGet packages and distributed systems, covering source, binary and wire compatibility and how to deprecate members safely.

    1.2k GitHub starsUsed in 2 repos~2.7k tokens
    Auto-check passed
  • .NET Trimming and Native AOT

    Aaronontheweb/dotnet-skills

    Guides making .NET libraries trimming-safe and Native-AOT compatible: the MSBuild properties, trimming attributes, warning codes and a playbook of safe patterns.

    1.2k GitHub stars~2.9k tokensUpdated 21 days ago
    Auto-check passed
  • Akka.Hosting Actor Patterns

    Aaronontheweb/dotnet-skills

    Shows how to build entity actors with Akka.Hosting so the same code runs in local unit tests and in a sharded cluster in production.

    1.2k GitHub starsUsed in 1 repo~5k tokens
    Auto-check passed
  • Akka.NET Best Practices

    Aaronontheweb/dotnet-skills

    Guidance for Akka.NET actor systems covering EventStream versus DistributedPubSub, supervision, Props versus DependencyResolver, work distribution and testable cluster code.

    1.2k GitHub starsUsed in 1 repo~3.3k tokens
    Auto-check passed
  • Akka.NET Management and Discovery

    Aaronontheweb/dotnet-skills

    Sets up Akka.Management and Cluster.Bootstrap so Akka.NET clusters form through service discovery on Kubernetes, Azure or config instead of static seed nodes.

    1.2k GitHub starsUsed in 1 repo~2.5k tokens
    Auto-check passed
  • Akka.NET Testing Patterns

    Aaronontheweb/dotnet-skills

    Shows how to test Akka.NET actors with Akka.Hosting.TestKit: swapping services for fakes, using TestProbes, and checking persistence, plus when the older TestKit still fits.

    1.2k GitHub starsUsed in 1 repo~2.4k tokens
    Auto-check passed

Works with

Categories

Questions about Dotnet Project Structure

What does Dotnet Project Structure do?

Modern .NET project structure including .slnx solution format, Directory.Build.props, central package management, SourceLink, version management with RELEASENOTES.md, and SDK pinning with global.json. Dotnet Project Structure is an agent skill from Aaronontheweb/dotnet-skills.json.

When should I use Dotnet Project Structure?

Dotnet Project Structure fits situations like: tasks that involve Changelog and release notes.

How do I install Dotnet Project Structure in Claude Code?

Run `npx skills add Aaronontheweb/dotnet-skills --skill dotnet-project-structure -a claude-code`. Or copy the skill folder (skills/project-structure in Aaronontheweb/dotnet-skills) into .claude/skills/dotnet-project-structure in your project. Claude Code loads it when a task matches its description.

How do I install Dotnet Project Structure in Codex?

Run `npx skills add Aaronontheweb/dotnet-skills --skill dotnet-project-structure -a codex`. Or copy the skill folder (skills/project-structure in Aaronontheweb/dotnet-skills) into .agents/skills/dotnet-project-structure in your project. Codex loads it when a task matches its description.

Can I use Dotnet Project Structure in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add Aaronontheweb/dotnet-skills --skill dotnet-project-structure -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/dotnet-project-structure, .gemini/skills/dotnet-project-structure, .github/skills/dotnet-project-structure and .opencode/skills/dotnet-project-structure in your project.

What does Dotnet Project Structure need to run?

Going by SKILL.md and its folder, Dotnet Project Structure needs the command-line tools its instructions call (dotnet) and credentials named NUGET_API_KEY.

Does Dotnet Project Structure access the network?

SKILL.md names 3 domains. In commands or code: github.com, api.nuget.org and pkgs.dev.azure.com; the agent is likely to contact these when it follows the instructions. This is read from the text; nothing was executed.

Is Dotnet Project Structure safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Dotnet Project Structure use?

Dotnet Project Structure is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Dotnet Project Structure use?

About 3.8k tokens (SKILL.md is roughly 15k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Dotnet Project Structure?

Skills that share tags, products or a category with Dotnet Project Structure: .NET Release Verification (dotnet/core, 22k stars), Add Analyzer (dotnet/roslynator, 3.5k stars), Generate .NET Release changes.json (dotnet/core, 22k stars) and Release Feature Scoring (dotnet/core, 22k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Dotnet Project Structure?

Aaronontheweb (a GitHub user) maintains it in Aaronontheweb/dotnet-skills, which has 1,203 GitHub stars. The repository holds 33 skills in this directory. The repository was last updated on September 17, 2026.

Source: Aaronontheweb/dotnet-skills on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.