dotnet-episteme-skills

DotNet Episteme Skills

Why these skills exist

AI coding tools can generate hundreds of source files in minutes. That speed is the point - but it shifts the bottleneck from writing code to trusting it.

The code compiles, the tests pass, and it still ships. Async operations quietly ignore cancellation signals. Buffers grow without bound until the process crashes under load. Sensitive user data flows into log files on every request. Public API contracts change without a deprecation path, silently breaking every caller that hasn't recompiled. Interfaces get refactored in one repository while nobody knows which of the other fourteen depend on them.

These aren't edge cases - they're the specific failure modes that general-purpose AI doesn't know to look for, and that tired humans miss in review. These skills exist to catch them before they reach production.

In a system with dozens or hundreds of microservices, where AI is generating implementations faster than any team can meaningfully review, the question isn't whether bad code will be written - it's whether you'll catch it before it ships. Most teams don't have the bandwidth or the .NET depth to review every generated service thoroughly. These skills fill that gap.

---

Install

Pick your tool. Claude Code, OpenCode and Codex each get a plugin with the skills, the multi-agent review, and the Synopsis dependency graph. Any other tool that supports Agent Skills can use the skills on their own.

What you get	Claude Code	OpenCode	Codex	Skills only
The 11 skills	✓	✓	✓	✓
Review with up to 5 reviewers + a reviewer that challenges them	/dotnet-review	/dotnet-review	ask for it (a skill)	one-pass review skill instead
Synopsis dependency graph, started for you	✓	✓	✓	start it yourself, or use the CLI
Story QA against the spec (per-AC verdicts, reuse, dead code)	/dotnet-qa	/dotnet-qa	ask for it (a skill)	one-pass QA skill instead
Phase-gated refactor loop with a design approval gate	/dotnet-refactor	/dotnet-refactor	ask for it (a skill)	—
Worker agents cannot change files	✓	✓	✓	—
A stronger model for big changes	automatic	opt-in	opt-in	—
Experimental log monitor	✓	—	—	—
Extra step after installing	none	none	one script	copy the skills

How to use the three pipelines, in plain words: docs/using-the-pipelines.md. Per-tool details: docs/tool-compatibility.md. Planned work: docs/roadmap.md.

Option 1: Plugin (Claude Code)

One command - skills activate automatically, and the review command, MCP server, and monitor come with it:

/plugin marketplace add Metalnib/dotnet-episteme-skills

Windows: the Synopsis MCP auto-start and log monitor launch through a POSIX shell script, so run Claude Code under WSL2 to get them (Synopsis then runs as a normal Linux binary). The review command, agents, and skills work on native Windows regardless; native Windows can also drive Synopsis through the CLI via skills/dotnet-techne-synopsis/scripts/detect-tool.ps1.

Option 2: Plugin (OpenCode)

OpenCode cannot read Claude Code plugins, so it has its own. Clone and run the installer, which registers everything and checks it worked:

git clone https://github.com/Metalnib/dotnet-episteme-skills.git
cd dotnet-episteme-skills
scripts/install-opencode.sh

You get the 11 skills, /dotnet-review with its five reviewers and the maintainer, /dotnet-qa, /dotnet-refactor, and the Synopsis graph server. git pull updates all of it. More: docs/opencode-setup.md.

Don't copy agents/review/*.md into OpenCode's own agent folder - they are written for Claude Code and OpenCode rejects them in a way that breaks its config. The installer converts them for you.

Option 3: Plugin (Codex)

Two commands install the plugin, then one script adds the thirteen worker roles (Codex only accepts those from its own config):

codex plugin marketplace add Metalnib/dotnet-episteme-skills
codex plugin add dotnet-episteme-skills@dotnet-episteme-marketplace
scripts/install-codex.sh    # or from the installed copy under ~/.codex/plugins/cache/

You get the 11 skills, thirteen worker roles that cannot change files, and the Synopsis graph server. The pipelines ship as skills (Codex is deprecating custom slash prompts in favour of skills), so you ask for a multi-agent review, a story QA, or a design loop in your own words. More: docs/codex-setup.md.

On first start Codex asks to trust the plugin's hook - choose Trust all and continue.

A full review uses six agents. On a free or metered plan, ask for a normal review of small changes instead.

Option 4: Skills-only (portable)

Download the latest archive from the releases page, extract, and copy skills/ into your tool's skills directory:

# Linux / macOS
tar -xzf dotnet-episteme-skills-1.8.2.tar.gz
cp -R skills/* ~/.claude/skills/          # Claude Code (skills only, no plugin extras)
cp -R skills/* ~/.config/opencode/skill/  # OpenCode
cp -R skills/* ~/.agents/skills/          # OpenAI Codex
# pi: add the extracted skills/ directory to pi's skill paths in settings

# Windows
Expand-Archive dotnet-episteme-skills-1.8.2.zip .
Copy-Item -Recurse skills\* "$env:USERPROFILE\.claude\skills\"

Or clone for easy updates:

git clone https://github.com/Metalnib/dotnet-episteme-skills.git
cp -R dotnet-episteme-skills/skills/* ~/.claude/skills/
# update later: git -C dotnet-episteme-skills pull && cp -R dotnet-episteme-skills/skills/* ~/.claude/skills/

Recommended companion: C# language intelligence (Claude Code)

For real-time diagnostics and go-to-definition while reviewing or refactoring, install the official C# LSP plugin alongside this one - it complements the review skills and Synopsis (per-file code intelligence vs cross-repo architecture graph):

/plugin install csharp-lsp@claude-plugins-official

dotnet tool install -g csharp-ls   # the language server binary the plugin expects on PATH

This plugin deliberately ships no .lsp.json of its own: only the first registered LSP server per file extension runs, so bundling one would conflict with the official plugin.

---

Skills

Skill	What it does	When to use it
dotnet-techne-code-review	Production-readiness review of .NET code: correctness, security, performance, data access, messaging, observability	After every AI-generated implementation, before any PR
dotnet-techne-synopsis	Roslyn-based dependency graph across all your repos: blast radius, cross-service call map, EF Core lineage, breaking-change diff	"What breaks if I change this?" across a microservices landscape
dotnet-techne-inspect	Decompiles and surfaces the public API of any NuGet package - internal or third-party	Before writing code against a package where you don't have the source
dotnet-techne-story-qa	Verifies a story implementation against its spec: per-AC verdicts with evidence and proving tests, reuse/design conformance, dead code, stale docs	Before marking a story done - "did we build what the ticket asked for?"
dotnet-techne-crap-analysis	Finds high-complexity, low-coverage methods (CRAP score)	Deciding where to focus test effort in a large codebase
dotnet-techne-cross-repo-impact	Checks a PR for breaking changes that hit other repos: API, DTO, endpoint, EF entity, NuGet package - and whether a compatible downstream PR already exists	Before merging a change to anything other services consume
dotnet-techne-csharp-api-design	Breaking-change detection, versioning strategy, deprecation paths, compatibility shims	Evolving a public or shared API without breaking callers
dotnet-techne-csharp-coding-standards	Modern C# idiom review: records, patterns, nullability, immutability	"Is this idiomatic?" or general refactoring guidance
dotnet-techne-csharp-concurrency-patterns	Async primitive selection, backpressure, lock-free patterns, deadlock detection	Choosing between async/await, Channel<T>, Dataflow, or Rx
dotnet-techne-csharp-type-design-performance	Hot-path allocations, readonly struct, FrozenDictionary, Span<T>, sealed types	Performance-sensitive or high-throughput code paths
dotnet-techne-serialisation	Wire contract safety, STJ source-gen, AOT compatibility, backwards compatibility across versions	Cross-service serialisation and versioned message schemas

---

Code review - the most important skill

The dotnet-techne-code-review skill performs end-to-end production-readiness review of .NET code changes. It's designed for the AI-coding workflow: you (or an agent) generate an implementation, then immediately review it before it ever reaches a human or a PR.

The review covers correctness (exception safety, CancellationToken propagation, thread-safety, retry and idempotency), performance (allocations on hot paths, unbounded buffers, missing backpressure, AOT/trimming), security (input validation, auth boundaries, SSRF controls, secrets in logs), data access (N+1 queries, missing indexes, EF Core misuse), messaging (ordering, poison messages, at-least-once safety), and observability (structured logging, metrics, correlation IDs).

Two modes are available. Standard is the default - balanced coverage of correctness, maintainability, and risk. Cynical/Adversarial mode assumes defects exist until disproven, generates at least five failure hypotheses, and validates each with evidence before reporting. Use it when the code is on a critical path or when you want the hardest possible challenge.

With the plugin installed, /dotnet-review [target] [--cynical] [--model tier] [--effort level] (fully: /dotnet-episteme-skills:dotnet-review) upgrades this to a multi-agent pipeline. Up to five reviewers run in parallel, each in a fresh isolated context: correctness/API, performance/AOT, security/observability, data/messaging/HTTP-integration, plus a generalist that hunts what falls between the lanes. Then an adversarial maintainer re-verifies every finding and refutes the ones that don't survive scrutiny, per maintainer-playbook.md.

The orchestration is a bundled dynamic workflow: a deterministic script that scales the reviewer model and reasoning effort to the size of the change and keeps raw findings out of your conversation. It runs slower than the single-context skill path - isolated reviewers and adversarial verification buy more thorough, run-to-run-consistent results in exchange for the time. bash scripts/install-workflow.sh optionally installs it standalone, where it registers as /dotnet-review-workers; the plugin's own /dotnet-review is the friendlier entry point and always matches the installed version. On other tools the same playbook runs as a single-context falsification pass.

Review the new OrdersController I just generated.

Critical review of this branch.

Cynical review of this PR before I merge.

Security-focused review of PR #247 (auth middleware).

Tear apart this message consumer - it'll be processing 250k messages/hour.

---

Synopsis - dependency graph and blast-radius analysis

The dotnet-techne-synopsis skill answers the architectural questions AI agents can't answer from code reading alone: what breaks if I change this, which services call that endpoint, what HTTP traffic touches this database table. It uses Roslyn to scan your entire .NET workspace and builds a live semantic dependency graph.