本文へ移動
cccskills
無料GitHub で公開

dotnet-tooling

.NET SDK and NuGet tooling conventions: dotnet CLI commands (new/build/run/test/publish/restore/format), NuGet package management (PackageReference, Directory.Packages.props central package management, packages.lock.json), project file conventions (.csproj, .sln, global.json, Directory.Build.props), multi-targeting, and dotnet format. Stack-agnostic — referenced by every .NET plugin in the marketplace. Use this skill to: - Detect the .NET SDK version and run all commands via the dotnet CLI. - Manage NuGet dependencies safely (central package management, no floating versions). - Configure project files and solution-wide properties in Directory.Build.props. - Format code consistently with dotnet format. Do NOT use this skill for: - Framework-specific tooling (dotnet ef migrations, aspnet-codegenerator — those are in aspnet-core-plugin:aspnet-conventions). - Testing patterns — see csharp-foundation:dotnet-testing. - C# language idioms — see csharp-foundation:csharp-conventions.

インストール方法を見る

含まれるファイル(1)

  • SKILL.md8.0 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

.NET Tooling (stack-agnostic)

Project detection

Determine the project structure at the start of every task:

SignalMeaning
*.sln existsSolution file — multiple projects; use dotnet build <solution>.sln
Single *.csproj in rootSingle-project layout
global.json existsSDK version is pinned — read it first
Directory.Build.props existsSolution-wide MSBuild properties apply
Directory.Packages.props existsCentral Package Management is active — do not specify versions in individual .csproj files

dotnet CLI — core commands

Always run dotnet commands from the directory containing the .sln or .csproj (or pass the path explicitly).

# Restore NuGet packages
dotnet restore

# Build (all projects in the solution, or a single project)
dotnet build
dotnet build MyApp.sln
dotnet build src/MyApp/MyApp.csproj

# Run (application project)
dotnet run --project src/MyApp/MyApp.csproj

# Run tests
dotnet test
dotnet test --filter "Category=Unit"
dotnet test --logger "trx;LogFileName=results.trx"

# Publish (Release, self-contained optional)
dotnet publish -c Release -o ./publish
dotnet publish -c Release --runtime linux-x64 --self-contained

# Check outdated packages
dotnet list package --outdated

# Format code (respects .editorconfig)
dotnet format

# Verify formatting without writing changes (useful in CI)
dotnet format --verify-no-changes

global.json — pin the SDK version

{
  "sdk": {
    "version": "8.0.404",
    "rollForward": "latestPatch"
  }
}

Always read global.json first to learn which SDK version is in use. Do not recommend commands or features that require a higher SDK version than what is pinned.

rollForward: "latestPatch" allows minor patch upgrades automatically — safe for CI. Use "disable" for strict reproducibility.

.csproj — project file conventions

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>   <!-- or net9.0, net10.0 -->
    <Nullable>enable</Nullable>                  <!-- always enable -->
    <ImplicitUsings>enable</ImplicitUsings>      <!-- reduces boilerplate using directives -->
    <TreatWarningsAsErrors>true</TreatWarningsAsErrors>  <!-- recommended for new projects -->
    <AnalysisLevel>latest</AnalysisLevel>        <!-- Roslyn analyzers at latest rules set -->
  </PropertyGroup>

  <ItemGroup>
    <!-- With Central Package Management: version goes in Directory.Packages.props -->
    <PackageReference Include="Microsoft.Extensions.Logging.Abstractions" />
    <PackageReference Include="Newtonsoft.Json" />

    <!-- Without CPM: pin versions explicitly — no floating ranges -->
    <!-- <PackageReference Include="Serilog" Version="4.1.0" /> -->
  </ItemGroup>

</Project>

Never use floating version ranges (*, 1.*, [1.0,)) — they break reproducible builds. Pin exact or minimum patch versions.

NuGet — PackageReference lifecycle

# Add a package
dotnet add package Serilog --version 4.1.0
dotnet add src/MyApp/MyApp.csproj package FluentValidation

# Remove a package
dotnet remove package Serilog

# Inspect the dependency graph
dotnet list package
dotnet list package --include-transitive
dotnet list package --outdated

When to add a package

  1. Check if the framework already provides the functionality (Microsoft.Extensions.* for DI, logging, configuration).
  2. Prefer packages with active maintenance, wide adoption, and no critical CVEs.
  3. Note the addition in DECISIONS — non-trivial additions change the project's supply-chain footprint.

Central Package Management (Directory.Packages.props)

When Directory.Packages.props exists, do not specify Version= attributes in individual .csproj files — the central file owns all version pins.

<!-- Directory.Packages.props (at solution root) -->
<Project>
  <PropertyGroup>
    <ManagePackageVersionsCentrally>true</ManagePackageVersionsCentrally>
  </PropertyGroup>

  <ItemGroup>
    <PackageVersion Include="Microsoft.EntityFrameworkCore" Version="8.0.11" />
    <PackageVersion Include="FluentValidation" Version="11.11.0" />
    <PackageVersion Include="xunit" Version="2.9.2" />
    <PackageVersion Include="xunit.runner.visualstudio" Version="2.8.2" />
    <PackageVersion Include="Moq" Version="4.20.72" />
    <PackageVersion Include="FluentAssertions" Version="6.12.1" />
  </ItemGroup>
</Project>

Add new packages with:

# When CPM is active, dotnet add package still updates Directory.Packages.props
dotnet add package NewPackage --version 1.2.3

Directory.Build.props — solution-wide MSBuild properties

<!-- Directory.Build.props (at solution root) — applies to ALL projects -->
<Project>
  <PropertyGroup>
    <Nullable>enable</Nullable>
    <ImplicitUsings>enable</ImplicitUsings>
    <LangVersion>latest</LangVersion>
    <TreatWarningsAsErrors>true</TreatWarningsAsErrors>
    <AnalysisLevel>latest</AnalysisLevel>
    <Authors>Your Org</Authors>
    <Copyright>© 2025 Your Org</Copyright>
  </PropertyGroup>
</Project>

Do not repeat properties already in Directory.Build.props in individual .csproj files — they are inherited automatically.

Multi-targeting

When a library must support multiple runtimes:

<PropertyGroup>
  <TargetFrameworks>net6.0;net8.0</TargetFrameworks>  <!-- semicolon-separated -->
</PropertyGroup>

Use #if NET8_0_OR_GREATER preprocessor symbols to conditionally compile version-specific code.

dotnet format — code formatting

dotnet format respects .editorconfig and Roslyn analyzer rules. Run it after writing code:

# Fix all formatting issues in place
dotnet format

# Only fix whitespace issues (fastest)
dotnet format whitespace

# Only fix style issues (var usage, using directives, etc.)
dotnet format style

# CI gate — fails if any changes would be made
dotnet format --verify-no-changes

Create a .editorconfig at the solution root to enforce consistent style. Minimum recommended settings:

root = true

[*.cs]
indent_style = space
indent_size = 4
end_of_line = lf
charset = utf-8-bom
trim_trailing_whitespace = true
insert_final_newline = true

# Prefer file-scoped namespaces
csharp_style_namespace_declarations = file_scoped:warning

# Prefer var when type is apparent
csharp_style_var_for_built_in_types = false:suggestion
csharp_style_var_when_type_is_apparent = true:suggestion
csharp_style_var_elsewhere = false:suggestion

packages.lock.json — lock file for reproducibility

Enable lock files when reproducible restores are required (CI, Docker images):

<!-- .csproj or Directory.Build.props -->
<PropertyGroup>
  <RestorePackagesWithLockFile>true</RestorePackagesWithLockFile>
</PropertyGroup>

Commit packages.lock.json alongside source. In CI, restore with --locked-mode to fail on any drift:

dotnet restore --locked-mode

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

Angular 18-21 project structure, standalone components vs NgModule, control flow (@if/@for/@switch + *ngIf/*ngFor legacy), decorators, dependency injection (inject() function), lifecycle hooks, pipes, Angular Universal SSR pointer. Use this skill to: - Detect project style (standalone vs NgModule) and apply matching patterns. - Pick correct decorators and DI approach. - Use modern control flow (@if/@for/@switch) in Angular 17+ projects. - Apply `inject()` function over constructor injection where appropriate. - Wire bootstrap correctly (bootstrapApplication for standalone, AppModule for legacy). Do NOT use this skill for: - State management (see angular-state-and-rx). - Routing (see angular-routing). - Forms (see angular-forms). - Testing (see angular-testing).

日本語の概要は準備中です。原文の説明を表示しています。

AratKruglik/claude-sdlc362026年9月21日 更新

Angular forms: Reactive Forms (preferred — typed FormGroup/FormControl since Angular 14, FormBuilder, custom + async validators, FormArray, multi-step) and Template-driven (`[(ngModel)]` + FormsModule). Validation strategies, server error mapping, accessibility. Use this skill to: - Build Reactive Forms with typed FormGroup/FormControl. - Use FormBuilder для concise syntax. - Implement custom synchronous and async validators. - Wire FormArray for dynamic field lists. - Map server errors back to form fields. - Pick Reactive vs Template-driven (prefer Reactive). Do NOT use this skill for: - General conventions (see angular-conventions). - State management beyond forms (see angular-state-and-rx). - Routing (see angular-routing). - Testing forms (see angular-testing).

日本語の概要は準備中です。原文の説明を表示しています。

AratKruglik/claude-sdlc362026年9月21日 更新

Angular Router (built-in `@angular/router`) — route configuration for standalone and NgModule projects, functional guards (Angular 14.1+), lazy loading, route resolvers, typed params via signals/observables, programmatic navigation, route data and meta. Use this skill to: - Configure routes (standalone-style or NgModule-style). - Use functional guards (canActivate as function, preferred over class-based in 17+). - Lazy-load components or feature modules. - Implement auth guards via route meta + functional guards. - Read params/queries via `inject(ActivatedRoute)` + signals or RxJS. Do NOT use this skill for: - General conventions (see angular-conventions). - State management (see angular-state-and-rx). - Forms (see angular-forms). - Testing routes (see angular-testing).

日本語の概要は準備中です。原文の説明を表示しています。

AratKruglik/claude-sdlc362026年9月21日 更新

State management for Angular 18-21: signals (signal/computed/effect), services-as-state, NgRx Store + Effects + Selectors, NgRx Component Store, NgRx Signals (newer signal-based store). RxJS essentials — operators, async pipe, takeUntilDestroyed, signal/observable interop. Use this skill to: - Pick the right state tool (signals / services / NgRx variant / vue-query equivalent). - Use signals correctly (signal/computed/effect — when each). - Build a Pinia-style service-as-state singleton. - Set up NgRx Store + Effects + Selectors. - Use RxJS without leaking subscriptions (async pipe, takeUntilDestroyed, Subject patterns). - Bridge signals ↔ observables via toSignal / toObservable. Do NOT use this skill for: - General Angular conventions (see angular-conventions). - Routing state (see angular-routing). - Form state (see angular-forms). - Testing state (see angular-testing).

日本語の概要は準備中です。原文の説明を表示しています。

AratKruglik/claude-sdlc362026年9月21日 更新

Testing Angular 18-21: TestBed, component harnesses (@angular/cdk/testing), Karma+Jasmine (default historical) vs Jest (jest-preset-angular, modern), Angular Testing Library (RTL-style). HttpClient mocking via HttpTestingController. NgRx Effects testing. Cypress / Playwright e2e. Use this skill to: - Detect runner (Karma+Jasmine vs Jest) and configure correctly. - Write component tests with TestBed. - Use component harnesses for Material / custom UI components. - Mock HttpClient via provideHttpClientTesting + HttpTestingController. - Test signal-based inputs with componentRef.setInput(). - Test NgRx Effects with provideMockActions. Do NOT use this skill for: - General Angular conventions (see angular-conventions). - Routing patterns broadly (see angular-routing — covers testing routes briefly). - Form patterns broadly (see angular-forms).

日本語の概要は準備中です。原文の説明を表示しています。

AratKruglik/claude-sdlc362026年9月21日 更新

Shared conventions for every SDLC development-phase architect agent: hard rules, code quality bar, workflow steps (superpowers invocation, spec reading, codebase exploration, verification), and the report/compact-summary contract. Architects load this skill first, then apply their stack-specific instructions on top.

日本語の概要は準備中です。原文の説明を表示しています。

AratKruglik/claude-sdlc362026年9月21日 更新

AratKruglik のスキルをすべて見る

このスキルの問題を報告する