Designing a .NET Review Skill That Is Allowed to Say Nothing
noteSeptember 30, 2026By Ali Haghighi
I started this experiment with a prompt that was almost too easy to write: "Review this pull request."
The result looked useful at first, but I could not tell what the reviewer was optimizing for. It could comment on naming, redesign a class, miss a cancellation problem and still produce a polished answer.
For the first artifact in my AI Lab, I therefore made the task smaller rather than making the prompt longer: a .NET change-review skill with an explicit contract.
Narrow the job before improving the prompt
The skill focuses on production risks I regularly care about in C# changes: cancellation propagation, async behavior, resource ownership, exception semantics, compatibility, unbounded buffering, disposal and tests around changed boundaries.
It deliberately does not score code quality, enforce style or redesign architecture.
That distinction matters. A useful review assistant should not turn every diff into an architecture discussion.
Evidence before confidence
A finding must point to behavior visible in the supplied diff or surrounding context. If the conclusion depends on a contract that is not available, the output should become a question rather than a defect.
Stream ownership is a good example. Disposing an input stream may be a bug if the caller owns it, but the same code can be correct when ownership is transferred. The model should not invent the contract.
Silence is an evaluation case
One of the evaluation cases contains a small correct change. The expected result is no material finding.
This is intentional. Systems optimized to always produce feedback quickly become noisy. In code review, a false positive consumes attention and makes later findings easier to ignore.
What I am testing next
The current artifact is a specification with four small evaluation cases, not a claim of review accuracy. The next useful step is to run the same cases across model/configuration changes and record whether expected findings remain stable.
I also want to test ambiguous diffs where the right response is a question, because that boundary is more interesting than another example of catching an obvious missing cancellation token.
The skill specification and examples are linked from the AI Lab.