# Review Pull Requests on an ASP.NET Core App Yes. An agent checks out the pull request, runs dotnet build and dotnet test in its own sandbox, and posts one review citing file and line for each finding. [Run this on Rush](https://cloud.getrush.ai/run/review-pull-requests/aspnet-core/), in a Project that has your repository. ## What the agent does The agent reads the repository before it builds anything. In Jason Taylor's CleanArchitecture template (jasontaylordev/CleanArchitecture) it opens `global.json` and finds the .NET SDK pinned to 10.0.402 with `rollForward: latestFeature`, then the solution `CleanArchitecture.slnx` and the six test projects under `tests/`: `Application.UnitTests` (NUnit, Moq, Shouldly), `Domain.UnitTests`, `Infrastructure.IntegrationTests`, `Application.FunctionalTests` which references Respawn to reset the database between runs, `Web.AcceptanceTests` and a `TestAppHost`. It checks out the pull request branch, restores and runs `dotnet build` on the solution, then `dotnet test`. NUnit discovers every test project, so a change that breaks a MediatR-style handler in `src/Application` (TodoItems, TodoLists, WeatherForecasts) or an Entity Framework Core mapping in `src/Infrastructure/Data` fails a named project and test, and the output says which. The template pins the ASP.NET Core and EF Core packages at 10.0.13 in `Directory.Packages.props`, so the build uses the same versions CI does. With the build and suite green or red, it reads the diff with the prompt's focus areas in view. An EF Core query that filters or tracks more than the handler needs, an async method that blocks on `.Result` or drops an `await`, an endpoint missing the authorization attribute its sibling endpoints carry: each candidate is checked against the test projects to see whether an existing test covers the changed path before it is reported. What it posts is one GitHub review with the `dotnet build` and `dotnet test` results quoted at the top, findings that cite file and line, and a blocking-versus-suggestion split the summary states plainly. No commits are pushed to the pull request's branch. ## Start it with one API call `POST https://api.prix.dev/o/{org}/sessions` ```json { "agent": "claude", "input": "Review the open pull request on this repository. Check it out, run dotnet build and dotnet test, and post one review that cites file and line for every finding, paying particular attention to EF Core queries, async usage and authorization. Do not push commits.", "resources": [ { "url": "https://github.com/your-org/your-app/pull/42" } ] } ``` 1. **Get an API key.** In the console, open Settings, then API keys, and create a key for your org. Send it in the Authorization header as a Bearer token. 2. **Send the request.** POST the body in request.json to https://api.prix.dev/o/{org}/sessions, with your repository as the resources URL. The run starts in its own cloud sandbox. 3. **Read what came back.** Follow the run on its live stream or wait for the run.completed webhook, then read the result and its trajectory. ## What comes back What comes back is a review on the pull request. The summary quotes the build result and each test project's outcome, then lists findings with file and line, each marked blocking or suggestion. The review names the EF Core, async and authorization checks it ran, so a reviewer knows which classes of problem were looked for and which were found. The session's trajectory holds the evidence: the `dotnet build` and `dotnet test` invocations with their output, and the handler, mapping and test files the agent opened while reading the diff in context. When a finding claims a query over-fetches, the trajectory shows the query it read. Before merging, a reviewer reproduces the blocking findings: check out the branch, run `dotnet build` and `dotnet test`, open the cited line. Suggestions can be taken or dismissed without blocking the merge. ## Run it on every pull request opened Create an automation with a GitHub trigger on `pull_request.opened` and `pull_request.synchronize`, limited to the branches your team protects, and this prompt. Each pull request then gets its own run in its own sandbox with the full SDK the repository pins, and the review appears on the pull request without a developer checking anything out. Set a webhook URL on the API key and Rush POSTs `run.completed` when a run's turn finishes, with the session URL. Your server can forward the review link to the pull request's channel. A key admits at most `max_concurrent` runs, 4 by default, and answers `429` beyond it, which matters on a template repository where many contributors open pull requests the same day. ## Why run it on Rush? Verifying an ASP.NET Core change on a laptop means matching the SDK in `global.json`, restoring half a dozen projects and waiting through `dotnet test` before you can write a word of review. On Rush the agent does that loop in its own sandbox with the repository's own pinned SDK, and the trajectory keeps the build and test output next to the review, so a finding about an EF Core query is backed by the build and suite, not by reading the diff. The template's six test projects are the other reason to run this in the cloud: a `dotnet test` across the solution takes minutes a developer would rather spend elsewhere, and with one run per pull request, twenty pull requests get twenty sandboxes instead of one overloaded machine. Every review carries its own executed proof, and nothing touches the reviewer's working tree. ## Frequently asked questions ### Does it run all six test projects? `dotnet test` on the solution discovers every test project, unit, integration, functional and acceptance alike, and the review quotes each project's result. If you only need the fast signal, name one project in the prompt, for example `dotnet test tests/Application.UnitTests`, and it limits the run and says so in the review. ### Our app targets an older .NET. Does that matter? The agent builds with what the repository declares: the SDK pin in `global.json` and the target frameworks in the projects. A repository on an older SDK builds and tests with that SDK in the sandbox, the same as it does for this template's .NET 10 pin. ### Will it catch a missing authorization check? Authorization is one of the prompt's named focus areas, alongside EF Core queries and async usage. For an API where endpoints carry an authorization attribute or a policy, the agent compares the changed endpoint with its siblings and reports a missing one with file and line. ### What if the functional tests need a database? The functional and integration projects bring their own test infrastructure (the template uses Respawn to reset state between tests). Where a project expects a connection string, pass it as a Project secret or in the prompt, and the trajectory shows the exact `dotnet test` invocation it used.