What this prompt does
This prompt scaffolds an ASP.NET Core 8 minimal API for a given [api_purpose] following Clean Architecture. It sets up [project_count] projects — API, Application, Domain, Infrastructure — with the dependency flow pointing inward, then builds [endpoint_groups] endpoint groups using MapGroup(), integrates FluentValidation returning ProblemDetails for [validation_scenarios], and adds global exception handling, DI via [di_pattern], OpenAPI with [auth_method], and health checks for [health_dependencies].
The structure works because Clean Architecture only pays off if the dependency flow actually points inward, so the prompt makes that the first thing it establishes. Mapping domain exceptions to ProblemDetails and grouping endpoints with MapGroup() is the combination that keeps the API consistent as it grows. The [di_pattern] choice and correct middleware ordering — exception handling, authentication, authorization, CORS, rate limiting — are spelled out so the pipeline behaves predictably from the start.
When to use it
- You are starting a new minimal API and want Clean Architecture structure from the first commit
- You need endpoint groups organized with
MapGroup()and OpenAPI tag metadata for[endpoint_groups] - You want FluentValidation wired to return consistent ProblemDetails for
[validation_scenarios] - You need a global exception handler mapping domain exceptions to correct HTTP status codes
- You want DI registered cleanly via
[di_pattern]with correct service lifetimes - You need health-check endpoints for dependencies like
[health_dependencies]
Example output
Expect a project scaffold and code: a four-project solution with the dependency arrows pointing inward, endpoint-group registrations using MapGroup(), a ValidationFilter returning ProblemDetails, exception-handling middleware, DI registration code with scoped, singleton, and transient lifetimes assigned correctly, Swagger or Scalar configuration including the security scheme, health-check endpoints, and a correctly ordered middleware pipeline.
Pro tips
- State
[api_purpose]concretely — an inventory system drives different endpoint groups and domain models than a generic CRUD API - Keep the dependency flow strict: Domain depends on nothing, and the prompt will respect that only if you don't let infrastructure leak inward
- Be specific in
[validation_scenarios]so the generated FluentValidation rules cover real business constraints, not just non-null checks - Pick a
[di_pattern]your team understands; Scrutor assembly scanning reduces boilerplate but hides registrations, so weigh that against explicit registration - Watch service lifetimes — the classic bug is injecting a scoped DbContext into a singleton, and the prompt assigns lifetimes but you should verify them
- Confirm middleware order matches the prompt's sequence; exception handling must sit outermost or thrown errors bypass your ProblemDetails formatting
- Add OpenAPI tag metadata and example requests per group so the generated Swagger or Scalar docs are genuinely usable by the clients consuming
[api_purpose] - Wire each item in
[health_dependencies]to a real readiness probe rather than a hardcoded healthy response, or the endpoint will report green while a dependency is down - Keep validation in FluentValidation rather than scattering checks into endpoints, so
[validation_scenarios]rules stay in one place as the API grows
