Agent skill

Clean Architecture Dotnet

by SebastienDegodez in SebastienDegodez/copilot-instructions

A skill your agent uses when domain logic leaks into API/Infrastructure, project references violate layer boundaries, or you need to decide between CQS (always), CQRS bus (complex domains), and DDD…

Apache-2.0Auto-check passedDevelopment

Install Clean Architecture Dotnet

skills CLI
$ npx skills add SebastienDegodez/copilot-instructions --skill clean-architecture-dotnet -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install SebastienDegodez/copilot-instructions clean-architecture-dotnet --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/SebastienDegodez/copilot-instructions.git skills-src && mkdir -p .claude/skills && cp -r skills-src/plugins/csharp-clean-architecture-development/skills/clean-architecture-dotnet .claude/skills/clean-architecture-dotnet && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
clean-architecture-dotnet
GitHub stars
198
Token cost
~5.1k tokens
SKILL.md length
1,651 words
Files
32 (incl. scripts, references)
Skills in repo
19
Repo updated
First seen
Licence
Apache-2.0

At a glance

A skill your agent uses when domain logic leaks into API/Infrastructure, project references violate layer boundaries, or you need to decide between CQS (always), CQRS bus (complex domains), and DDD…

  • Domain logic leaks into API/Infrastructure
  • SKILL.md covers Overview, When to Use, CQS vs CQRS vs DDD —… and DDD vs POCO — Quick Decision, plus 11 more sections
  • Runs C#, PowerShell and Shell scripts from its folder
  • Project references violate layer boundaries

What it does

Clean Architecture Dotnet is an agent skill from SebastienDegodez/copilot-instructions. Use when domain logic leaks into API/Infrastructure, project references violate layer boundaries, or you need to decide between CQS (always), CQRS bus (complex domains), and DDD patterns (invariants and events).

Its SKILL.md is about 5.1k tokens, which your agent loads only when the skill is triggered. The skill folder holds 37 other files, including scripts and reference files (for example `references/architecture-layers.md`, `references/convention-based-di.md` and `references/cqrs-patterns.md`).

It sits in Development, covering Design patterns, Domain-driven design and Event-driven systems. It works with .NET. The repository describes itself as: A comprehensive codebase of best practices, coding rules, and workflow automation for AI-assisted development with GitHub Copilot. Includes DDD, Clean Architecture, testing… The licence is Apache-2.0.

When your agent uses it

  • Domain logic leaks into API/Infrastructure
  • Project references violate layer boundaries
  • You need to decide between CQS (always)
  • CQRS bus (complex domains)

Example prompts

  • “/clean-architecture-dotnet”

Requirements

  • A Bash shell
  • PowerShell

What it can do on your machine

Read from SKILL.md and the folder at commit 0f0dccf. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Ships 2 files in scripts/ (C#, PowerShell and Shell, from the files we listed), which the agent can run.

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Clean Architecture Dotnet loads about 5.1k tokens when it runs, and up to ~22k if it reads all its reference files. Until then it costs about 59 tokens; SKILL.md has 1,651 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~59
When it runs · the whole SKILL.md, loaded when a task matches
~5.1k
With references · SKILL.md plus every file in references/, read only if the agent opens them
~22k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); the scripts in this folder are not scanned.

SKILL.md

The full file from SebastienDegodez/copilot-instructions at commit 0f0dccf, republished under its Apache-2.0 licence (© SebastienDegodez). 1,651 words, ~5,134 tokens.

Download SKILL.mdSave it as .claude/skills/clean-architecture-dotnet/SKILL.md (or your agent's skills folder). This skill also uses 31 other files; get the full folder from GitHub.
name
clean-architecture-dotnet
description
Use when domain logic leaks into API/Infrastructure, project references violate layer boundaries, or you need to decide between CQS (always), CQRS bus (complex domains), and DDD patterns (invariants and events).

Clean Architecture in .NET

Overview

Clean Architecture organizes code into independent layers (Domain → Application → Infrastructure → API).

The Iron Law: Violating layer boundaries is a failure. If API references Application or Domain references Infrastructure, delete the change and start over.

Concrete violations that break the Iron Law:

  • using MyApp.Infrastructure; in a Domain class — Infrastructure must never flow inward.
  • using MyApp.Application; in an API endpoint file — API must only interact via ICommandBus / IQueryBus or an injected use case interface.
  • new AppDbContext() inside a Controller — bypasses both Infrastructure and Application layers.
  • HttpClient injected directly into a Domain or Application class — HTTP belongs in Infrastructure behind an interface.

Fix: move the dependency to the correct outer layer and expose it through an interface pointing inward.

When to Use

  • Business logic is leaking into Controllers or Repositories
  • Circular dependencies occur between projects
  • Need to isolate core business rules from external frameworks (EF Core, APIs)
  • Autonomy is required: sealed Domain objects, strongly-typed IDs

When NOT to add CQRS or DDD:

  • The feature is pure CRUD with no business rules, no invariants, and no domain events → use a CQS Application service (see Pattern A below)
  • A query only reads data with no domain logic → inject the repository or a read service directly in the Application handler; no IQueryBus required
  • You have fewer than 3 use cases with no cross-cutting concerns (logging pipeline, validation pipeline) → a CQRS bus adds ceremony without value

CQS vs CQRS vs DDD — Complexity Threshold

These three patterns are independent tools. Choose based on what the codebase actually needs.

PatternRuleAdd it when…Skip it when…
CQS (always)Every handler/method is either a command (void) or a query (returns value) — never bothAlways — zero exceptionsNever skip
CQRS + Bus (optional)Separate ICommandBus / IQueryBus routing commands and queries through a pipelineCross-cutting concerns (validation, logging pipelines), large teams writing many use cases, read/write model asymmetrySimple CRUD; < 3 use cases; no cross-cutting pipeline needed
DDD (optional)Aggregates, factory methods, value objects, domain eventsDomain has invariants (rules that must be enforced on every state change), state machines, rich business logicEntities are pure data (no if/throw to protect state); CRUD-only feature

Quick rule of thumb:

"Does this feature have a business rule that could be violated?"
— No → CQS Application Service (Pattern A).
— Yes → Domain Aggregate + CQS or CQRS depending on scale (Pattern B).

DDD vs POCO — Quick Decision

UseWhen
sealed class Foo : AggregateRoot + factory methodThe object has domain invariants, raises events, or owns child entities
Plain sealed record Foo(...) (POCO)Pure data carrier, no invariants, used only inside Application or API (DTOs, ViewModels)
sealed class Bar : ValueObjectImmutable, identity-by-value, represents a domain concept (e.g., PolicyNumber, Horsepower)

Rule of thumb: if you're tempted to add an if or throw to protect the object's state — it's a Domain object (aggregate or value object), not a POCO.

Aggregate vs POCO test: write the business method first. If you never need if (condition) throw new DomainException(...) to protect state, the object has no invariants — make it a plain sealed record, not an AggregateRoot. DDD complexity is the cure for invariants, not for data.

Implementation Flow

dot
digraph clean_arch {
    "Domain has invariants?" [shape=diamond];
    "Pattern A: CQS App Service" [shape=box];
    "Pattern B: DDD + CQRS?" [shape=diamond];
    "Define Aggregate in Domain" [shape=box];
    "Create Handler in Application" [shape=box];
    "Add CQRS Bus? (optional)" [shape=diamond];
    "Route via ICommandBus/IQueryBus" [shape=box];
    "Inject handler directly" [shape=box];
    "Expose in API" [shape=box];

    "Domain has invariants?" -> "Pattern A: CQS App Service" [label="No (CRUD)"];
    "Domain has invariants?" -> "Pattern B: DDD + CQRS?" [label="Yes"];
    "Pattern A: CQS App Service" -> "Expose in API";
    "Pattern B: DDD + CQRS?" -> "Define Aggregate in Domain";
    "Define Aggregate in Domain" -> "Create Handler in Application";
    "Create Handler in Application" -> "Add CQRS Bus? (optional)";
    "Add CQRS Bus? (optional)" -> "Route via ICommandBus/IQueryBus" [label="Yes (cross-cutting)"];
    "Add CQRS Bus? (optional)" -> "Inject handler directly" [label="No"];
    "Route via ICommandBus/IQueryBus" -> "Expose in API";
    "Inject handler directly" -> "Expose in API";
}

Core Patterns

Pattern A: CQS Application Use Case (Simple / CRUD)

Use when the feature has no business invariants. Layer boundaries are maintained — no CQRS bus needed.

CQS rule: each method is either a command (void / Task) or a query (returns a value) — never both.

Naming: call it *UseCase, not *Service. "Service" implies stateful or cross-cutting infrastructure; a use case class orchestrates one bounded interaction.

csharp
// Application/Contacts/ContactUseCase.cs — plain use case, no bus
public sealed class ContactUseCase
{
    private readonly IContactRepository _repository; // interface defined in Application (see Interface Placement)

    public ContactUseCase(IContactRepository repository)
    {
        _repository = repository;
    }

    // Command — void (CQS)
    public async Task CreateAsync(Guid id, string name, CancellationToken ct)
    {
        await _repository.AddAsync(new Contact(new ContactId(id), name), ct);
    }

    // Query — maps domain object to ViewModel in the use case (Option 1)
    public async Task<ContactViewModel?> GetByIdAsync(Guid id, CancellationToken ct)
    {
        var contact = await _repository.FindAsync(new ContactId(id), ct);
        return contact is null ? null : new ContactViewModel(contact.Id.Value, contact.Name);
    }
}

// API/ContactsEndpoints.cs — inject the use case directly (no bus)
app.MapPost("/contacts", async (CreateContactRequest req, ContactUseCase uc) =>
{
    var id = Guid.NewGuid();
    await uc.CreateAsync(id, req.Name, default);
    return Results.Created($"/contacts/{id}", null);
});

app.MapGet("/contacts/{id:guid}", async (Guid id, ContactUseCase uc) =>
    await uc.GetByIdAsync(id, default) is { } vm ? Results.Ok(vm) : Results.NotFound());

Option 2 — read-optimized query: for read-heavy paths, skip the domain object entirely. Define a dedicated read interface in Application; Infrastructure implements it directly (e.g., a raw SQL/EF projection).

csharp
// Application/Contacts/IContactReadService.cs — interface in Application, no domain object involved
public interface IContactReadService
{
    Task<ContactViewModel?> GetByIdAsync(ContactId id, CancellationToken ct = default);
}

// Infrastructure/Contacts/ContactReadService.cs — implementation maps directly from DB row to ViewModel
public sealed class ContactReadService : IContactReadService
{
    private readonly AppDbContext _db;

    public ContactReadService(AppDbContext db)
    {
        _db = db;
    }

    public async Task<ContactViewModel?> GetByIdAsync(ContactId id, CancellationToken ct)
    {
        return await _db.Contacts
            .Where(c => c.Id == id.Value)
            .Select(c => new ContactViewModel(c.Id, c.Name))
            .FirstOrDefaultAsync(ct);
    }
}

Rule of thumb: IContactRepository (write path) returns domain objects. IContactReadService (read path) returns ViewModels. Both interfaces live in Application; implementations live in Infrastructure.

Pattern B: CQRS + DDD (Complex Domains)

Use when the domain has invariants, state transitions, or events. CQRS bus is optional even here — add it when you need a cross-cutting pipeline.

Add ICommandBus / IQueryBus only when ALL of the following are true:

  1. You need a cross-cutting pipeline for ALL commands/queries (e.g., logging every command, input validation via pipeline behaviours, performance metrics).
  2. You have multiple use cases (>3) that all benefit from this pipeline — the overhead is justified by scale.
  3. Your read and write models are structurally different (CQRS read-model separation), or your team is large enough that different people own the command and query paths.

If only one condition is true, use a decorator or middleware instead — don't build a bus for a single use case.

CQS rule for commands: a command must be void — it does not return a value. The caller is responsible for generating the ID and including it in the command.

csharp
// Application/Features/Orders/PlaceOrderCommand.cs — ID is part of the command
public sealed record PlaceOrderCommand(OrderId OrderId, string CustomerName);

// Application/Features/Orders/PlaceOrderCommandHandler.cs
public sealed class PlaceOrderCommandHandler : ICommandHandler<PlaceOrderCommand>
{
    private readonly IOrderRepository _repository; // IOrderRepository defined in Domain (write path) — see Interface Placement
    
    public async Task HandleAsync(PlaceOrderCommand cmd, CancellationToken ct)
    {
        var order = Order.Create(cmd.OrderId, cmd.CustomerName);
        await _repository.AddAsync(order, ct);
    }
}

// API/OrdersEndpoints.cs — caller generates the ID, sends it via ICommandBus (optional)
app.MapPost("/orders", async (PlaceOrderCommand cmd, ICommandBus bus) =>
{
    await bus.PublishAsync(cmd);
    return Results.Created($"/orders/{cmd.OrderId}");
});

// Queries follow the same rule — inject IQueryBus if using CQRS bus
app.MapGet("/orders/{id}", async (Guid id, IQueryBus bus)
    => Results.Ok(await bus.SendAsync<GetOrderQuery, OrderViewModel>(new GetOrderQuery(new OrderId(id)))));

// Both buses resolve via Infrastructure DI. API never references Application assembly.

Layer Responsibilities

LayerPurposeAllowed Dependencies
SharedKernel (multi-context only)Generic interfaces + base classes only — zero domain logicNone
DomainPure business logic, aggregatesSharedKernel (optional)
ApplicationUse cases, Handler orchestrationDomain, SharedKernel (optional)
InfrastructureDatabase, DI registration, CQRS BusApplication, Domain
APIEndpoints, JSON mappingInfrastructure (Transitive: Application, Domain)

Shared Kernel (Multi-Context Solutions)

Use a SharedKernel project when two or more Bounded Contexts need to share handler interfaces or base classes. It must contain zero domain logic.

SharedKernel/
├── Abstractions/
│   ├── ICommandHandler.cs   ← generic interface only
│   ├── IQueryHandler.cs
│   ├── ValueObject.cs       ← base class, no business logic
│   └── AggregateRoot.cs     ← base class, exposes DomainEvents collection
└── Events/
    └── DomainEvent.cs       ← abstract base for all domain events

Dependency rule for SharedKernel: it depends on nothing. Domain and Application reference it, not the other way around.

csharp
// SharedKernel/Abstractions/ICommandHandler.cs — commands are void (CQS)
public interface ICommandHandler<in TCommand>
{
    Task HandleAsync(TCommand command, CancellationToken ct = default);
}

// SharedKernel/Abstractions/IQueryHandler.cs — queries return a result
public interface IQueryHandler<in TQuery, TResult>
{
    Task<TResult> HandleAsync(TQuery query, CancellationToken ct = default);
}

// Each context's Application layer implements it:
// Orders.Application/Features/PlaceOrder/PlaceOrderCommandHandler.cs
using SharedKernel.Abstractions;
public sealed class PlaceOrderCommandHandler
    : ICommandHandler<PlaceOrderCommand> { }

What NEVER goes in SharedKernel: concrete value objects like Money, Address (each context defines its own); aggregate logic; context-specific event types.

Domain Events

Rule: Domain events are declared in the Domain layer and dispatched in the Application layer (from the handler, after the aggregate operation succeeds).

csharp
// Domain/Orders/Events/OrderPlacedEvent.cs — sealed, in Domain
public sealed class OrderPlacedEvent : DomainEvent  // DomainEvent base from SharedKernel (or Domain if single-context)
{
    public OrderId OrderId { get; }

    public OrderPlacedEvent(OrderId orderId)
    {
        OrderId = orderId;
    }
}

// Domain/Orders/Order.cs — aggregate raises the event
public sealed class Order : AggregateRoot
{
    public OrderId Id { get; }
    public CustomerId CustomerId { get; }

    // Private constructor — only the factory method can create an instance
    private Order(OrderId id, CustomerId customerId)
    {
        Id = id;
        CustomerId = customerId;
    }

    public static Order Create(OrderId id, CustomerId customerId)
    {
        var order = new Order(id, customerId);
        order.AddDomainEvent(new OrderPlacedEvent(id)); // ← raised in Domain
        return order;
    }
}

// Application/Features/PlaceOrder/PlaceOrderCommandHandler.cs — handler dispatches
public sealed class PlaceOrderCommandHandler : ICommandHandler<PlaceOrderCommand>
{
    private readonly IOrderRepository _repository;
    private readonly IDomainEventDispatcher _dispatcher; // interface in Application/Domain

    public async Task HandleAsync(PlaceOrderCommand cmd, CancellationToken ct)
    {
        var order = Order.Create(cmd.OrderId, cmd.CustomerId); // ← ID comes from the command
        await _repository.AddAsync(order, ct);
        await _dispatcher.DispatchAsync(order.DomainEvents, ct); // ← dispatched in Application
    }
}

Anti-pattern: Never dispatch events from inside a Domain aggregate method — Domain has no dependency on dispatch infrastructure.

The Dependency Chain (Transitive Access)

The architecture follows a strict outward-in dependency flow: API → Infrastructure → Application → Domain

  • API has access to everything below it (Infrastructure, Application, Domain).
  • Infrastructure has access to Application and Domain.
  • Application has access to Domain.
  • Domain remains pure with zero project dependencies.

CRITICAL: Just because a layer can see another via transitive reference doesn't mean it should use its concrete types.

  • API should only use Interfaces from Application/Domain.
  • Always follow the Iron Law and Red Flags below.
Show full SKILL.md (621 more words)Show less

Interface Placement — Repository, Authorization, and Authentication

See Interface Placement for full decision tables and examples.

ContractDefine inKey question
Write repo for a Domain aggregateDomainDoes it persist an aggregate?
Write repo for CRUD entity / read serviceApplicationNo aggregate — Application owns the contract
ICurrentUser / IUserContextApplicationUse cases need the caller's identity
Authentication (token/role gate)InfrastructureTechnical filter, no business logic

Authorization quick rule: read access gate → Application use case policy. Mutation invariant → Domain aggregate method. Token/role → Infrastructure middleware.

Rationalization Table

ExcuseReality
"Injecting ICommandHandler<,> directly is simpler"If you're using a CQRS bus, always route through ICommandBus / IQueryBus — consistent indirection, easier to intercept. But if you're not using a bus at all (Pattern A), injecting the Application service directly is correct.
"It's just one small service"Small leaks become circular dependency nightmares.
"Referencing Application in API is faster"It bypasses the Bus/Handler pattern and couples contract to implementation.
"Domain needs this NuGet package"If it's not a primitive/System lib, it doesn't belong in Domain.
"Every handler needs a CQRS bus"Only if you need a cross-cutting pipeline or read/write model separation. Simple CRUD with a CQS Application service is valid and cleaner.
"Every entity should be an Aggregate"Only if the entity has invariants to protect. Plain data without business rules → use records and simple repositories.

Red Flags - STOP and Start Over

  • using MyApp.Application; inside API layer files
  • using MyApp.Infrastructure; inside Domain layer files
  • Injecting ICommandHandler<> or IQueryHandler<,> directly in API endpoints when using a CQRS bus — route through ICommandBus / IQueryBus
  • Command handler returns a domain ID — commands must be void (Task); the ID must be part of the incoming command
  • Non-sealed classes in Domain
  • Handlers performing HTTP calls directly (use an Infrastructure service via interface)
  • Adding ICommandBus / IQueryBus to a simple CRUD API with no domain logic, invariants, or cross-cutting pipeline — use a CQS Application use case (Pattern A) instead
  • Application class named *Service (e.g., OrderService) — rename to *UseCase; "Service" implies infrastructure or shared state, not a single bounded interaction

Common Mistakes

MistakeFix
Handler not found by DIHandler must be listed explicitly in AddInfrastructure() via AddHandler<T>()
using MyApp.Application; in APIRemove it — inject ICommandBus / IQueryBus (CQRS) or Application service (CQS) via DI
Command handler returns an IDCommands are void — the caller generates the ID and passes it in the command
Read result named ProductDtoName it ProductViewModel to distinguish from transfer objects
typeof(Product).Assembly in testsUse typeof(IApplicationMarker).Assembly for reliable discovery
Non-sealed Domain classesAll Domain classes must be sealed (enforced by NetArchTest)
SharedKernel references DomainSharedKernel must depend on nothing — if it references Domain, invert: Domain references SharedKernel
Handler contains if/domain invariant logicDelegate to Domain aggregate methods — handlers orchestrate only. Exception: Application use cases may contain access policy checks (if (resource.OwnerId != _currentUser.Id) throw) — that is use-case policy, not domain invariant logic
Creating Domain aggregates for CRUD entities with no invariantsUse a plain Application service with direct repository access — no aggregate, no events
Adding CQRS bus for < 3 use cases with no cross-cutting concernsUse Pattern A (CQS Application service) — less indirection, same layer safety

References

  • Architecture Layers — Dependency rules, marker interfaces, layer tests, and layer validation with NetArchTest
  • CQRS Patterns — Handler interfaces, examples, DI discovery, and complete CQRS implementation patterns
  • Convention-Based DI — Auto-discovery, Bus interfaces, full DI setup
  • Layer Responsibilities — Full rules for each layer with DDD context
  • Project Structure — File/folder conventions and layer organization guidance
  • NetArchTest Rules — Automated boundary enforcement
  • DDD Patterns — Aggregates, factory methods, value objects, and domain events (optional)
  • Shared Kernel — Shared abstractions for multi-context solutions (optional)
  • Interface Placement — Repository, authorization, and ICurrentUser placement with GetOrder (read policy) + CancelOrder (domain invariant) examples
  • Init Script — Bootstrap script for new project setup (./init-project.sh MyApp)
  • ArchitectureTests Template — Drop-in architecture test template

© SebastienDegodez, Apache-2.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 31 other files (scripts, references) in plugins/csharp-clean-architecture-development/skills/clean-architecture-dotnet of SebastienDegodez/copilot-instructions.

  • SKILL.md
  • references/architecture-layers.md
  • references/convention-based-di.md
  • references/cqrs-patterns.md
  • references/ddd.md
  • references/interface-placement.md
  • references/layer-responsibilities.md
  • references/netarchtest-rules.md
  • references/project-structure.md
  • references/shared-kernel.md
  • scripts/init-project.ps1
  • scripts/init-project.sh
  • templates/Api/IApiMarker.cs
  • templates/Application/IApplicationMarker.cs
  • templates/Application/Shared/ICommandBus.cs
  • … and 17 more

Open the folder on GitHubat commit 0f0dccf

Compare with similar skills

Clean Architecture Dotnet next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Clean Architecture Dotnet compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Clean Architecture Dotnet this skillSebastienDegodez/copilot-instructions198—~5.1kAutomated safety check: PassApache-2.0
Architecturemanagedcode/dotnet-skills486—~659Automated safety check: PassMIT
Scaffoldcodewithmukesh/dotnet-claude-kit756—~1.7kAutomated safety check: PassMIT
Architecture Advisorcodewithmukesh/dotnet-claude-kit7561 repos~2.9kAutomated safety check: PassMIT
Architect ReviewAratKruglik/claude-laravel1558 repos~2.2kAutomated safety check: PassNone
Dddcodewithmukesh/dotnet-claude-kit7561 repos~3kAutomated safety check: PassMIT

Similar skills

  • Architecture

    managedcode/dotnet-skills

    Design or review .NET solution architecture across modular monoliths, clean architecture, vertical slices, microservices, DDD, CQRS, and cloud-native boundaries without over-engineering.

    486 GitHub stars~659 tokensUpdated today
    DevelopmentAuto-check passed
  • Scaffold

    codewithmukesh/dotnet-claude-kit

    Architecture-aware feature scaffolding for .NET 10 projects.

    756 GitHub stars~1.7k tokensUpdated 2 mo ago
    DevelopmentAuto-check passed
  • Architecture Advisor

    codewithmukesh/dotnet-claude-kit

    Architecture selection advisor for .NET applications. An agent skill from codewithmukesh/dotnet-claude-kit.

    756 GitHub starsUsed in 1 repo~2.9k tokens
    DevelopmentAuto-check passed
  • Architect Review

    AratKruglik/claude-laravel

    Master software architect specializing in modern architecture patterns, clean architecture, microservices, event-driven systems, and DDD.

    155 GitHub starsUsed in 8 repos~2.2k tokens
    DevelopmentAuto-check passed
  • Ddd

    codewithmukesh/dotnet-claude-kit

    Domain-Driven Design tactical patterns for .NET applications.

    756 GitHub starsUsed in 1 repo~3k tokens
    DevelopmentAuto-check passed
  • Dotnet Cop

    fmflurry/settings-opencode

    Pre-merge code review for .NET 10 pull requests. An agent skill from fmflurry/settings-opencode.

    171 GitHub stars~2k tokensUpdated 3 days ago
    DevelopmentAuto-check passed

More from SebastienDegodez/copilot-instructions

All 19 skills in this repo
  • Setup Husky Dotnet

    SebastienDegodez/copilot-instructions

    A skill your agent uses when configuring Git hooks in .NET projects before team commits occur, to enforce commit message standards and code formatting automatically

    198 GitHub stars~1.3k tokensUpdated 4 days ago
    Auto-check passed
  • Outside In TDD

    SebastienDegodez/copilot-instructions

    A skill your agent uses when writing tests from the outside-in, defining behavior before code, or any feature where tests should start from observable business behavior and let internal design emerge

    198 GitHub stars~1.8k tokensUpdated 4 days ago
    Auto-check passed
  • Creating Dotnet MCP Servers

    SebastienDegodez/copilot-instructions

    A skill your agent uses when building Model Context Protocol (MCP) servers in .NET, configuring tools, transports (SSE/stdio), JSON serialization for AOT, or testing MCP endpoints

    198 GitHub stars~1.3k tokensUpdated 4 days ago
    Auto-check passed
  • Generate Microcks Openapi Samples

    SebastienDegodez/copilot-instructions

    A skill your agent uses when creating OpenAPI mock examples for Microcks, setting up request/response routing with dispatchers, or mapping request fields to mock responses

    198 GitHub stars~2.5k tokensUpdated 4 days ago
    Auto-check passed
  • Analyzing Code

    SebastienDegodez/copilot-instructions

    A skill your agent uses when understanding project composition by language, measuring code change impact, or generating code statistics for CI/CD metrics

    198 GitHub stars~1k tokensUpdated 4 days ago
    Auto-check passed
  • Extracting Code Structure

    SebastienDegodez/copilot-instructions

    A skill your agent uses when listing all methods, functions, or classes in a file, exploring unfamiliar code, getting API overviews, or deciding what to read selectively without loading entire files

    198 GitHub stars~1.3k tokensUpdated 4 days ago
    Auto-check passed

Works with

Categories

Questions about Clean Architecture Dotnet

What does Clean Architecture Dotnet do?

A skill your agent uses when domain logic leaks into API/Infrastructure, project references violate layer boundaries, or you need to decide between CQS (always), CQRS bus (complex domains), and DDD…. Clean Architecture Dotnet is an agent skill from SebastienDegodez/copilot-instructions. Use when domain logic leaks into API/Infrastructure, project references violate layer boundaries, or you need to decide between CQS (always), CQRS bus (complex domains), and DDD patterns (invariants and events).

When should I use Clean Architecture Dotnet?

Clean Architecture Dotnet fits situations like: domain logic leaks into API/Infrastructure; project references violate layer boundaries; you need to decide between CQS (always); CQRS bus (complex domains).

How do I install Clean Architecture Dotnet in Claude Code?

Run `npx skills add SebastienDegodez/copilot-instructions --skill clean-architecture-dotnet -a claude-code`. Or copy the skill folder (plugins/csharp-clean-architecture-development/skills/clean-architecture-dotnet in SebastienDegodez/copilot-instructions) into .claude/skills/clean-architecture-dotnet in your project. Claude Code loads it when a task matches its description.

How do I install Clean Architecture Dotnet in Codex?

Run `npx skills add SebastienDegodez/copilot-instructions --skill clean-architecture-dotnet -a codex`. Or copy the skill folder (plugins/csharp-clean-architecture-development/skills/clean-architecture-dotnet in SebastienDegodez/copilot-instructions) into .agents/skills/clean-architecture-dotnet in your project. Codex loads it when a task matches its description.

Can I use Clean Architecture Dotnet in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add SebastienDegodez/copilot-instructions --skill clean-architecture-dotnet -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/clean-architecture-dotnet, .gemini/skills/clean-architecture-dotnet, .github/skills/clean-architecture-dotnet and .opencode/skills/clean-architecture-dotnet in your project.

What does Clean Architecture Dotnet need to run?

Going by SKILL.md and its folder, Clean Architecture Dotnet needs C#, PowerShell and a shell for the scripts in its folder. Our summary lists: A Bash shell; PowerShell.

Does Clean Architecture Dotnet access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Clean Architecture Dotnet safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. The check reads SKILL.md only: the scripts in the folder are not scanned, so read them before running anything.

What licence does Clean Architecture Dotnet use?

Clean Architecture Dotnet is published under the Apache-2.0 licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Clean Architecture Dotnet use?

About 5.1k tokens (SKILL.md is roughly 21k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 17k tokens, read only when the agent opens those files.

What are the alternatives to Clean Architecture Dotnet?

Skills that share tags, products or a category with Clean Architecture Dotnet: Architecture (managedcode/dotnet-skills, 486 stars), Scaffold (codewithmukesh/dotnet-claude-kit, 756 stars), Architecture Advisor (codewithmukesh/dotnet-claude-kit, 756 stars) and Architect Review (AratKruglik/claude-laravel, 155 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Clean Architecture Dotnet?

SebastienDegodez (a GitHub user) maintains it in SebastienDegodez/copilot-instructions, which has 198 GitHub stars. The repository holds 19 skills in this directory. The repository was last updated on October 6, 2026.

Source: SebastienDegodez/copilot-instructions on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.