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.

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.

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.

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).
  • 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.