lang-csharp
Skill5 starsChanged 46 days agoMITView on GitHub
use this when writing, reviewing, or testing C# — *.cs, *.csproj, *.sln. do not use for Java or TypeScript. not a Unity or ASP.NET architecture skill.
In this repository49 other files it gives its agents.
- AGENTS.mdAGENTS.md
- maintainers/AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- buying-researcherSkill
- cursor-cloud-agents-whenSkill
- debug-anthropicSkill
- debug-pocockSkill
- debugSkill
- discover-the-ideaSkill
- docs-google-styleSkill
- golang-safetySkill
- golang-securitySkill
- golang-testingSkill
- grok-acpSkill
- host-config-pyinfraSkill
- lang-cppSkill
- lang-cSkill
- lang-dartSkill
- lang-dockerSkill
- lang-goSkill
- lang-javaSkill
- lang-js-tsSkill
- lang-kotlinSkill
- lang-luaSkill
- lang-makefileSkill
- lang-phpSkill
- lang-powershellSkill
- lang-protobufSkill
- lang-pythonSkill
- lang-rubySkill
- lang-rustSkill
- lang-shellSkill
- lang-sqlSkill
- lang-swiftSkill
- lang-terraformSkill
- language-routerSkill
- lang-web-markupSkill
- modern-pythonSkill
- pr-reviewSkill
- sdlc-artifactsSkill
- sdlc-onboardingSkill
- security-hardeningSkill
- shell-safetySkill
- tddSkill
- tracker-sdlcSkill
- ui-craftSkill
- ux-designSkill
- verify-before-doneSkill
- yagniSkill
The file
We split this skill into the rules it gives an agent
3 rules. About 0 are common, 2 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 23
Run on the touched project.
- Distinctive: line 41
Do not use exceptions for ordinary control flow.
- Very specific: line 53
Test behavior through the public type.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
C#
Language guide. No scripts/.
Process skills that may load with this one: language-router Load-with list.
Iron law
Nullable reference types on. Dispose what you acquire. Async all the way down.
Tooling / verify
dotnet test --nologo
dotnet format --verify-no-changes # when the repo already uses itRun on the touched project. Read failing tests. Do not add a second test framework.
Idioms a linter misses
- Nullable enabled. Treat warnings as errors if the project already does.
await using/usingforIDisposable/IAsyncDisposable.- Records / required members for values. Do not mutate DTOs in place if the file is already immutable.
- LINQ for clarity. Do not enumerate an expensive
IEnumerabletwice by accident. - Public APIs: properties over public fields.
IReadOnlyList<T>when the caller must not mutate.
Errors
- Throw specific exceptions. Do not swallow.
OperationCanceledExceptionis cancellation, not a generic failure.- Do not use exceptions for ordinary control flow.
Concurrency
async Task. Noasync voidexcept event handlers.- No
.Result/.Wait()on Tasks (deadlock + thread-pool starve). ConfigureAwait(false)only if the project already does in libraries.CancellationTokenis the last parameter and is plumbed.
Testing
- xUnit / NUnit / MSTest as the repo chose.
- Test behavior through the public type.
IHttpClientFactory/ time / RNG are the mock boundaries. async Tasktests. No.Resultin tests either.
PR review
- New
async voidin library code: reject. - New
IDisposablewithoutusingat call sites. - Nullable suppression (
!): local and named, or reject. - Public surface: breaking changes to nullability are breaking.
Security
- Parameterized SQL. No string concat into commands.
- No
BinaryFormatter/ insecure deserializers. Process.Start: argument array, never a concatenated command line.- Secrets not in config committed to git. User-secrets / env as the project already does.
Always
- Dispose / async-dispose.
awaitthe Task.- Tests for the new branch.
Ask first
- Disabling nullable for a file.
- Adding an analyzer package the repo does not have.
- Mixing sync-over-async to "keep this controller sync."
Never
async voidin library code..Result/.Wait()on production paths.- Public fields on API types.
BinaryFormatter.
Red flags
- "I'll .Result it to keep this sync"
- "nullable is too noisy"
- "we dispose it in the finalizer"
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

