/project-setup
Create or reorganize .NET solutions with clean project boundaries, repeatable SDK settings, and a maintainable baseline for libraries, apps, tests, CI, and local development. USE FOR: creating a new .NET solution or restructuring an existing one; setting up
$ npx -y skills add managedcode/dotnet-skills --skill project-setup --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/project-setup
Context preview
The summary Claude sees to decide when to auto-load this skill.
Create or reorganize .NET solutions with clean project boundaries, repeatable SDK settings, and a maintainable baseline for libraries, apps, tests, CI, and local development. USE FOR: creating a new .NET solution or restructuring an existing one; setting up
SKILL.md
project-setup.SKILL.mdname: project-setup
description: "Create or reorganize .NET solutions with clean project boundaries, repeatable SDK settings, and a maintainable baseline for libraries, apps, tests, CI, and local development. USE FOR: creating a new .NET solution or restructuring an existing one; setting up Directory.Build.props, shared package management, or repo-wide defaults; defining project. DO NOT USE FOR: unrelated stacks; generic tasks that do not need this specific guidance. INVOKES: inspect the repository context, edit targeted files, and run relevant build, test, lint, or validation commands when changes are made."
compatibility: "Best for new repositories or structural refactors of existing .NET solutions."
.NET Project Setup
Trigger On
- creating a new .NET solution or restructuring an existing one
- setting up `Directory.Build.props`, shared package management, or repo-wide defaults
- defining project layout for apps, libraries, and test projects
Workflow
1. Start from the app model and deployment target, then choose the smallest correct SDK and target framework set. 2. Use solution folders and project names that reflect bounded contexts or product areas, not temporary implementation details. 3. Centralize shared build settings, analyzer rules, nullable context, and package versions where it reduces duplication without hiding important differences. 4. Create test projects and CI hooks early so new projects do not drift into unverified templates. 5. Prefer project references and composition over circular dependencies or utility dumping grounds. 6. Document the local build, test, and run path in repo docs or `AGENTS.md` when the workflow is not obvious.
Current Upstream Notes
- The July 2026 "Build apps with .NET" Learn refresh reinforces app-model-first setup: console, web, worker, desktop, mobile, cloud, and AI entry points should drive SDK/template choice.
- `.NET SDK 10.0.302` is the current 10.0.3xx servicing SDK; it fixes Aspire AppHost launching and tool-runner duplicate-flag handling and enables file-based app `#:include` / `#:exclude` without feature flags. `.NET SDK 8.0.423` remains the current 8.0 servicing SDK. Keep `global.json` and CI images explicit for the selected line.
Deliver
- a coherent solution structure
- shared build defaults that are easy to reason about
- starter quality and testing hooks for future work
Validate
- projects have explicit responsibility boundaries
- shared MSBuild settings do not accidentally override platform-specific needs
- a new contributor can build and test the repo without guessing
References
- [patterns.md](references/patterns.md): solution layout conventions, `Directory.Build.props`, `Directory.Build.targets`, Central Package Management, `global.json`, `nuget.config`, analyzers, multi-targeting, and source link
- [templates.md](references/templates.md): `dotnet new` templates for console apps, class libraries, ASP.NET Core APIs, worker services, Blazor, test projects, .NET Aspire, and gRPC services
Read more
name: project-setup description: "Create or reorganize .NET solutions with clean project boundaries, repeatable SDK settings, and a maintainable baseline for libraries, apps, tests, CI, and local development. USE FOR: creating a new .NET solution or restructuring an existing one; setting up Directory.Build.props, shared package management, or repo-wide defaults; defining project. DO NOT USE FOR: unrelated stacks; generic tasks that do not need this specific guidance. INVOKES: inspect the repository context, edit targeted files, and run relevant build, test, lint, or validation commands when changes are made." compatibility: "Best for new repositories or structural refactors of existing .NET solutions."
.NET Project Setup
Trigger On
- creating a new .NET solution or restructuring an existing one
- setting up `Directory.Build.props`, shared package management, or repo-wide defaults
- defining project layout for apps, libraries, and test projects
Workflow
1. Start from the app model and deployment target, then choose the smallest correct SDK and target framework set. 2. Use solution folders and project names that reflect bounded contexts or product areas, not temporary implementation details. 3. Centralize shared build settings, analyzer rules, nullable context, and package versions where it reduces duplication without hiding important differences. 4. Create test projects and CI hooks early so new projects do not drift into unverified templates. 5. Prefer project references and composition over circular dependencies or utility dumping grounds. 6. Document the local build, test, and run path in repo docs or `AGENTS.md` when the workflow is not obvious.
Current Upstream Notes
- The July 2026 "Build apps with .NET" Learn refresh reinforces app-model-first setup: console, web, worker, desktop, mobile, cloud, and AI entry points should drive SDK/template choice.
- `.NET SDK 10.0.302` is the current 10.0.3xx servicing SDK; it fixes Aspire AppHost launching and tool-runner duplicate-flag handling and enables file-based app `#:include` / `#:exclude` without feature flags. `.NET SDK 8.0.423` remains the current 8.0 servicing SDK. Keep `global.json` and CI images explicit for the selected line.
Deliver
- a coherent solution structure
- shared build defaults that are easy to reason about
- starter quality and testing hooks for future work
Validate
- projects have explicit responsibility boundaries
- shared MSBuild settings do not accidentally override platform-specific needs
- a new contributor can build and test the repo without guessing
References
- [patterns.md](references/patterns.md): solution layout conventions, `Directory.Build.props`, `Directory.Build.targets`, Central Package Management, `global.json`, `nuget.config`, analyzers, multi-targeting, and source link
- [templates.md](references/templates.md): `dotnet new` templates for console apps, class libraries, ASP.NET Core APIs, worker services, Blazor, test projects, .NET Aspire, and gRPC services
Stop explaining .NET to your AI. Start building. We've all been there: asking Claude to use Entity Framework, only to get EF6 patterns in a .NET 8 project. Explaining to Copilot that Blazor Server and Blazor WebAssembly aren't the same thing.
Repo: managedcode/dotnet-skills
Other skills on dotnet-skills.
- /aspnet-core
Build, debug, modernize, or review ASP.NET Core applications with correct hosting, middleware, security, configuration, logging, and deployment patterns on current .NET. USE FOR: working on ASP.NET Core apps, services, or middleware; changing auth, routing, configuration,
Open skill - /aspire
Build, upgrade, and operate Aspire 13.4.x C# or TypeScript application hosts with the current CLI, AppHost, ServiceDefaults, integrations, dashboard, testing, MCP, and deployment patterns for distributed apps. USE FOR: Aspire.AppHost.Sdk, Aspire.Hosting.*,
Open skill - /azure-functions
Build, review, or migrate Azure Functions in .NET with correct execution model, isolated worker setup, bindings, DI, and Durable Functions patterns. USE FOR: working on Azure Functions in .NET; migrating from the in-process model to the isolated worker model; adding Durable
Open skill - /blazor
Build and review Blazor applications across server, WebAssembly, web app, and hybrid scenarios with correct component design, state flow, rendering, and hosting choices. USE FOR: building interactive web UIs with C# instead of JavaScript; choosing between Server, WebAssembly, or
Open skill - /entity-framework6
Maintain or migrate EF6-based applications with realistic guidance on what to keep, what to modernize, and when EF Core is or is not the right next step. USE FOR: EF6 codebases; runtime versus ORM migration decisions; EDMX, code-first, ObjectContext, and legacy data-access
Open skill - /entity-framework-core
Design, tune, or review EF Core data access with proper modeling, migrations, query translation, performance, and lifetime management for modern .NET applications. USE FOR: DbContext, migrations, model configuration, EF queries, tracking, loading, performance, transactions, and
Open skill

