一键导入
dto-conventions
Canonical DTO naming, structure, and mapping conventions for backend tasks. Load when creating or modifying DTOs.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Canonical DTO naming, structure, and mapping conventions for backend tasks. Load when creating or modifying DTOs.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Structure and rules for .NET projects using Clean Architecture with DDD. Use when the project has complex business domain, multiple use cases, need to test business logic in isolation, or when the system is enterprise, e-commerce, ERP, CRM, or any rich domain. Do not use for simple CRUDs without logic — prefer Vertical Slice in that case. For implementation details, load the required `backend/dotnet/orms/ef-core/*/SKILL.md` leaf skill(s) or your chosen data access skill.
Structure and rules for .NET projects using Hexagonal Architecture (Ports & Adapters). Use when the project has multiple input channels (API, CLI, message queue), need to test the domain in isolation, or when adapters change frequently. Do not use for simple CRUDs without logic — prefer Vertical Slice in that case. For implementation details, load the required `backend/dotnet/orms/ef-core/*/SKILL.md` leaf skill(s) or your chosen data access skill.
Structure and rules for .NET projects using Onion Architecture. Use when the project has a strong domain-centric focus with DDD, aggregate roots, and the Specification pattern. All dependencies point inward toward the domain core. Do not use for simple CRUDs without logic — prefer Vertical Slice in that case. For implementation details, load the required `backend/dotnet/orms/ef-core/*/SKILL.md` leaf skill(s) or your chosen data access skill.
Canonical DbContext setup and registration rules for EF Core. Load when creating or modifying DbContext classes or their DI wiring.
Pure LINQ standards for .NET 10 projects. Covers language operators, query composition, projection patterns, filtering, grouping, and performance best practices over IEnumerable<T> and IQueryable<T>. Load when writing or reviewing LINQ expressions in any layer. DO NOT load expecting EF Core-specific methods (ToListAsync, AsNoTracking, Include, ExecuteUpdateAsync) — those belong to `backend/dotnet/orms/ef-core/query-best-practices/SKILL.md`.
Canonical rules for using AppDbContext DIRECTLY from application code (use cases / handlers) when the project's data-access pattern is Direct DbContext — no repositories, no UnitOfWork. Load when the chosen pattern is Direct DbContext and a use case reads or writes data. This is the counterpart to repository-usage; never load both for the same task.
| name | dto-conventions |
| description | Canonical DTO naming, structure, and mapping conventions for backend tasks. Load when creating or modifying DTOs. |
| requires | ["backend-dotnet-csharp"] |
| produces | ["request-dtos","response-dtos","mapping-conventions"] |
sealed record with explicit propertiesDto suffixrequired for non-nullable DTO properties — use nullable properties only when null is semantically required| Element | Convention | Example |
|---|---|---|
| Request DTO | RequestDto | CreateProductRequestDto |
| Response DTO | ResponseDto | CreateProductResponseDto |
[Entity]MappingExtensions.csTo[DtoName]// ✅ GOOD — explicit properties, no primary constructor
public sealed record CreateProductRequestDto
{
public required string Name { get; init; }
public required string Description { get; init; }
public decimal Price { get; init; }
}
// ❌ BAD — primary constructor
public sealed record CreateProductRequestDto(string Name, string Description, decimal Price);
// ✅ GOOD — explicit properties with required non-nullable members
public sealed record CreateProductResponseDto
{
public Guid Id { get; init; }
public required string Name { get; init; }
public decimal Price { get; init; }
public required string Status { get; init; }
}
public static class ProductMappingExtensions
{
public static CreateProductResponseDto ToCreateProductResponseDto(this Product product)
{
return new CreateProductResponseDto
{
Id = product.Id,
Name = product.Name,
Price = product.Price,
Status = product.Status.ToString()
};
}
}
// ❌ NEVER map HTTP responses from a mapper
public static IActionResult MapToResponse(this Result<Product> result)
{
if (result.HttpStatusCode == HttpStatusCode.NotFound)
return NotFound();
return Ok();
}
// ❌ NEVER create conditional DTO mapping from Result state
public static object ToResponseDto(this Result<Product> result)
{
if (!result.IsSuccess)
return new { error = result.Description };
if (result.Payload is null)
return new { error = "Missing payload" };
return result.Payload.ToProductDto();
}
When a nested type is only used by one DTO, keep it in the same file instead of creating a separate one-off file.
public sealed record CreateProductRequestDto
{
public required string Name { get; init; }
public required string Description { get; init; }
public required BarcodeInfoDto Barcode { get; init; }
public sealed record BarcodeInfoDto
{
public required string Code { get; init; }
public BarcodeType Type { get; init; }
}
}