Open
Conversation
- Create dotnet-aspnet plugin (reserved name for ASP.NET Core skills) - Add dotnet-webapi skill for Web API endpoint creation with proper HTTP semantics, OpenAPI metadata, error handling, and EF Core wiring - Add eval.yaml with 5 scenarios: CRUD API, EF migration usage, error handling, OpenAPI setup, and controller-based projects - Update marketplace.json (both copies), CODEOWNERS, and README.md Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Reduce prompt scope in the two slowest scenarios to lower agent execution time (the dominant cost in eval runs): Scenario 1 - CRUD Minimal API (600s -> 240s): - Reduce from 5 endpoints to 3 (GET list, GET by ID, POST) - Remove Category entity and EF Core/SQLite, use in-memory service - Remove OpenAPI requirements (already tested in dedicated scenario) - Trim assertions from 6 to 3, rubric items from 12 to 7 Scenario 2 - Controller-based endpoint (360s -> 240s): - Remove OrderItems sub-entity, keep Order -> Customer relationship - Reduce from full CRUD to 3 endpoints (list, get, create) - Trim rubric items from 8 to 6 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Trim SKILL.md from 497 to 415 lines by removing guidance that belongs in other skills: - Remove standalone 'Seal all types by default' section (general C#) - Gut Step 6 'Wire up data access' to keep only the service layer pattern; remove DbContext, migrations, HasData, Fluent API, and AsNoTracking guidance (belongs in optimizing-ef-core-queries skill) - Remove EF Core items from Validation checklist and Common Pitfalls - Remove EF Core Migrations link from More Info - Update frontmatter to remove 'data access wiring' from USE FOR - Update eval rubric to remove DbContext reference Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
- Swashbuckle restriction now applies only to .NET 9+ projects; projects targeting .NET 8 or earlier can still use Swashbuckle - Remove pagination section from Step 3 (PaginatedResponse record, page size defaults) and all related references in validation checklist, common pitfalls, frontmatter, service layer example, .http sample, and eval.yaml scenarios SKILL.md: 415 -> 374 lines Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Reduce from 3 endpoints to 2 (GET list + POST create), drop service layer and customer relationship from requirements, trim rubric from 5 to 4 items, and lower timeout from 240s to 180s. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Merge the OpenAPI scenario into the CRUD scenario to reduce from 4 to 3 test cases. Add assertions and rubric items for DateTimeOffset, XML doc comments, enum string serialization, Middleware folder placement, and OpenAPI metadata across all scenarios. Enrich prompts with date/time and enum fields to naturally exercise the new requirements. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Contributor
There was a problem hiding this comment.
Pull request overview
This PR introduces a new dotnet-webapi skill under the dotnet-aspnet plugin, along with evaluation scenarios to validate the skill’s guidance for ASP.NET Core Web APIs (minimal APIs + controller-based extensions, OpenAPI metadata, and ProblemDetails-based error handling).
Changes:
- Added a new
dotnet-webapiskill document describing recommended patterns for DTOs, HTTP semantics, OpenAPI setup, and global error handling. - Added a new
dotnet-webapiskill-validator eval suite covering minimal API CRUD + OpenAPI, ProblemDetails/IExceptionHandler error handling, and extending a controller-based project.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 5 comments.
| File | Description |
|---|---|
| tests/dotnet-aspnet/dotnet-webapi/eval.yaml | New eval scenarios and assertions for validating the dotnet-webapi skill behavior. |
| plugins/dotnet-aspnet/skills/dotnet-webapi/SKILL.md | New skill guidance for ASP.NET Core Web API endpoint creation/modification, OpenAPI, and global error handling. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
mikekistler
reviewed
Apr 6, 2026
Co-authored-by: Mike Kistler <mikekistler@microsoft.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Contributor
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 2 out of 2 changed files in this pull request and generated 9 comments.
Comments suppressed due to low confidence (1)
tests/dotnet-aspnet/dotnet-webapi/eval.yaml:134
- Scenario 3’s rubric requires POST to return
CreatedAtAction, but the assertions don’t check for it. Adding anoutput_contains: "CreatedAtAction"(or similar) assertion would prevent regressions when the judge fails or is unavailable.
value: "ControllerBase"
- type: "output_contains"
value: "[ApiController]"
- type: "output_contains"
value: "CancellationToken"
- type: "output_not_matches"
pattern: "app\\.(MapGet|MapPost|MapPut|MapDelete|MapPatch)|\\b(MapGet|MapPost|MapPut|MapDelete|MapPatch)\\b"
- type: "output_contains"
value: "DateTimeOffset"
- type: "output_matches"
pattern: "/// <summary>"
rubric:
- "Continues with the controller pattern since the existing project uses controllers (does not mix minimal APIs)"
- "Includes CancellationToken in all endpoint signatures"
- "POST create returns CreatedAtAction with 201 status, not Ok with 200"
- "Uses sealed record DTOs with proper naming (CreateOrderRequest, OrderResponse)"
- "Date/time properties use DateTimeOffset, not DateTime"
- "All request and response DTOs include XML doc summary comments"
timeout: 600
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
- Remove non-existent dotnet-csharp skill reference from frontmatter - Fix escaped code fences in JSON serialization section - Scope strict JSON serialization guidance to new projects only - Use enum type in DTO examples for consistency with enum guidance - Avoid leaking exception.Message in ProblemDetails.Detail - Add CancellationToken assertion to eval scenario 1 - Update .http file example to use enum string value Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Member
Author
|
@mikekistler the PR is ready for your review |
mikekistler
approved these changes
Apr 8, 2026
mikekistler
left a comment
mikekistler
left a comment
There was a problem hiding this comment.
Looks good! 👍
I suggested one more minor improvement that gave better results in my local tests.
Co-authored-by: Mike Kistler <mikekistler@microsoft.com>
Contributor
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Contributor
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Comment on lines
+343
to
+351
| await httpContext.Response.WriteAsJsonAsync(new ProblemDetails | ||
| { | ||
| Status = statusCode, | ||
| Title = title, | ||
| // Do not use exception.Message here — it may leak sensitive internal details. | ||
| // Use a safe, user-facing message instead. | ||
| Detail = title, | ||
| Instance = httpContext.Request.Path | ||
| }, cancellationToken); |
There was a problem hiding this comment.
In the custom IExceptionHandler example, WriteAsJsonAsync(new ProblemDetails { ... }) will default the response content-type to application/json. For RFC 7807 interoperability, set the content type to application/problem+json (e.g., via the contentType parameter on WriteAsJsonAsync, or by setting httpContext.Response.ContentType before writing).
Suggested change
| await httpContext.Response.WriteAsJsonAsync(new ProblemDetails | |
| { | |
| Status = statusCode, | |
| Title = title, | |
| // Do not use exception.Message here — it may leak sensitive internal details. | |
| // Use a safe, user-facing message instead. | |
| Detail = title, | |
| Instance = httpContext.Request.Path | |
| }, cancellationToken); | |
| await httpContext.Response.WriteAsJsonAsync( | |
| new ProblemDetails | |
| { | |
| Status = statusCode, | |
| Title = title, | |
| // Do not use exception.Message here — it may leak sensitive internal details. | |
| // Use a safe, user-facing message instead. | |
| Detail = title, | |
| Instance = httpContext.Request.Path | |
| }, | |
| contentType: "application/problem+json", | |
| cancellationToken: cancellationToken); |
Comment on lines
+8
to
+12
| The API should have these endpoints: | ||
| - GET /api/products (list all) | ||
| - GET /api/products/{id} (get by ID) | ||
| - POST /api/products (create a product) | ||
|
|
There was a problem hiding this comment.
This scenario’s endpoint list only includes GET (list), GET (by ID), and POST (create), but the scenario name says “CRUD”. Either rename the scenario to match the three endpoints, or add update/delete endpoints so it is actually CRUD (and can validate the corresponding HTTP semantics).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds the
dotnet-webapiskill to thedotnet-aspnetplugin. This skill guides the creation and modification of ASP.NET Core Web API endpoints with correct HTTP semantics, OpenAPI metadata, and error handling.Here is a sample project created with this skill https://github.com/sayedihashimi/sample-projects/tree/2026.04.01.FitnessStudioApi
What's included
New skill:
plugins/dotnet-aspnet/skills/dotnet-webapi/SKILL.mdA comprehensive skill covering the following areas:
sealed recordDTOs with proper naming conventions (CreateXxxRequest,XxxResponse), XML doc comments, andDateTimeOffsetfor timestamps.TypedResultswith explicitResults<T1, T2>return types,CancellationTokenforwarding, and OpenAPI endpoint metadata (WithName,WithSummary,WithDescription).[ApiController]conventions withActionResult<T>return types andProducesResponseTypeattributes.AddOpenApi()/MapOpenApi()instead of Swashbuckle; includes XML doc comment integration andJsonStringEnumConverterfor enum serialization.IExceptionHandlerwith RFC 7807ProblemDetails, exception-to-status-code mapping, and a sealed handler class in aMiddleware/folder..httptest files — Generates test files for verifying endpoints directly from the IDE.New tests:
tests/dotnet-aspnet/dotnet-webapi/eval.yamlThree evaluation scenarios with assertions and rubrics:
Skill validator results
claude-opus-4.6, judge-mode: Pairwise, 5 runs per scenarioSkill validator results
@mikekistler