dotnet-techne-code-review

name	dotnet-techne-code-review
description	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.
disable-model-invocation	false
user-invocable	true
license	MIT
compatibility	Requires git and bash (Linux/macOS) or PowerShell (Windows). Works with any AI agent that supports the Agent Skills specification and has file read and command execution tools.
metadata	{"author":"Metalnib","version":"1.6.0","trigger_keywords":["code review","review pr","review diff","critical review","cynical review","adversarial review","production readiness","low gc","aot","security 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.