# Dotnet Techne Code Review

> Use when reviewing PRs/diffs/branches/documents for .NET quality, correctness, performance, security, data access, messaging, and observability. Includes adversarial critical-thinking mode for skeptical/cynical review requests. Keywords: code review, review PR, review diff, critical review, cynical review, adversarial review, production readiness, low GC, AOT, security review.

- Skill: `metalnib/dotnet-techne-code-review` (Agent Skill, multi-file: 19 files)
- Install (CLI): `npx skillmds@latest add metalnib/dotnet-techne-code-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/metalnib/dotnet-techne-code-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- License: MIT
- Author: Metalnib (https://skillmd.com/u/metalnib)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/metalnib/dotnet-techne-code-review

---

# End-to-end .NET Code Review

Lean entrypoint for high-signal .NET review. Detailed commands/checklists/output requirements are split into reference files for progressive disclosure.

On Claude Code with this plugin installed, prefer `/dotnet-episteme-skills:dotnet-review` for parallel multi-agent review (4 domain specialists + a generalist + adversarial maintainer verification). This file remains the complete single-context procedure for all other tools.

## Requirements
This skill requires:
- **Git** for diff and commit analysis
- **Bash/Zsh** (Linux/macOS) or **PowerShell 5.1+** (Windows)
- **Agent tools** with file read capability and shell command execution

Optional but recommended:
- `rg` (ripgrep) for faster dependency searches on Linux/macOS
- `dotnet` CLI for build verification

## When to use this skill
Use this skill when the user asks for:
- PR / branch / diff / commit-range review
- "code review this implementation"
- "critical review of ..."
- "cynical review of ..."
- adversarial / devil's-advocate review
- production-readiness review (performance, AOT/trimming, security, observability, DB, messaging)

## Reference files (read on demand)
- `references/scripts-and-context.md`
  - Read first when gathering change context and choosing script commands.
- `references/domain-checklists.md`
  - Read after context is loaded; focus on only the relevant sections for changed components.
- `references/output-contract.md`
  - Read before writing the final review output.
- `references/maintainer-playbook.md`
  - Read during the falsification pass (Step 3) to pressure-test findings before output.

## Review modes

### Standard mode (default)
- Balanced review focused on correctness, maintainability, and risk.

### Cynical mode (adversarial)
Use when request language is explicitly skeptical: "critical review", "cynical review", "tear this apart", "assume this is broken", "devil's advocate".

Mandates:
- Assume defects exist until disproven.
- Prefer failure-mode discovery over style nits.
- Generate **at least 5 issue hypotheses** before finalizing.
- Validate each hypothesis with evidence; remove weak/speculative findings.

## Core workflow

### Step -1: Receive content
- Load content from provided input or current context.
- If content is empty (no diff/branch/files/document), ask for clarification and stop.
- Identify content type: diff, branch, uncommitted changes, commit range, or document/spec.

### Step 0: Gather context
- Read `references/scripts-and-context.md`.
- Run the baseline context commands.
- Read changed files with your file-read tool.

### Step 1: Select review mode
- Use **Cynical** mode for explicitly skeptical requests.
- Otherwise use **Standard** mode.

### Step 2: Establish component context
- Identify component type(s): API, worker, repository, domain, messaging, etc.
- Identify critical paths: request path, message path, DB path.
- Identify invariants: idempotency, correlation, ordering, transaction boundaries.

### Step 3: Adversarial hypothesis pass
- Generate candidate defects (at least 5 in cynical mode).
- For each hypothesis, collect direct evidence (`file:line`, snippet, or command output).
- Try to falsify each hypothesis (tests, guards, explicit design intent, invariants).
- Apply `references/maintainer-playbook.md` to each surviving finding (maintainer persona, five checks, evidence-backed verdicts).
- Keep only confirmed/high-signal findings.

### Step 4: Domain checklist pass
- Read `references/domain-checklists.md`.
- Apply only relevant sections based on changed files and architecture.
- If scope is unclear, run all sections but prioritize correctness/security/data-loss risks first.

### Step 5: Produce findings
- Read `references/output-contract.md`.
- Format output exactly as specified there.