Add .NET skills and quality tooling guidance

Author: KSemenenko

README.md

@@ -0,0 +1,68 @@
+---
+name: mcaf-ci-cd
+description: "Design or refine CI/CD workflows, quality gates, release flow, and safe AI-assisted pipeline authoring. Use when adding or changing build pipelines, release stages, IaC-driven environments, or deployment rollback policy."
+compatibility: "Requires repository access; may update CI workflows, pipeline docs, and release guidance."
+---
+
+# MCAF: CI/CD
+
+## Trigger On
+
+- adding or changing CI workflows
+- defining release flow or rollback policy
+- tightening pipeline quality gates
+- writing or reviewing AI-assisted pipeline YAML
+
+## Do Not Use For
+
+- feature-level testing with no pipeline or release impact
+- general source-control policy without CI/CD changes
+
+## Inputs
+
+- the current pipeline and release flow
+- real build, test, analyze, and deploy steps
+- environment and rollback constraints
+
+## Workflow
+
+1. Define the target flow first:
+   - PR validation
+   - integration-branch gates
+   - non-production deployment
+   - production promotion or release
+2. Keep pipelines reviewable:
+   - explicit build, test, and analyze steps
+   - least-privilege secrets and permissions
+   - rollback or fail-safe strategy
+3. Treat AI-generated YAML as draft content until it is reviewed and validated.
+4. For .NET repositories, make the quality gate explicit:
+   - formatting ownership
+   - analyzer ownership
+   - coverage and report generation
+   - runner model (`VSTest` or `Microsoft.Testing.Platform`)
+5. Pull only the references that match the current delivery problem.
+
+## Deliver
+
+- CI/CD changes that are explicit, reproducible, and reviewable
+- release documentation with rollback thinking
+- pipeline rules aligned with MCAF verification
+
+## Validate
+
+- every stage has a clear purpose and failure signal
+- rollback or safe failure is explicit
+- secrets and permissions are minimized
+- the pipeline matches the repo’s actual verification model
+
+## Load References
+
+- read `references/ci-cd.md` first
+- for .NET quality gates, use `mcaf-dotnet-quality-ci`
+
+## Example Requests
+
+- "Design CI for this repo."
+- "Tighten our deployment gates and rollback story."
+- "Review this GitHub Actions YAML before we trust it."

TUTORIAL.md

@@ -0,0 +1,58 @@
+---
+name: mcaf-dotnet-analyzer-config
+description: "Use a repo-root `.editorconfig` to configure free .NET analyzer and style rules. Use when a .NET repo needs rule severity, code-style options, section layout, or analyzer ownership made explicit. Nested `.editorconfig` files are allowed when they serve a clear subtree-specific purpose."
+compatibility: "Requires a .NET SDK-based repository; respects the repo's `AGENTS.md` commands first."
+---
+
+# MCAF: .NET Analyzer Config
+
+## Trigger On
+
+- the repo needs a root `.editorconfig`
+- analyzer severity and style ownership are unclear
+- the team wants one source of truth for rule configuration
+
+## Do Not Use For
+
+- choosing analyzers with no config change
+- formatting-only execution with no config ownership question
+
+## Inputs
+
+- the nearest `AGENTS.md`
+- current `.editorconfig`
+- any `Directory.Build.props` overrides
+
+## Workflow
+
+1. Prefer one repo-root `.editorconfig` with `root = true`.
+2. Add nested `.editorconfig` files when a subtree has a clear scoped purpose, such as stricter rules, different generated-code handling, or a different policy for tests or legacy code.
+3. Keep severity in `.editorconfig`, not scattered through IDE settings.
+4. Write the file as real EditorConfig, not as a made-up `.NET` variant:
+   - lowercase filename `.editorconfig`
+   - `root = true` in the preamble
+   - no inline comments
+   - forward slashes in globs
+5. Keep bulk switches such as `EnableNETAnalyzers` in MSBuild files, not in `.editorconfig`.
+6. Treat `.globalconfig` as an exceptional case, not the normal repo setup.
+
+## Deliver
+
+- one explicit analyzer configuration ownership model
+- a root `.editorconfig` layout that agents can extend safely
+
+## Validate
+
+- rule severity is reproducible in local and CI builds
+- IDE-only settings do not silently override repo policy
+- the default path is a root `.editorconfig`, not a surprise alternative
+
+## Load References
+
+- read `references/analyzer-config.md` first
+
+## Example Requests
+
+- "Make `.editorconfig` the source of truth."
+- "Write a proper root `.editorconfig` for this repo."
+- "Fix conflicting analyzer severities in this .NET repo."

docs/templates/AGENTS.md

@@ -0,0 +1,155 @@
+# .NET Root .editorconfig
+
+## Open/Free Status
+
+- built-in .NET configuration system
+- free to use
+
+## Default Placement
+
+The default MCAF path is:
+
+- one repo-root lowercase `.editorconfig`
+- `root = true` at the top
+- optional nested `.editorconfig` files when a subtree has a clear scoped purpose
+
+## Verify First
+
+Before adding a new config file, check whether the repo already has one:
+
+```bash
+rg --files -g '.editorconfig' -g '.globalconfig'
+```
+
+## File Format
+
+`EditorConfig` is an INI-style format:
+
+- section names are path globs like `[*.cs]` or `[src/**/*.cs]`
+- files are read from the current file directory upward
+- `root = true` stops the search
+- closer matching `.editorconfig` files override earlier parent rules
+- later matching sections in the same file win
+- comments must be on their own line and start with `#` or `;`
+- inline comments are not part of the format
+- the file should be UTF-8 with `LF` or `CRLF` line separators
+- forward slashes are the path separator in section globs
+- keys and values are case-insensitive
+- `unset` removes the effect of a previously set property
+
+## Core Rules That Matter for .NET
+
+- only `root` belongs in the preamble for effect outside sections
+- all other effective pairs belong under a matching section such as `[*.cs]`
+- unknown keys are allowed by the EditorConfig format, which is why `.NET`-specific keys like `dotnet_diagnostic.*`, `dotnet_style_*`, and `csharp_*` can live in `.editorconfig`
+- unsupported keys or values may be ignored by a given plugin or tool, so keep repo expectations tied to tools that actually honor them
+
+## Glob Rules That People Commonly Get Wrong
+
+- `*.cs` can match at any level below the directory that contains the `.editorconfig`
+- `src/*.cs` is relative to the directory that contains that `.editorconfig`
+- if a glob contains `/`, use `/`, never `\\`
+- a section ending with `/` does not match a file
+- a leading `/` does not add extra meaning if the glob already contains a `/`
+
+## Comments
+
+Good:
+
+```ini
+# C# rules
+[*.cs]
+dotnet_diagnostic.CA1502.severity = warning
+```
+
+Bad:
+
+```ini
+[*.cs]
+dotnet_diagnostic.CA1502.severity = warning # inline comment
+```
+
+In the bad example, the trailing `# inline comment` is not a comment under the current specification.
+
+## Recommended Root Layout
+
+Start with one root file like this:
+
+```ini
+root = true
+
+[*]
+charset = utf-8
+end_of_line = lf
+insert_final_newline = true
+trim_trailing_whitespace = true
+
+[*.cs]
+indent_style = space
+indent_size = 4
+dotnet_analyzer_diagnostic.severity = warning
+dotnet_style_qualification_for_method = false:suggestion
+dotnet_style_qualification_for_property = false:suggestion
+dotnet_style_qualification_for_field = false:suggestion
+dotnet_style_qualification_for_event = false:suggestion
+
+[*.{csproj,props,targets}]
+indent_style = space
+indent_size = 2
+```
+
+Then add rule-specific severity in the same root file:
+
+```ini
+root = true
+
+[*.cs]
+dotnet_diagnostic.CA1000.severity = warning
+dotnet_diagnostic.CA1502.severity = warning
+dotnet_diagnostic.SA1200.severity = warning
+dotnet_diagnostic.RCS1036.severity = error
+```
+
+## Scoped Nested .editorconfig
+
+Add a nested `.editorconfig` when a subtree has a real local purpose, for example:
+
+- tighter rules in a core domain
+- relaxed rules for generated code
+- different test-project conventions
+- legacy-code containment during gradual cleanup
+
+Example:
+
+```ini
+# src/LegacyModule/.editorconfig
+[*.cs]
+dotnet_diagnostic.CA1502.severity = error
+```
+
+## CI Fit
+
+- `dotnet format` and .NET analyzers both read `.editorconfig`
+- repo-root `.editorconfig` should be versioned and treated as the default source of truth
+- keep MSBuild switches such as `EnableNETAnalyzers` and `AnalysisLevel` in project files or `Directory.Build.props`
+- keep the file lowercase as `.editorconfig`
+
+## Exceptional Use of .globalconfig
+
+Use `.globalconfig` only when you have a real reason, for example:
+
+- analyzer config distributed by package or SDK conventions
+- special project layouts where file-tree inheritance is not the right model
+
+That is not the default MCAF recommendation for normal .NET repos.
+
+## When Not To Use
+
+- when the repo is trying to store analyzer policy only in IDE profiles or ephemeral local settings
+
+## Sources
+
+- [EditorConfig home and file location rules](https://editorconfig.org/)
+- [EditorConfig formal specification](https://spec.editorconfig.org/)
+- [Configuration files for code analysis rules](https://learn.microsoft.com/en-us/dotnet/fundamentals/code-analysis/configuration-files)
+- [Code style rule options](https://learn.microsoft.com/en-us/dotnet/fundamentals/code-analysis/code-style-rule-options)

skills/mcaf-ci-cd/SKILL.md

@@ -0,0 +1,46 @@
+---
+name: mcaf-dotnet-archunitnet
+description: "Use the open-source free `ArchUnitNET` library for architecture rules in .NET tests. Use when a repo needs richer architecture assertions than lightweight fluent rule libraries usually provide."
+compatibility: "Requires a .NET test project; supports dedicated integrations for xUnit, xUnit v3, MSTest, TUnit, and others where available."
+---
+
+# MCAF: .NET ArchUnitNET
+
+## Trigger On
+
+- the repo uses or wants `ArchUnitNET`
+- architecture testing needs richer modeling than simple dependency checks
+
+## Do Not Use For
+
+- the lightest possible architecture rule checks
+
+## Inputs
+
+- the nearest `AGENTS.md`
+- target assemblies
+- architecture boundaries and naming conventions
+
+## Workflow
+
+1. Load the architecture once per test assembly where possible.
+2. Encode a small number of durable, high-value architecture rules first.
+3. Use the test-framework-specific integration package that matches the repo.
+
+## Deliver
+
+- architecture tests with richer domain and type modeling
+
+## Validate
+
+- architecture load cost is reasonable for the suite
+- rules are stable and tied to real boundaries
+
+## Load References
+
+- read `references/archunitnet.md` first
+
+## Example Requests
+
+- "Use ArchUnitNET for layered architecture tests."
+- "Set up ArchUnitNET with xUnit or MSTest."

skills/mcaf-dotnet-analyzer-config/SKILL.md

@@ -0,0 +1,55 @@
+# ArchUnitNET
+
+## Open/Free Status
+
+- open source
+- free to use
+
+## Install
+
+Core package:
+
+```bash
+dotnet add package TngTech.ArchUnitNET
+```
+
+Framework integration packages vary by test framework, for example:
+
+```bash
+dotnet add package TngTech.ArchUnitNET.xUnit
+dotnet add package TngTech.ArchUnitNET.xUnitV3
+dotnet add package TngTech.ArchUnitNET.MSTestV2
+dotnet add package TngTech.ArchUnitNET.TUnit
+```
+
+## Verify First
+
+Before adding packages, check whether the repo already references ArchUnitNET and which framework integration it uses:
+
+```bash
+rg -n "TngTech\\.ArchUnitNET" -g '*.csproj' .
+```
+
+## Common Usage
+
+Load the target assemblies once, then assert rules in tests.
+
+Good fit for:
+
+- layered architecture
+- namespace rules
+- dependency restrictions
+- domain boundary checks
+
+## CI Fit
+
+- runs as part of the normal test suite
+- richer than lightweight architecture-rule libraries, but also heavier
+
+## When Not To Use
+
+- when simple `NetArchTest` rules already cover the needed constraints
+
+## Sources
+
+- [ArchUnitNET](https://github.com/TNG/ArchUnitNET)