Clarify dotnet bootstrap guidance across skills

Author: KSemenenko

skills/mcaf-dotnet-code-analysis/SKILL.md

@@ -47,6 +47,23 @@ compatibility: "Requires a .NET SDK-based repository; respects the repo's `AGENT
 4. Use `dotnet build` as the analyzer execution gate in CI.
 5. Add third-party analyzers only for real gaps that first-party rules do not cover.
 
+## Bootstrap When Missing
+
+If first-party .NET code analysis is requested but not configured yet:
+
+1. Detect current state:
+   - `dotnet --info`
+   - `rg -n "EnableNETAnalyzers|AnalysisLevel|AnalysisMode|TreatWarningsAsErrors" -g '*.csproj' -g 'Directory.Build.*' .`
+2. Treat SDK analyzers as built-in functionality, not as a separate third-party install path.
+3. Enable the needed properties in the solution's MSBuild config, typically in `Directory.Build.props` or the target project file:
+   - `EnableNETAnalyzers`
+   - `AnalysisLevel`
+   - `AnalysisMode` when needed
+   - warning policy such as `TreatWarningsAsErrors`
+4. Keep rule-level severity in the repo-root `.editorconfig`.
+5. Run `dotnet build <solution-or-project>` and return `status: configured` or `status: improved`.
+6. If the repo intentionally defers analyzer policy to another documented build layer, return `status: not_applicable`.
+
 ## Deliver
 
 - first-party analyzer policy that is explicit and reviewable

skills/mcaf-dotnet-format/SKILL.md

@@ -46,6 +46,20 @@ compatibility: "Requires a .NET SDK-based repository; respects the repo's `AGENT
 4. Keep `.editorconfig` as the source of truth for style preferences.
 5. If the repo also uses `CSharpier`, document which tool owns which file types or rules.
 
+## Bootstrap When Missing
+
+If `dotnet format` is requested but not available yet:
+
+1. Detect current state:
+   - `dotnet --info`
+   - `dotnet format --version`
+2. Treat `dotnet format` as SDK-provided, not as a separate repo-local tool by default.
+3. If the command is missing, install or upgrade to a supported .NET SDK, then recheck `dotnet format --version`.
+4. Add explicit local and CI commands to `AGENTS.md`, usually:
+   - `dotnet format <target> --verify-no-changes`
+5. Run the chosen command once and return `status: configured` or `status: improved`.
+6. If the repo intentionally uses only `CSharpier` for formatting ownership, return `status: not_applicable`.
+
 ## Deliver
 
 - explicit `dotnet format` commands for local and CI runs

skills/mcaf-dotnet-tunit/SKILL.md

@@ -48,6 +48,22 @@ compatibility: "Requires a .NET solution or project with TUnit packages; respect
 5. Run the narrowest useful scope first. If the repo hasn't documented filter switches for TUnit yet, prefer project-level focused runs over guessed runner arguments.
 6. Use `[Test]`, `[Arguments]`, hooks, and dependencies only when they make the scenario clearer, not because the framework allows it.
 
+## Bootstrap When Missing
+
+If `TUnit` is requested but not configured yet:
+
+1. Detect current state:
+   - `rg -n "TUnit|Microsoft\\.Testing\\.Platform" -g '*.csproj' -g 'Directory.Build.*' .`
+2. Add the minimal package set to the test project:
+   - `dotnet add <test-project>.csproj package TUnit`
+   - `dotnet add <test-project>.csproj package Microsoft.NET.Test.Sdk`
+3. Keep the runner model explicit in `AGENTS.md` and CI:
+   - record that the repo uses Microsoft.Testing.Platform-compatible execution for this test project
+   - record the exact `dotnet test <test-project>.csproj` command the repo will use
+4. Add one small executable test using `[Test]`.
+5. Run `dotnet test <test-project>.csproj` and return `status: configured` or `status: improved`.
+6. If the repo intentionally standardizes on xUnit or MSTest, return `status: not_applicable` unless migration is explicitly requested.
+
 ## Deliver
 
 - TUnit tests that respect source generation and parallel execution