What this prompt does
This prompt makes the model a senior .NET engineer and asks for a production-ready .NET 9 Minimal API as working code, not pseudocode. You set [resource], [database], [auth_scheme], and [hosting], and it returns a wired Program.cs, route-grouped CRUD endpoints with paging, FluentValidation validators returning RFC 7807 problem details, JWT auth with role policies, EF Core entities plus a migration command, and xUnit integration tests using WebApplicationFactory.
The structure works because it bakes in the disciplines teams usually bolt on too late — validation, auth, and integration tests on day one. [resource] names the entity every endpoint and entity revolves around, [database] selects the EF Core provider so the DbContext and connection setup match, [auth_scheme] shapes the JWT and policy configuration on mutating endpoints, and [hosting] (for example, containerized on ECS) informs how the app is configured to run. Returning each concern as a separate labelled code block keeps the output readable and lets you drop files into a project one at a time, rather than untangling one giant listing that mixes startup, endpoints, and tests together.
When to use it
- You're starting a .NET 9 Minimal API and want a clean, opinionated skeleton.
- You want FluentValidation and RFC 7807 problem details wired from the start.
- You need JWT auth with role or policy checks on mutating endpoints.
- You want EF Core entities, configuration, and an initial migration generated together.
- You want integration tests covering happy path, validation failure, and 401 on day one.
- You're bringing the same validation-and-tests discipline you use in other stacks to .NET.
Example output
Expect separate, labelled code blocks: Program.cs with DI, EF Core, Serilog, and Swagger; the endpoint definitions grouped with route groups; the FluentValidation validators; the DbContext and entity configuration; and the xUnit test class. It closes with the dotnet CLI commands to run the API and execute the tests, including the migration command.
Pro tips
- Set
[database]to your real engine (SQL Server, PostgreSQL, SQLite) so the EF Core provider and migration are correct. - Wire the WebApplicationFactory tests from step 6 first; they catch DI and auth mistakes before staging does.
- Make
[auth_scheme]specific about roles and policies so the mutating-endpoint guards match your access model. - Use
[hosting]to signal config needs — containerized hosting changes how you handle connection strings and secrets. - Run the generated migration command in a throwaway database first to confirm the schema is what you expect.
- Ask it to add a second resource afterward to confirm the route-group and validation pattern scales cleanly.
- Keep the paging on the GET list endpoint; an unpaged list is the first thing to fall over once
[resource]accumulates real rows. - Review the JWT setup against your identity provider's actual token claims rather than trusting the default policy names verbatim.
