dotnet-implementation
Skill4 starsChanged 51 days agoMITView on GitHub
Implement production .NET or ASP.NET Core behavior within an existing codebase. Use for features, enhancements, fixes after diagnosis, and requested refactoring; not for review-only or investigation-only work.
In this repository37 other files it gives its agents.
- global-instructions/AGENTS.mdAGENTS.md
- api-contract-safetySkill
- api-endpoint-deprecationSkill
- aspnet-core-api-developmentSkill
- background-services-dotnetSkill
- bug-investigationSkill
- code-qualitySkill
- code-reviewSkill
- context-resetSkill
- dependency-managementSkill
- deployment-readiness-dotnetSkill
- diff-reviewSkill
- distributed-workflowsSkill
- dotnet-architectureSkill
- dotnet-securitySkill
- ef-core-safetySkill
- exception-handlingSkill
- git-workflowSkill
- google-bigquery-dotnetSkill
- google-cloud-pubsub-dotnetSkill
- google-firestore-dotnetSkill
- http-client-integrationsSkill
- integration-testing-dotnetSkill
- observability-dotnetSkill
- performance-diagnostics-dotnetSkill
- poc-developmentSkill
- production-debuggingSkill
- production-hotfixSkill
- production-loggingSkill
- redis-dotnetSkill
- relational-database-dotnetSkill
- retry-resilienceSkill
- safe-terminalSkill
- shared-code-impactSkill
- targeted-validationSkill
- task-routerSkill
- unit-testingSkill
The file
We split this skill into the rules it gives an agent
6 rules. About 0 are common, 4 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 8
Use this sequence: understand -> trace -> identify impact -> implement -> review diff -> validate.
- Distinctive: line 10
Start from the relevant entry point and follow the actual path: controller/handler -> service -> mapper/helper -> persistence or external …
- Very specific: line 12
Before changing shared helpers, extensions, middleware, models, mappers, DI registration, auth, configuration, serialization, or common …
- Very specific: line 16
Follow current project language version, nullable settings, analyzers, conventions, and libraries.
- Distinctive: line 20
Add meaningful tests for new or materially changed testable business logic.
- Distinctive: line 22
Before completion, verify the requested observable behavior, inspect the final diff, run proportionate relevant checks, and report any …
≈ “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
Safe .NET implementation
Use this sequence: understand -> trace -> identify impact -> implement -> review diff -> validate.
Start from the relevant entry point and follow the actual path: controller/handler -> service -> mapper/helper -> persistence or external integration. Keep a small working set and expand only when evidence requires it.
Before changing shared helpers, extensions, middleware, models, mappers, DI registration, auth, configuration, serialization, or common libraries, find their usages and load shared-code-impact.
Implement the requested behavior without changing unrelated behavior. If a rule applies to one API, customer, reseller, country, region, sender, integration, feature flag, or workflow, encode that scope rather than making it global. Do not modernize adjacent code or reformat unrelated files.
Follow current project language version, nullable settings, analyzers, conventions, and libraries. Preserve architectural layers and public contracts. Propagate cancellation through cancellable I/O; avoid sync-over-async and async void; respect DI lifetimes; use structured logs without secrets; dispose owned resources; keep configuration validated and externalized.
For conditional runtime guidance, read only the relevant section of references/runtime-safety.md.
Add meaningful tests for new or materially changed testable business logic. Validate once after a coherent change, escalating from focused tests/builds only as risk or evidence requires.
Before completion, verify the requested observable behavior, inspect the final diff, run proportionate relevant checks, and report any validation not performed.
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.

