Dotnet Design Pattern Review
Get a read-only agent review of selected C#/.NET code against Command, Factory, DI, Repository, Provider, and Resource patterns before you merge or refactor.
Overview
dotnet-design-pattern-review is an agent skill most often used in Ship (also Build) that reviews selected C#/.NET code for Command, Factory, DI, Repository, Provider, and Resource patterns and suggests improvements witho
Install
npx skills add https://github.com/github/awesome-copilot --skill dotnet-design-pattern-reviewWhat is this skill?
- Read-only review of ${selection}—no automatic code edits
- Six required patterns: Command, Factory, DI, Repository, Provider, Resource (.resx)
- Command checklist: CommandHandler<TOptions>, ICommandHandler, SetupCommand(IHost), options inheritance
- Architecture pass: Core/Console namespace conventions and project separation
- .NET practices: primary constructors, ArgumentNullException, service lifetimes, async repositories
- 6 required design patterns in the review rubric
- 3 review checklist areas: design patterns, architecture, .NET best practices
Adoption & trust: 10.1k installs on skills.sh; 34.6k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your .NET codebase mixes ad-hoc classes and inconsistent DI, and you need a pattern-aware review before merge without letting the agent rewrite everything blindly.
Who is it for?
Solo builders maintaining multi-project .NET solutions (Core/Console/Service) who already target Command Handler and provider-style abstractions.
Skip if: Greenfield spikes with no C# selection, non-.NET stacks, or when you want the agent to apply refactors automatically instead of review-only output.
When should I use this skill?
Review the C#/.NET code in ${selection} for design pattern implementation and suggest improvements; do not make any changes to the code.
What do I get? / Deliverables
You receive a structured review against the required patterns, architecture conventions, and .NET best practices so you can fix issues manually or in a follow-up refactor pass.
- Written design-pattern and architecture review for the selection
- Suggestions for missing or incorrect pattern usage
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Formal design-pattern review is a ship-phase quality gate, but teams also run it while still in active build on feature branches. Canonical shelf is code review: the skill explicitly reviews without modifying files.
Where it fits
Run on the PR diff selection to verify new ICommandHandler types and SetupCommand registration match team standards.
After adding a database Provider abstraction, review the selection for contract clarity and configuration handling.
Audit ResourceManager and separate LogMessages versus ErrorMessages .resx usage before release.
How it compares
Use for opinionated .NET pattern review instead of generic lint-only or language-agnostic code review skills.
Common Questions / FAQ
Who is dotnet-design-pattern-review for?
Indie and solo developers on C#/.NET who want a senior-style design-pattern audit on a specific selection before shipping or refactoring.
When should I use dotnet-design-pattern-review?
During Ship review on a PR, during Build backend work after adding handlers or repositories, or when validating that new Console commands follow CommandHandler and SetupCommand conventions.
Is dotnet-design-pattern-review safe to install?
It is instruction-only and does not change code by design; still review the Security Audits panel on this Prism page before adding any awesome-copilot skill to your agent.
SKILL.md
READMESKILL.md - Dotnet Design Pattern Review
# .NET/C# Design Pattern Review Review the C#/.NET code in ${selection} for design pattern implementation and suggest improvements for the solution/project. Do not make any changes to the code, just provide a review. ## Required Design Patterns - **Command Pattern**: Generic base classes (`CommandHandler<TOptions>`), `ICommandHandler<TOptions>` interface, `CommandHandlerOptions` inheritance, static `SetupCommand(IHost host)` methods - **Factory Pattern**: Complex object creation service provider integration - **Dependency Injection**: Primary constructor syntax, `ArgumentNullException` null checks, interface abstractions, proper service lifetimes - **Repository Pattern**: Async data access interfaces provider abstractions for connections - **Provider Pattern**: External service abstractions (database, AI), clear contracts, configuration handling - **Resource Pattern**: ResourceManager for localized messages, separate .resx files (LogMessages, ErrorMessages) ## Review Checklist - **Design Patterns**: Identify patterns used. Are Command Handler, Factory, Provider, and Repository patterns correctly implemented? Missing beneficial patterns? - **Architecture**: Follow namespace conventions (`{Core|Console|App|Service}.{Feature}`)? Proper separation between Core/Console projects? Modular and readable? - **.NET Best Practices**: Primary constructors, async/await with Task returns, ResourceManager usage, structured logging, strongly-typed configuration? - **GoF Patterns**: Command, Factory, Template Method, Strategy patterns correctly implemented? - **SOLID Principles**: Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, Dependency Inversion violations? - **Performance**: Proper async/await, resource disposal, ConfigureAwait(false), parallel processing opportunities? - **Maintainability**: Clear separation of concerns, consistent error handling, proper configuration usage? - **Testability**: Dependencies abstracted via interfaces, mockable components, async testability, AAA pattern compatibility? - **Security**: Input validation, secure credential handling, parameterized queries, safe exception handling? - **Documentation**: XML docs for public APIs, parameter/return descriptions, resource file organization? - **Code Clarity**: Meaningful names reflecting domain concepts, clear intent through patterns, self-explanatory structure? - **Clean Code**: Consistent style, appropriate method/class size, minimal complexity, eliminated duplication? ## Improvement Focus Areas - **Command Handlers**: Validation in base class, consistent error handling, proper resource management - **Factories**: Dependency configuration, service provider integration, disposal patterns - **Providers**: Connection management, async patterns, exception handling and logging - **Configuration**: Data annotations, validation attributes, secure sensitive value handling - **AI/ML Integration**: Semantic Kernel patterns, structured output handling, model configuration Provide specific, actionable recommendations for improvements aligned with the project's architecture and .NET best practices.