К основному содержанию
скилл CX Codex

project-structure · codewithmukesh — скилл для Claude Code: структура .NET-решения

Скилл задаёт агенту правила раскладки .NET-решения: центральные версии пакетов, общие свойства сборки, формат .slnx и именование проектов.

Установить в Claude Code · Через Skills CLI (Vercel) Все способы и платформы ↓
npx skills add codewithmukesh/dotnet-claude-kit --skill project-structure -a claude-code
Открыть на GitHub

Что делает project-structure

Скилл описывает, как устроено .NET-решение: где лежат исходники и тесты, как называются проекты и пространства имён, какие файлы отвечают за сборку. Агент читает эти правила и раскладывает новый код по ним, а не по своему вкусу.

Внутри — четыре принципа и примеры файлов. Directory.Packages.props держит версии NuGet в одном месте, поэтому в отдельных .csproj атрибут Version не пишется. Directory.Build.props хранит общие свойства вроде целевой платформы, Nullable и ImplicitUsings. Решение собирается в формате .slnx, исходники идут в src/, тесты в tests/.

Есть таблица именования (решение, проект, пространство имён, папка фичи) и разбор антипаттернов: разбросанные версии пакетов, дублирование свойств сборки, тестовые проекты внутри src/. Версии пакетов в примерах помечены как иллюстративные — автор советует уточнять актуальные через dotnet add package без флага --version. Скилл подключается к Claude, Codex, Cursor, GitHub Copilot, Gemini CLI и OpenCode, так что структура остаётся одинаковой в какой бы редактор вы ни переключились.

Какие задачи решает

  • разложить новый .NET-проект по папкам src и tests
  • свести версии NuGet-пакетов в один файл вместо десятка .csproj
  • вынести общие свойства сборки в Directory.Build.props
  • перевести решение со старого .sln на .slnx
  • выбрать имена для проектов, пространств имён и папок фич

Примеры запросов агенту

  • Создай новый .NET-проект по структуре из скилла project-structure
  • Перенеси версии пакетов в Directory.Packages.props
  • Проверь раскладку решения: тесты должны лежать в tests/, а не в src/

Как установить project-structure

1Через Skills CLI (Vercel)

npx skills add codewithmukesh/dotnet-claude-kit --skill project-structure -a claude-code

2Вручную: положить файлы

~/.claude/skills/project-structure/SKILL.md

Папка скилла целиком; для одного проекта — .claude/skills/project-structure/

По шагам, с командами для каждой платформы: Как установить скилл в Claude Code: пять способов

Из того же набора46

configuration Настраивает конфигурацию .NET 10 через типизированные options, проверку и разделение секретов. Пригодится при работе с appsettings и переменными окружения. CX Codex +1 2 800установок scalar Скилл подсказывает агенту, как подключить Scalar вместо Swagger UI в приложении на .NET 10 и настроить темы, авторизацию и несколько документов. CX Codex +1 2 800установок opentelemetry Скилл настраивает трассировку, метрики и логи OpenTelemetry в .NET 10 через единый вызов с OTLP-экспортом. CX Codex +1 2 800установок messaging Скилл для .NET-проектов: подсказывает, как настроить Wolverine или MassTransit, outbox, саги и брокеры RabbitMQ и Azure Service Bus. CX Codex +1 2 800установок httpclient-factory Скилл обучает ассистента конфигурировать IHttpClientFactory и типовые HTTP-клиенты для .NET 10. Помогает настроить политики устойчивости и избежать исчерпания сокетов. CX Codex +1 2 800установок de-sloppify Наводит порядок в .NET-коде по семи шагам: от форматирования до передачи CancellationToken. Нужен перед релизом, после крупных изменений или обновления зависимостей. CX Codex +1 2 800установок logging Скилл про наблюдаемость в .NET 10: разводит liveness и readiness, прокидывает correlation ID и задаёт уровни логов. CX Codex +1 2 800установок ci-cd Скилл помогает создавать YAML-пайплайны для проектов на .NET. Пригодится для быстрой настройки GitHub Actions и Azure DevOps с этапами сборки, тестов и публикации. CX Codex +1 2 800установок

Другие версии project-structure

Похожие

dotnet-project-structure Aaronontheweb Скилл подсказывает агенту, как разложить .NET-решение: .slnx, Directory.Build.props, центральные версии пакетов и SourceLink. CX Codex +1 658установок convert-to-cpm dotnet Переводит .NET-проекты и решения на NuGet Central Package Management через Directory.Packages.props. Нужен при рассинхронизации версий пакетов между проектами. CX Codex +1 3 400установок extension-points dotnet Скилл разбирает, откуда MSBuild берёт хуки и импорты: CustomBefore/CustomAfter, wildcard-каталоги, авто-импорты NuGet. Пригодится, когда ассеты пропали или подменились. CX Codex +1 3 000установок api-design Aaronontheweb Скилл для проектирования публичных API по принципу «только расширять»: помогает не ломать совместимость при выпуске новых версий. CX Codex +1 660установок python-project-structure Seth Hobson Скилл помогает разложить Python-проект по модулям, определить публичные API и выбрать структуру каталогов. Подойдёт для нового проекта и реорганизации существующего кода. CX Codex 14 768установок nuget-manager официальный github Управляет NuGet-пакетами в .NET-проектах через dotnet CLI. Нужен при добавлении, удалении и обновлении зависимостей. 14 360установок

Рядом в теме «Бэкенд и API»

Всё по теме «Бэкенд и API» →

Вопросы о project-structure

Как установить project-structure в Claude?

Выполните npx skills add codewithmukesh/dotnet-claude-kit --skill project-structure -a claude-code. Скилл появится в ~/.claude/skills/project-structure/SKILL.md.

Что делает скилл project-structure?

Описывает конвенции .NET-решения: формат .slnx, центральное управление версиями пакетов, общие свойства сборки, global usings и правила именования. Агент применяет их, когда вы заводите решение или добавляете проект.

Нужен ли .NET 10 для этого скилла?

В примерах Directory.Build.props указаны net10.0 и LangVersion 14, а в global.json — SDK 10.0.100. Это значения из примеров, а не жёсткое требование: подставьте свою целевую платформу.

Исходный текст

SKILL.md · MIT
---
name: project-structure
description: >
  .NET solution and project structure conventions. Covers .slnx format,
  Directory.Build.props, Directory.Packages.props for central package management,
  global usings, and naming conventions.
  Load this skill when setting up a new solution, adding projects, configuring
  build properties, or when the user mentions "solution structure", ".slnx",
  "Directory.Build.props", "central package management", "Directory.Packages.props",
  "global usings", ".editorconfig", "project layout", or "naming conventions".
---

# Project Structure

## Core Principles

1. **Central package management** — Use `Directory.Packages.props` to manage NuGet package versions in one place. No version numbers in individual `.csproj` files.
2. **Shared build properties** — Use `Directory.Build.props` for common settings (target framework, nullable, implicit usings). Don't repeat in every project.
3. **.slnx for solutions** — The new XML-based solution format is cleaner and more merge-friendly than the legacy `.sln` format.
4. **src/tests separation** — Source projects in `src/`, test projects in `tests/`. Clear boundary.

## Patterns

### Solution Layout

```
MyApp/
├── MyApp.slnx                       # Solution file
├── Directory.Build.props             # Shared MSBuild properties
├── Directory.Packages.props          # Central package management
├── .editorconfig                     # Code style rules
├── .gitignore
├── global.json                       # SDK version pinning
├── src/
│   ├── MyApp.Api/                    # Web API (entry point)
│   │   ├── MyApp.Api.csproj
│   │   ├── Program.cs
│   │   └── Features/
│   ├── MyApp.Domain/                 # Domain entities, value objects (optional)
│   │   └── MyApp.Domain.csproj
│   └── MyApp.Infrastructure/         # EF Core, external services (optional)
│       └── MyApp.Infrastructure.csproj
└── tests/
    └── MyApp.Api.Tests/
        └── MyApp.Api.Tests.csproj
```

### Directory.Build.props

```xml
<Project>
  <PropertyGroup>
    <TargetFramework>net10.0</TargetFramework>
    <LangVersion>14</LangVersion>
    <Nullable>enable</Nullable>
    <ImplicitUsings>enable</ImplicitUsings>
    <TreatWarningsAsErrors>true</TreatWarningsAsErrors>
    <EnforceCodeStyleInBuild>true</EnforceCodeStyleInBuild>
  </PropertyGroup>
</Project>
```

### Directory.Packages.props (Central Package Management)

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

  <ItemGroup>
    <!-- Versions below are illustrative — resolve the current stable versions
         with `dotnet add package <name>` (no --version flag); see the packages rule -->
    <!-- ASP.NET Core -->
    <PackageVersion Include="Mediator.Abstractions" Version="3.0.0" />
    <PackageVersion Include="Mediator.SourceGenerator" Version="3.0.0" />
    <PackageVersion Include="FluentValidation.DependencyInjectionExtensions" Version="12.0.0" />

    <!-- Data -->
    <PackageVersion Include="Microsoft.EntityFrameworkCore" Version="10.0.10" />
    <PackageVersion Include="Npgsql.EntityFrameworkCore.PostgreSQL" Version="10.0.10" />

    <!-- Observability -->
    <PackageVersion Include="Serilog.AspNetCore" Version="10.0.0" />
    <PackageVersion Include="OpenTelemetry.Extensions.Hosting" Version="1.17.0" />

    <!-- Testing -->
    <PackageVersion Include="xunit.v3" Version="3.2.2" />
    <PackageVersion Include="Microsoft.AspNetCore.Mvc.Testing" Version="10.0.10" />
    <PackageVersion Include="Testcontainers.PostgreSql" Version="4.13.0" />
  </ItemGroup>
</Project>
```

### Project File (.csproj) with Central Package Management

```xml
<Project Sdk="Microsoft.NET.Sdk.Web">
  <!-- No TargetFramework here — inherited from Directory.Build.props -->

  <ItemGroup>
    <!-- No Version attribute — managed centrally -->
    <PackageReference Include="Mediator.Abstractions" />
    <PackageReference Include="Mediator.SourceGenerator" />
    <PackageReference Include="FluentValidation.DependencyInjectionExtensions" />
    <PackageReference Include="Microsoft.EntityFrameworkCore" />
    <PackageReference Include="Npgsql.EntityFrameworkCore.PostgreSQL" />
    <PackageReference Include="Serilog.AspNetCore" />
  </ItemGroup>

  <ItemGroup>
    <ProjectReference Include="..\MyApp.Domain\MyApp.Domain.csproj" />
    <ProjectReference Include="..\MyApp.Infrastructure\MyApp.Infrastructure.csproj" />
  </ItemGroup>
</Project>
```

### global.json (SDK Pinning)

```json
{
  "sdk": {
    "version": "10.0.100",
    "rollForward": "latestFeature"
  }
}
```

### .slnx Solution Format

```xml
<Solution>
  <Folder Name="/src/">
    <Project Path="src/MyApp.Api/MyApp.Api.csproj" />
    <Project Path="src/MyApp.Domain/MyApp.Domain.csproj" />
    <Project Path="src/MyApp.Infrastructure/MyApp.Infrastructure.csproj" />
  </Folder>
  <Folder Name="/tests/">
    <Project Path="tests/MyApp.Api.Tests/MyApp.Api.Tests.csproj" />
  </Folder>
</Solution>
```

### Naming Conventions

| Element | Convention | Example |
|---------|-----------|---------|
| Solution | `CompanyName.AppName` or `AppName` | `MyApp.slnx` |
| Project | `AppName.Layer` | `MyApp.Api`, `MyApp.Domain` |
| Namespace | Matches folder path | `MyApp.Api.Features.Orders` |
| Feature folder | PascalCase, plural | `Features/Orders/` |
| Test project | `ProjectName.Tests` | `MyApp.Api.Tests` |

## Anti-patterns

### Don't Scatter Package Versions

```xml
<!-- BAD — version in every .csproj, version drift -->
<PackageReference Include="Mediator.Abstractions" Version="2.0.0" />  <!-- in Project A -->
<PackageReference Include="Mediator.Abstractions" Version="3.0.0" />  <!-- in Project B -->

<!-- GOOD — central management, one version -->
<!-- Directory.Packages.props: <PackageVersion Include="Mediator.Abstractions" Version="3.0.0" /> -->
<!-- .csproj: <PackageReference Include="Mediator.Abstractions" /> -->
```

### Don't Repeat Build Properties

```xml
<!-- BAD — same properties in every .csproj -->
<PropertyGroup>
  <TargetFramework>net10.0</TargetFramework>
  <Nullable>enable</Nullable>
  <ImplicitUsings>enable</ImplicitUsings>
</PropertyGroup>

<!-- GOOD — once in Directory.Build.props, inherited everywhere -->
```

### Don't Mix Source and Test Projects

```
# BAD — tests mixed with source
src/
  MyApp.Api/
  MyApp.Api.Tests/    # test project in src/

# GOOD — clear separation
src/
  MyApp.Api/
tests/
  MyApp.Api.Tests/
```

## Decision Guide

| Scenario | Recommendation |
|----------|---------------|
| New solution | `.slnx` format |
| Package version management | `Directory.Packages.props` (central) |
| Shared build settings | `Directory.Build.props` |
| SDK version pinning | `global.json` |
| Common using directives | Global usings in `Directory.Build.props` |
| Small API (1-2 devs) | Single project (`MyApp.Api`) |
| Medium API (3-5 devs) | 2-3 projects (`Api`, `Domain`, `Infrastructure`) |
| Large / modular app | Module-per-project with shared `Contracts` |

© codewithmukesh · MIT · codewithmukesh/dotnet-claude-kit

Смотрите также

Спонсоры проекта

Компании, которые помогают держать аналитику открытой