controllers

Enforce a unified ASP.NET Core controller standard for API contracts, routes, DTOs, and OpenAPI.

Updated Apr 9, 2026
One-click install
npx skills add https://github.com/SergeuMatyasov/dotnet-shared-skills --skill controllers-sergeumatyasov
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: controllers
Source: https://github.com/SergeuMatyasov/dotnet-shared-skills/tree/main/controllers
Command: npx skills add https://github.com/SergeuMatyasov/dotnet-shared-skills --skill controllers-sergeumatyasov

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Establishes a single, enforceable contract for ASP.NET Core controllers covering API surface, routes, DTOs, HTTP status codes, validation, OpenAPI, and CancellationToken usage to improve consistency and reviewability.

Core Features & Use Cases

  • Standardizes controller structure to keep presentation thin and free of business logic.
  • Enforces consistent DTO naming, mapping, OpenAPI documentation, and route conventions.
  • Guides testing, PR reviews, and API versioning to ensure stable, predictable endpoints.

Quick Start

Применяйте этот скилл для стандартизации нового или существующего контроллера ASP.NET Core в рамках вашего проекта.

Frequently Asked Questions about controllers

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I standardize ASP.NET Core controller routes and DTOs across a project?

To standardize ASP.NET Core controllers, enforce explicit frontmatter metadata, per-action DTO mapping to commands and queries, typed response contracts, and consistent camelCase JSON routes to ensure predictable API surfaces.

What is the best way to document HTTP status codes and OpenAPI for ASP.NET Core controllers?

The best way to document HTTP status codes and OpenAPI is to enforce ProducesResponseType attributes on all endpoints, ensuring seamless OpenAPI documentation and explicitly typed response contracts for every controller action.

How do I enforce CancellationToken usage in ASP.NET Core API controllers?

Enforce CancellationToken usage by including it as a parameter in controller actions and passing it through per-action DTO mapping to commands and queries, ensuring predictable API surfaces and testable cancellation behavior.

Can I use this controller standard for refactoring existing ASP.NET Core APIs?

Yes, you can apply this standard to refactoring existing ASP.NET Core controllers to enforce a consistent API contract, thin presentation layers free of business logic, and seamless OpenAPI documentation across projects.

Why should I keep business logic out of ASP.NET Core controllers?

Keeping business logic out of ASP.NET Core controllers standardizes the structure to keep presentation thin, improves testability, and ensures per-action DTO mapping handles commands and queries predictably across the API surface.