Add .NET orchestration and modern feature skills

Author: KSemenenko

README.md

@@ -108,8 +108,9 @@ The public skill catalog lives on the Skills page:
 - [https://mcaf.managed-code.com/skills.html](https://mcaf.managed-code.com/skills.html)
 
 Platform-specific bundles can stay small and still be explicit.
-For example, a typical .NET repo baseline can install `mcaf-solution-governance`, `mcaf-testing`, exactly one of `mcaf-dotnet-xunit`, `mcaf-dotnet-tunit`, or `mcaf-dotnet-mstest`, plus `mcaf-dotnet-quality-ci`, `mcaf-dotnet-complexity`, `mcaf-solid-maintainability`, and `mcaf-ci-cd`.
-In that setup, the repo-root lowercase `.editorconfig` is the default source of truth for formatting and analyzer severity, while `AGENTS.md` records the exact `dotnet build`, `dotnet test`, `dotnet format`, `analyze`, and coverage commands. Nested `.editorconfig` files are allowed when they serve a clear subtree-specific purpose, such as stricter domain rules, generated-code handling, test-specific conventions, or legacy-code containment.
+For example, a typical .NET repo baseline can install `mcaf-dotnet` as the entry skill, `mcaf-dotnet-features`, `mcaf-solution-governance`, `mcaf-testing`, exactly one of `mcaf-dotnet-xunit`, `mcaf-dotnet-tunit`, or `mcaf-dotnet-mstest`, plus `mcaf-dotnet-quality-ci`, `mcaf-dotnet-complexity`, `mcaf-solid-maintainability`, `mcaf-architecture-overview`, and `mcaf-ci-cd`.
+In that setup, `mcaf-dotnet` knows when to open the more specific .NET skills, the repo-root lowercase `.editorconfig` is the default source of truth for formatting and analyzer severity, and `AGENTS.md` records the exact `dotnet build`, `dotnet test`, `dotnet format`, `analyze`, and coverage commands. Nested `.editorconfig` files are allowed when they serve a clear subtree-specific purpose, such as stricter domain rules, generated-code handling, test-specific conventions, or legacy-code containment.
+For .NET code changes, the task is not done when tests are green if the repo also configured formatters, analyzers, coverage, architecture tests, or security gates. Agents should run the repo-defined post-change quality pass before completion.
 If the repo standardizes on concrete tools, install the matching tool skills as well. Typical open or free .NET additions include `mcaf-dotnet-format`, `mcaf-dotnet-code-analysis`, `mcaf-dotnet-analyzer-config`, `mcaf-dotnet-stylecop-analyzers`, `mcaf-dotnet-roslynator`, `mcaf-dotnet-meziantou-analyzer`, `mcaf-dotnet-coverlet`, `mcaf-dotnet-reportgenerator`, `mcaf-dotnet-stryker`, `mcaf-dotnet-netarchtest`, `mcaf-dotnet-archunitnet`, `mcaf-dotnet-semgrep`, and `mcaf-dotnet-csharpier`. `mcaf-dotnet-codeql` stays available, but should be chosen only when its hosting and licensing model fits the repository.
 
 ### 2.5 Context Rules

TUTORIAL.md

@@ -81,23 +81,35 @@ This keeps install deterministic without requiring manifests or archives.
 
 For a .NET repository, the usual baseline is:
 
+- `mcaf-dotnet`
+- `mcaf-dotnet-features`
 - `mcaf-solution-governance`
 - `mcaf-testing`
 - exactly one of:
   - `mcaf-dotnet-xunit`
   - `mcaf-dotnet-tunit`
   - `mcaf-dotnet-mstest`
 - `mcaf-dotnet-quality-ci`
+- `mcaf-dotnet-complexity`
 - `mcaf-solid-maintainability`
+- `mcaf-architecture-overview`
 - `mcaf-ci-cd`
 
 For .NET repositories, also make these repo-native artifacts explicit:
 
 - a repo-root `.editorconfig` as the analyzer and formatting source of truth
 - project-specific nested `.editorconfig` files when a subtree has a clear different purpose or policy
 - `Directory.Build.props` or project files for bulk analyzer and runner settings
+- target `TFM` and explicit `LangVersion` only when the repo intentionally differs from the SDK default
 - whether the solution uses `VSTest` or `Microsoft.Testing.Platform`
 
+The intended flow is:
+
+- `mcaf-dotnet` is the entry skill for normal C# or .NET work
+- `mcaf-dotnet-features` decides which modern language features are safe to use, especially for C# 13 on `.NET 9` and C# 14 on `.NET 10`
+- the framework-specific test skill handles xUnit, TUnit, or MSTest mechanics
+- after code changes, agents run the repo-defined quality pass: format, build, analyze, tests, coverage, and any configured extra gates
+
 Add tool-specific .NET skills only when the repo standardizes on them:
 
 - `mcaf-dotnet-format`

docs/templates/AGENTS.md

@@ -94,9 +94,15 @@ Do not paste the whole framework catalog here.
 
 If the stack is `.NET`, this usually includes:
 
+- `mcaf-dotnet`
+- `mcaf-dotnet-features`
 - `mcaf-testing`
 - exactly one of `mcaf-dotnet-xunit`, `mcaf-dotnet-tunit`, or `mcaf-dotnet-mstest`
 - `mcaf-dotnet-quality-ci`
+- `mcaf-dotnet-complexity`
+- `mcaf-solid-maintainability`
+- `mcaf-architecture-overview` if the repo keeps a maintained architecture map
+- `mcaf-ci-cd`
 
 ## Rules to Follow (Mandatory)
 
@@ -113,6 +119,7 @@ If the stack is `.NET`, also document:
 - whether tests run on `VSTest` or `Microsoft.Testing.Platform`
 - whether `format` is `dotnet format --verify-no-changes` or a checked-in wrapper over it
 - whether coverage uses a VSTest collector, `coverlet.MTP`, or an MSTest SDK extension
+- explicit `LangVersion` only when the repo intentionally differs from the SDK default
 
 ### Project AGENTS Policy
 
@@ -194,6 +201,7 @@ Local `AGENTS.md` files may tighten these values, but they must not loosen them
 - Repository or module coverage must not decrease without an explicit written exception.
 - Coverage is for finding gaps, not gaming a number. Coverage numbers do not replace scenario coverage or user-flow verification.
 - If the stack is `.NET`, document the active framework and runner model explicitly so agents do not mix VSTest and Microsoft.Testing.Platform assumptions.
+- If the stack is `.NET`, after changing production code run the repo-defined quality pass: format, build, analyze, focused tests, broader tests, coverage, and any configured extra gates such as architecture, security, or mutation checks.
 
 ### Code and Design
 

skills/mcaf-dotnet-features/SKILL.md

@@ -0,0 +1,65 @@
+---
+name: mcaf-dotnet-features
+description: "Write modern, version-aware C# for .NET repositories. Use when choosing language features across C# versions, especially C# 13 and C# 14, while staying compatible with the repo's target framework and `LangVersion`."
+compatibility: "Requires a C# or .NET repository; respects explicit `LangVersion` and target framework settings."
+---
+
+# MCAF: .NET Features
+
+## Trigger On
+
+- the repo wants more modern idiomatic C# code
+- a change depends on language-version compatibility
+- the team is upgrading or reviewing C# feature usage across versions
+- you need to know whether a C# 13 or C# 14 feature is safe to use
+
+## Do Not Use For
+
+- non-C# .NET languages such as F# or VB
+- analyzer-only or formatter-only setup with no language feature choice
+
+## Inputs
+
+- target `TFM` or `TFMs`
+- explicit `LangVersion`, if any
+- current SDK version
+- team style rules in `.editorconfig` and `AGENTS.md`
+
+## Workflow
+
+1. Detect the real language ceiling from the repo's target framework and explicit `LangVersion`.
+2. Prefer stable features that the current repo actually supports.
+3. Use modern syntax when it reduces ceremony, improves correctness, or makes invariants clearer.
+4. Do not mass-rewrite a codebase into newer syntax unless the repo wants that churn.
+5. Treat preview features as opt-in only. Never assume preview because the current machine has a newer SDK.
+6. Pay special attention to C# 13 and C# 14:
+   - C# 13 is the stable language for `.NET 9`
+   - C# 14 is the stable language for `.NET 10`
+7. When feature selection changes architecture, style rules, or generated-code patterns, coordinate with:
+   - `mcaf-dotnet`
+   - `mcaf-dotnet-analyzer-config`
+   - `mcaf-solid-maintainability`
+8. After feature-driven refactors, run the repo's .NET quality pass through `mcaf-dotnet`.
+
+## Deliver
+
+- modern C# code that fits the repo's real language version
+- fewer obsolete patterns when a newer stable feature is clearer
+- no accidental preview or unsupported-language drift
+
+## Validate
+
+- the chosen syntax is supported by the repo's `TFM` and `LangVersion`
+- the feature improves clarity, correctness, or maintainability
+- preview-only features are used only when the repo explicitly opted in
+- style and analyzer rules still agree with the new syntax
+
+## Load References
+
+- read `references/csharp-modern-features.md` first
+
+## Example Requests
+
+- "Make this C# code more modern."
+- "Which features can we use on .NET 9?"
+- "Review this repo for C# 13 or C# 14 opportunities."

skills/mcaf-dotnet-features/references/csharp-modern-features.md

@@ -0,0 +1,198 @@
+# Modern C# Features For .NET Repositories
+
+Use this reference when modernizing C# code without breaking the repo's target framework, SDK, or language-version expectations.
+
+## First Rule: Detect The Real Language Ceiling
+
+- the default C# version follows the target framework in modern SDK-style projects
+- `.NET 9` maps to `C# 13`
+- `.NET 10` maps to `C# 14`
+- newer language versions than the target framework supports are not supported
+- do not set `<LangVersion>latest</LangVersion>` because it makes builds machine-dependent
+- use `<LangVersion>preview</LangVersion>` only when the repo intentionally opts into preview
+
+Useful checks:
+
+```bash
+rg -n "<TargetFramework|<TargetFrameworks|<LangVersion" -g '*.csproj' -g 'Directory.Build.*' .
+```
+
+If the repo's current language version is unclear, the compiler can reveal it:
+
+```csharp
+#error version
+```
+
+As of March 8, 2026:
+
+- `C# 14` is the latest stable version
+- `C# 15` exists in preview, but should not be a default choice for production repo guidance
+
+## Practical Adoption Rules
+
+- prefer stable features that remove ceremony, improve correctness, or improve performance without obscuring intent
+- do not rewrite entire codebases just to use new syntax
+- modernize opportunistically when touching the code anyway
+- coordinate feature adoption with `.editorconfig`, analyzers, and architecture rules
+
+## Version Guide
+
+### C# 8
+
+Typical pairing: `.NET Core 3.x`
+
+Key features:
+
+- readonly members
+- default interface members
+- switch expressions
+- property patterns
+- tuple patterns
+- positional patterns
+- using declarations
+- static local functions
+- disposable `ref struct`
+- nullable reference types
+- asynchronous streams
+- indices and ranges
+- null-coalescing assignment
+- unmanaged constructed types
+- stackalloc in nested expressions
+- improved interpolated verbatim strings
+
+### C# 9
+
+Typical pairing: `.NET 5`
+
+Key features:
+
+- records
+- init-only setters
+- top-level statements
+- relational patterns
+- logical patterns
+- native-sized integers
+- function pointers
+- module initializers
+- target-typed `new`
+- static anonymous functions
+- target-typed conditional expressions
+- covariant return types
+- extension `GetEnumerator` support in `foreach`
+- lambda discard parameters
+- attributes on local functions
+
+### C# 10
+
+Typical pairing: `.NET 6`
+
+Key features:
+
+- record structs
+- struct initialization improvements
+- interpolated string handlers
+- `global using`
+- file-scoped namespaces
+- extended property patterns
+- lambda natural type
+- explicit lambda return types
+- attributes on lambda expressions
+- `const` interpolated strings
+- `sealed` `ToString` in records
+- more accurate definite assignment and null-state analysis
+- mixed assignment and declaration in deconstruction
+- `AsyncMethodBuilder` on methods
+- `CallerArgumentExpression`
+- new `#line` format
+
+### C# 11
+
+Typical pairing: `.NET 7`
+
+Key features:
+
+- raw string literals
+- generic math support
+- generic attributes
+- UTF-8 string literals
+- newlines inside interpolation expressions
+- list patterns
+- file-local types
+- required members
+- auto-default structs
+- matching `Span<char>` against a constant string
+- extended `nameof` scope
+- `nint` and `nuint` aliases
+- `ref` fields and `scoped ref`
+- improved method-group conversion to delegate
+- warning wave 7
+
+### C# 12
+
+Typical pairing: `.NET 8`
+
+Key features:
+
+- primary constructors
+- collection expressions
+- inline arrays
+- optional parameters in lambda expressions
+- `ref readonly` parameters
+- alias any type
+- `Experimental` attribute
+- interceptors as a preview feature
+
+### C# 13
+
+Released November 2024. Stable on `.NET 9`.
+
+Key features:
+
+- `params` collections
+- new `lock` type and semantics with `System.Threading.Lock`
+- `\e` escape sequence
+- method-group natural type improvements
+- implicit indexer access in object initializers
+- `ref` locals and `unsafe` contexts in iterators and async methods
+- `ref struct` can implement interfaces
+- `allows ref struct` anti-constraint for generics
+- partial properties and partial indexers
+- overload resolution priority
+- `field` contextual keyword as a preview feature in C# 13-era tooling
+
+Practical use:
+
+- use `System.Threading.Lock` when the repo is on `.NET 9` and wants the newer synchronization model
+- use `params ReadOnlySpan<T>` or related collection forms in performance-sensitive APIs
+- use partial properties or indexers only where partial-type generation patterns already exist
+- do not assume `field` is safe unless the repo explicitly opted into preview behavior
+
+### C# 14
+
+Released November 2025. Stable on `.NET 10`.
+
+Key features:
+
+- extension members
+- null-conditional assignment
+- `nameof` with unbound generic types such as `nameof(List<>)`
+- more implicit conversions for `Span<T>` and `ReadOnlySpan<T>`
+- modifiers on simple lambda parameters
+- field-backed properties via `field`
+- partial events and partial constructors
+- user-defined compound assignment operators
+- file-based app preprocessor directives
+
+Practical use:
+
+- use null-conditional assignment to remove boilerplate null guards when side effects are clear
+- use field-backed properties when you need simple validation in an otherwise auto-property style
+- use extension members when the repo wants richer extension APIs, not for cosmetic rewrites
+- use span-related improvements in performance-sensitive code paths, not as blanket style churn
+
+## Sources
+
+- [Configure C# language version](https://learn.microsoft.com/dotnet/csharp/language-reference/configure-language-version)
+- [The history of C#](https://learn.microsoft.com/dotnet/csharp/whats-new/csharp-version-history)
+- [What's new in C# 13](https://learn.microsoft.com/dotnet/csharp/whats-new/csharp-13)
+- [What's new in C# 14](https://learn.microsoft.com/dotnet/csharp/whats-new/csharp-14)

skills/mcaf-dotnet-quality-ci/SKILL.md

@@ -53,20 +53,29 @@ compatibility: "Requires a .NET solution or project; may update `AGENTS.md`, CI
    - which command analyzes
    - which command measures coverage
    - which runner model the tests use
-6. Route tool-specific setup through dedicated skills where possible:
+6. After any .NET code change, the repo's quality pass must be runnable by agents:
+   - format
+   - build
+   - analyze
+   - focused tests
+   - broader tests
+   - coverage and report generation when configured
+   - extra configured gates only when the repo actually enabled them
+7. Route tool-specific setup through dedicated skills where possible:
    - `mcaf-dotnet-format`
    - `mcaf-dotnet-code-analysis`
    - `mcaf-dotnet-analyzer-config`
    - analyzer-pack skills such as `mcaf-dotnet-stylecop-analyzers`, `mcaf-dotnet-roslynator`, and `mcaf-dotnet-meziantou-analyzer`
    - coverage/reporting skills such as `mcaf-dotnet-coverlet` and `mcaf-dotnet-reportgenerator`
    - architecture/security skills such as `mcaf-dotnet-netarchtest`, `mcaf-dotnet-archunitnet`, `mcaf-dotnet-codeql`, and `mcaf-dotnet-semgrep`
-7. Avoid overlapping tools with conflicting ownership. If you add an opinionated formatter, define whether it replaces or complements `dotnet format`.
+8. Avoid overlapping tools with conflicting ownership. If you add an opinionated formatter, define whether it replaces or complements `dotnet format`.
 
 ## Deliver
 
 - a documented .NET quality baseline
 - CI commands that are explicit and reproducible
 - analyzer and coverage choices that match the repo's runner model
+- a documented post-change quality pass for agents and CI
 - tool selection that stays open-source and free by default, with caveats called out explicitly
 
 ## Validate
@@ -75,6 +84,7 @@ compatibility: "Requires a .NET solution or project; may update `AGENTS.md`, CI
 - formatting, analyzer, and coverage commands are runner-compatible
 - added tools cover distinct gaps instead of duplicating each other
 - complexity and architecture policy are explicit, not implied
+- .NET code changes are expected to pass more than tests alone when quality gates are configured
 - any licensing or hosting caveat is documented before the tool becomes a default gate
 
 ## Load References