Align skills with Claude skill guide

KSemenenko · KSemenenko · commit a7185ae6e1c0 · 2026-03-08T15:02:15.000+01:00
diff --git a/skills/mcaf-adr-writing/SKILL.md b/skills/mcaf-adr-writing/SKILL.md
@@ -51,7 +51,7 @@ compatibility: "Requires repository write access; produces Markdown ADRs with Me
 
 ## Deliver
 
-- `docs/ADR/ADR-XXXX-<short-title>.md`
+- `docs/ADR/ADR-XXXX-short-title.md`
 - linked updates to architecture docs when the decision changes boundaries
 
 ## Validate
diff --git a/skills/mcaf-dotnet-analyzer-config/SKILL.md b/skills/mcaf-dotnet-analyzer-config/SKILL.md
@@ -58,7 +58,7 @@ If analyzer configuration is requested but not structured yet:
 2. Create or normalize one repo-root `.editorconfig` with `root = true`.
 3. Move rule severity into `.editorconfig` and keep bulk analyzer switches in project or MSBuild config.
 4. Add nested `.editorconfig` files only when a subtree really needs different scoped policy.
-5. Run `dotnet build <solution-or-project>` and return `status: configured` or `status: improved`.
+5. Run `dotnet build SOLUTION_OR_PROJECT` and return `status: configured` or `status: improved`.
 6. If the repo intentionally uses another documented analyzer-config ownership model, return `status: not_applicable`.
 
 ## Deliver
diff --git a/skills/mcaf-dotnet-archunitnet/SKILL.md b/skills/mcaf-dotnet-archunitnet/SKILL.md
@@ -46,11 +46,11 @@ If `ArchUnitNET` is not configured yet:
 1. Detect existing setup:
    - `rg -n "TngTech\\.ArchUnitNET" -g '*.csproj' .`
 2. Add packages to the architecture test project:
-   - `dotnet add <test-project>.csproj package TngTech.ArchUnitNET`
+   - `dotnet add TEST_PROJECT.csproj package TngTech.ArchUnitNET`
    - add one framework bridge package: `TngTech.ArchUnitNET.xUnit`, `TngTech.ArchUnitNET.xUnitV3`, `TngTech.ArchUnitNET.MSTestV2`, or `TngTech.ArchUnitNET.TUnit`
 3. Add at least one durable boundary rule test.
 4. Wire architecture tests into the standard `test` command in `AGENTS.md` and CI.
-5. Run `dotnet test <test-project>.csproj` and return `status: configured` or `status: improved`.
+5. Run `dotnet test TEST_PROJECT.csproj` and return `status: configured` or `status: improved`.
 6. If `NetArchTest` already covers the same boundary policy and no gap exists, return `status: not_applicable`.
 
 
diff --git a/skills/mcaf-dotnet-cloc/SKILL.md b/skills/mcaf-dotnet-cloc/SKILL.md
@@ -41,7 +41,7 @@ compatibility: "Requires a repository with .NET source files or a Git checkout;
 1. Choose the counting mode deliberately:
    - `--vcs=git` for repo-respecting counts
    - path-based counting for bounded folders
-   - `--git --diff <base> <head>` for change deltas
+   - `--git --diff BASE HEAD` for change deltas
 2. Prefer `.NET`-relevant views first:
    - C# footprint
    - test versus production footprint
diff --git a/skills/mcaf-dotnet-code-analysis/SKILL.md b/skills/mcaf-dotnet-code-analysis/SKILL.md
@@ -61,7 +61,7 @@ If first-party .NET code analysis is requested but not configured yet:
    - `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`.
+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
diff --git a/skills/mcaf-dotnet-complexity/SKILL.md b/skills/mcaf-dotnet-complexity/SKILL.md
@@ -57,7 +57,7 @@ If complexity thresholds are not configured yet:
 2. Add severity entries for `CA1502`, `CA1505`, `CA1506`, and `CA1501` in root `.editorconfig`.
 3. Add checked-in `CodeMetricsConfig.txt` and include it as `AdditionalFiles` in project props.
 4. Keep maintainability limits aligned with `AGENTS.md`.
-5. Run `dotnet build <solution-or-project>` and return `status: configured` or `status: improved`.
+5. Run `dotnet build SOLUTION_OR_PROJECT` and return `status: configured` or `status: improved`.
 6. If policy relies only on `AGENTS.md` limits with no analyzer gate by design, return `status: not_applicable`.
 
 
diff --git a/skills/mcaf-dotnet-coverlet/SKILL.md b/skills/mcaf-dotnet-coverlet/SKILL.md
@@ -55,13 +55,13 @@ If coverage is not configured yet:
    - `dotnet tool list --global`
    - `command -v coverlet`
 2. Install exactly one driver path:
-   - VSTest collector: `dotnet add <test-project>.csproj package coverlet.collector`
-   - MSBuild driver: `dotnet add <test-project>.csproj package coverlet.msbuild`
+   - VSTest collector: `dotnet add TEST_PROJECT.csproj package coverlet.collector`
+   - MSBuild driver: `dotnet add TEST_PROJECT.csproj package coverlet.msbuild`
    - Console tool: `dotnet new tool-manifest` (if missing) and `dotnet tool install coverlet.console`
 3. Record one concrete local and CI command in `AGENTS.md`:
-   - collector: `dotnet test <test-project>.csproj --collect:"XPlat Code Coverage"`
-   - msbuild: `dotnet test <test-project>.csproj /p:CollectCoverage=true /p:CoverletOutputFormat=cobertura`
-   - console: `dotnet tool run coverlet <test-assembly.dll> --target "dotnet" --targetargs "test <test-project>.csproj --no-build"`
+   - collector: `dotnet test TEST_PROJECT.csproj --collect:"XPlat Code Coverage"`
+   - msbuild: `dotnet test TEST_PROJECT.csproj /p:CollectCoverage=true /p:CoverletOutputFormat=cobertura`
+   - console: `dotnet tool run coverlet TEST_ASSEMBLY.dll --target "dotnet" --targetargs "test TEST_PROJECT.csproj --no-build"`
 4. Run the chosen command once and return `status: configured` or `status: improved`.
 5. If another coverage engine already owns coverage for this repo, return `status: not_applicable`.
 
diff --git a/skills/mcaf-dotnet-features/SKILL.md b/skills/mcaf-dotnet-features/SKILL.md
@@ -59,11 +59,11 @@ If the requested C# feature depends on SDK or language support the repo does not
 
 1. Detect current state:
    - `dotnet --list-sdks`
-   - `rg -n "<TargetFramework>|<LangVersion>|<TargetFrameworks>" -g '*.csproj' -g 'Directory.Build.*' .`
+   - `rg -n "TargetFramework|LangVersion|TargetFrameworks" -g '*.csproj' -g 'Directory.Build.*' .`
 2. Confirm whether the repo wants to stay on the current stable language level or intentionally upgrade.
 3. If the feature requires a newer supported SDK or target framework, upgrade the repo toolchain deliberately instead of relying on the local machine by accident.
 4. If the repo needs explicit `LangVersion`, record it in project or shared MSBuild config.
-5. Run `dotnet build <solution-or-project>` after the feature or toolchain change and return `status: configured` or `status: improved`.
+5. Run `dotnet build SOLUTION_OR_PROJECT` after the feature or toolchain change and return `status: configured` or `status: improved`.
 6. If the repo intentionally stays below the required language level, return `status: not_applicable`.
 
 ## Deliver
diff --git a/skills/mcaf-dotnet-features/references/csharp-modern-features.md b/skills/mcaf-dotnet-features/references/csharp-modern-features.md
@@ -8,13 +8,13 @@ Use this reference when modernizing C# code without breaking the repo's target f
 - `.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
+- do not set `LangVersion=latest` because it makes builds machine-dependent
+- use `LangVersion=preview` only when the repo intentionally opts into preview
 
 Useful checks:
 
 ```bash
-rg -n "<TargetFramework|<TargetFrameworks|<LangVersion" -g '*.csproj' -g 'Directory.Build.*' .
+rg -n "TargetFramework|TargetFrameworks|LangVersion" -g '*.csproj' -g 'Directory.Build.*' .
 ```
 
 If the repo's current language version is unclear, the compiler can reveal it:
diff --git a/skills/mcaf-dotnet-format/SKILL.md b/skills/mcaf-dotnet-format/SKILL.md
@@ -38,7 +38,7 @@ compatibility: "Requires a .NET SDK-based repository; respects the repo's `AGENT
 ## Workflow
 
 1. Prefer the SDK-provided `dotnet format` command instead of inventing custom format scripts.
-2. Start with verify mode in CI: `dotnet format <target> --verify-no-changes`.
+2. Start with verify mode in CI: `dotnet format TARGET --verify-no-changes`.
 3. Use narrower subcommands only when the repo needs them:
    - `whitespace`
    - `style`
@@ -56,7 +56,7 @@ If `dotnet format` is requested but not available yet:
 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`
+   - `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`.
 
diff --git a/skills/mcaf-dotnet-meziantou-analyzer/SKILL.md b/skills/mcaf-dotnet-meziantou-analyzer/SKILL.md
@@ -47,10 +47,10 @@ If `Meziantou.Analyzer` is not configured yet:
 1. Detect current state:
    - `rg -n "Meziantou\\.Analyzer" -g '*.csproj' .`
 2. Add the package to the intended scope (project-level or shared props strategy):
-   - `dotnet add <project>.csproj package Meziantou.Analyzer`
+   - `dotnet add PROJECT.csproj package Meziantou.Analyzer`
 3. Set severity in root `.editorconfig` for the enabled `MAxxxx` rules.
 4. Keep overlap with SDK analyzers and Roslynator explicit to avoid duplicate noise.
-5. Run `dotnet build <solution-or-project>` and return `status: configured` or `status: improved`.
+5. Run `dotnet build SOLUTION_OR_PROJECT` and return `status: configured` or `status: improved`.
 6. If the repo intentionally keeps a smaller analyzer surface, return `status: not_applicable`.
 
 
diff --git a/skills/mcaf-dotnet-mstest/SKILL.md b/skills/mcaf-dotnet-mstest/SKILL.md
@@ -42,10 +42,10 @@ compatibility: "Requires a .NET solution or project with MSTest packages; respec
    - `MSTest.Sdk` project SDK
    - `MSTest` meta-package
    - legacy package set with explicit `Microsoft.NET.Test.Sdk`
-2. Read the repo's real `test` command from `AGENTS.md`. If the repo has no explicit command yet, start with `dotnet test <project-or-solution>`.
+2. Read the repo's real `test` command from `AGENTS.md`. If the repo has no explicit command yet, start with `dotnet test PROJECT_OR_SOLUTION`.
 3. Keep the runner model consistent:
    - `MSTest.Sdk` defaults to the MSTest runner on Microsoft.Testing.Platform
-   - VSTest is opt-in with `<UseVSTest>true</UseVSTest>` or legacy package choices
+   - VSTest is opt-in with `UseVSTest=true` or legacy package choices
    - do not pass VSTest-only switches or assume legacy `.runsettings` behavior on Microsoft.Testing.Platform jobs
 4. Prefer `[DataRow]` or `DynamicData` for stable data-driven coverage. Keep test lifecycle hooks minimal and deterministic.
 5. Keep MSTest analyzers enabled and fix findings instead of muting them casually.
@@ -59,9 +59,9 @@ If MSTest is requested but not configured:
    - `rg -n "MSTest\\.Sdk|PackageReference Include=\"MSTest\"|xunit|TUnit|UseVSTest|TestingPlatformDotnetTestSupport" -g '*.csproj' .`
 2. If the repo currently uses `xUnit` or `TUnit`, do not auto-migrate. Return `status: not_applicable` unless migration is explicitly requested.
 3. For explicit MSTest adoption, add package(s) to target test project:
-   - `dotnet add <test-project>.csproj package MSTest`
+   - `dotnet add TEST_PROJECT.csproj package MSTest`
 4. Document runner model (`MSTest.Sdk` default MTP vs `UseVSTest`) in `AGENTS.md`.
-5. Run `dotnet test <test-project>.csproj` and return `status: configured` or `status: improved`.
+5. Run `dotnet test TEST_PROJECT.csproj` and return `status: configured` or `status: improved`.
 
 
 ## Deliver
diff --git a/skills/mcaf-dotnet-mstest/references/mstest.md b/skills/mcaf-dotnet-mstest/references/mstest.md
@@ -24,7 +24,7 @@ dotnet add package MSTest
 Before adding packages, check which MSTest model the repo already uses:
 
 ```bash
-rg -n "MSTest\\.Sdk|<UseVSTest>|PackageReference Include=\"MSTest\"|Microsoft\\.NET\\.Test\\.Sdk|TestingPlatformDotnetTestSupport" -g '*.csproj' .
+rg -n "MSTest\\.Sdk|UseVSTest|PackageReference Include=\"MSTest\"|Microsoft\\.NET\\.Test\\.Sdk|TestingPlatformDotnetTestSupport" -g '*.csproj' .
 ```
 
 Use this reference when the repository already chose MSTest and you need framework-specific commands, package checks, or CI guardrails.
@@ -34,13 +34,13 @@ Use this reference when the repository already chose MSTest and you need framewo
 Use the project file as the source of truth:
 
 ```bash
-rg -n "MSTest\\.Sdk|<UseVSTest>|PackageReference Include=\"MSTest\"|Microsoft\\.NET\\.Test\\.Sdk|TestingPlatformDotnetTestSupport" -g '*.csproj' .
+rg -n "MSTest\\.Sdk|UseVSTest|PackageReference Include=\"MSTest\"|Microsoft\\.NET\\.Test\\.Sdk|TestingPlatformDotnetTestSupport" -g '*.csproj' .
 ```
 
 Typical markers:
 
 - `MSTest.Sdk`: modern MSTest project SDK, Microsoft.Testing.Platform by default
-- `<UseVSTest>true</UseVSTest>`: explicit VSTest fallback
+- `UseVSTest=true`: explicit VSTest fallback
 - `MSTest` meta-package: framework, adapter, analyzers, and runner-related packages packaged together
 
 ## Common Commands
diff --git a/skills/mcaf-dotnet-netarchtest/SKILL.md b/skills/mcaf-dotnet-netarchtest/SKILL.md
@@ -49,10 +49,10 @@ If `NetArchTest.Rules` is not configured yet:
 1. Detect existing setup:
    - `rg -n "NetArchTest\\.Rules" -g '*.csproj' .`
 2. Add the package to the architecture test project:
-   - `dotnet add <test-project>.csproj package NetArchTest.Rules`
+   - `dotnet add TEST_PROJECT.csproj package NetArchTest.Rules`
 3. Add at least one executable boundary rule test.
 4. Wire architecture tests into the standard `test` command in `AGENTS.md` and CI.
-5. Run `dotnet test <test-project>.csproj` and return `status: configured` or `status: improved`.
+5. Run `dotnet test TEST_PROJECT.csproj` and return `status: configured` or `status: improved`.
 6. If richer modeling is required and `ArchUnitNET` is chosen as the standard, return `status: not_applicable`.
 
 
diff --git a/skills/mcaf-dotnet-profiling/SKILL.md b/skills/mcaf-dotnet-profiling/SKILL.md
@@ -74,9 +74,9 @@ If official .NET profiling tools are not available yet:
    - `dotnet-trace --version`
    - `dotnet-gcdump --version`
 4. Record exact profiling commands in `AGENTS.md`, for example:
-   - `dotnet-counters monitor --process-id <pid> --counters System.Runtime`
-   - `dotnet-trace collect --process-id <pid> --profile dotnet-common,dotnet-sampled-thread-time -o trace.nettrace`
-   - `dotnet-gcdump collect --process-id <pid> --output heap.gcdump`
+   - `dotnet-counters monitor --process-id PID --counters System.Runtime`
+   - `dotnet-trace collect --process-id PID --profile dotnet-common,dotnet-sampled-thread-time -o trace.nettrace`
+   - `dotnet-gcdump collect --process-id PID --output heap.gcdump`
 5. Run one bounded command and return `status: configured` or `status: improved`.
 6. If the repo intentionally standardizes on another profiling stack and does not want these tools, return `status: not_applicable`.
 
diff --git a/skills/mcaf-dotnet-profiling/references/profiling.md b/skills/mcaf-dotnet-profiling/references/profiling.md
@@ -65,13 +65,13 @@ dotnet-counters ps
 Monitor runtime counters:
 
 ```bash
-dotnet-counters monitor --process-id <pid> --counters System.Runtime
+dotnet-counters monitor --process-id PID --counters System.Runtime
 ```
 
 Export counters for later comparison:
 
 ```bash
-dotnet-counters collect --process-id <pid> --counters System.Runtime --format json -o counters.json
+dotnet-counters collect --process-id PID --counters System.Runtime --format json -o counters.json
 ```
 
 For startup diagnostics:
@@ -93,13 +93,13 @@ dotnet-trace ps
 Capture a focused general-purpose trace:
 
 ```bash
-dotnet-trace collect --process-id <pid> --profile dotnet-common,dotnet-sampled-thread-time -o trace.nettrace
+dotnet-trace collect --process-id PID --profile dotnet-common,dotnet-sampled-thread-time -o trace.nettrace
 ```
 
 Capture GC-heavy detail:
 
 ```bash
-dotnet-trace collect --process-id <pid> --profile gc-verbose -o gc.nettrace
+dotnet-trace collect --process-id PID --profile gc-verbose -o gc.nettrace
 ```
 
 Trace startup directly:
@@ -143,7 +143,7 @@ dotnet-gcdump ps
 Capture a heap snapshot:
 
 ```bash
-dotnet-gcdump collect --process-id <pid> --output heap.gcdump
+dotnet-gcdump collect --process-id PID --output heap.gcdump
 ```
 
 Get a heap summary report:
diff --git a/skills/mcaf-dotnet-roslynator/SKILL.md b/skills/mcaf-dotnet-roslynator/SKILL.md
@@ -62,13 +62,13 @@ If `Roslynator` is not configured yet:
    - `dotnet tool list --global`
    - `command -v roslynator`
 2. Choose the install path deliberately:
-   - analyzer package: `dotnet add <project>.csproj package Roslynator.Analyzers`
+   - analyzer package: `dotnet add PROJECT.csproj package Roslynator.Analyzers`
    - optional CLI: `dotnet new tool-manifest` (if missing) and `dotnet tool install roslynator.dotnet.cli`
 3. Configure ownership in root `.editorconfig` so Roslynator does not fight SDK analyzers, StyleCop, or Meziantou.
 4. If the CLI is adopted, add exact commands in `AGENTS.md` and CI, such as:
-   - `dotnet tool run roslynator analyze <solution-or-project>`
-   - `dotnet tool run roslynator fix <solution-or-project>`
-5. Run `dotnet build <solution-or-project>` and the selected Roslynator command, then return `status: configured` or `status: improved`.
+   - `dotnet tool run roslynator analyze SOLUTION_OR_PROJECT`
+   - `dotnet tool run roslynator fix SOLUTION_OR_PROJECT`
+5. Run `dotnet build SOLUTION_OR_PROJECT` and the selected Roslynator command, then return `status: configured` or `status: improved`.
 6. If the repo wants only the current analyzer baseline and no Roslynator-specific CLI workflow, return `status: not_applicable`.
 
 ## Deliver
diff --git a/skills/mcaf-dotnet-roslynator/references/roslynator.md b/skills/mcaf-dotnet-roslynator/references/roslynator.md
@@ -61,12 +61,12 @@ roslynator analyze MySolution.sln --severity-level warning
 
 Useful scoping flags from the CLI:
 
-- `--projects <name>`
-- `--ignored-projects <name>`
-- `--include <glob>`
-- `--exclude <glob>`
-- `--verbosity <level>`
-- `--properties <NAME=VALUE>`
+- `--projects PROJECT_NAME`
+- `--ignored-projects PROJECT_NAME`
+- `--include GLOB`
+- `--exclude GLOB`
+- `--verbosity LEVEL`
+- `--properties NAME=VALUE`
 
 ## CI Fit
 
diff --git a/skills/mcaf-dotnet-stylecop-analyzers/SKILL.md b/skills/mcaf-dotnet-stylecop-analyzers/SKILL.md
@@ -50,10 +50,10 @@ If `StyleCop.Analyzers` is not configured yet:
 1. Detect current state:
    - `rg -n "StyleCop\\.Analyzers|stylecop\\.json" -g '*.csproj' -g 'stylecop.json' .`
 2. Add package to the intended scope:
-   - `dotnet add <project>.csproj package StyleCop.Analyzers`
+   - `dotnet add PROJECT.csproj package StyleCop.Analyzers`
 3. Keep severity in root `.editorconfig` and use `stylecop.json` only for StyleCop-specific behavior.
 4. Prevent overlap with existing analyzer packs by defining ownership.
-5. Run `dotnet build <solution-or-project>` and return `status: configured` or `status: improved`.
+5. Run `dotnet build SOLUTION_OR_PROJECT` and return `status: configured` or `status: improved`.
 6. If the repo intentionally uses SDK analyzers only, return `status: not_applicable`.
 
 
diff --git a/skills/mcaf-dotnet-tunit/SKILL.md b/skills/mcaf-dotnet-tunit/SKILL.md
@@ -39,7 +39,7 @@ compatibility: "Requires a .NET solution or project with TUnit packages; respect
 ## Workflow
 
 1. Confirm the project really uses TUnit and not a different MTP-based framework.
-2. Read the repo's real `test` command from `AGENTS.md`. If the repo has no explicit command yet, start with `dotnet test <project-or-solution>`.
+2. Read the repo's real `test` command from `AGENTS.md`. If the repo has no explicit command yet, start with `dotnet test PROJECT_OR_SOLUTION`.
 3. Keep the TUnit execution model intact:
    - tests are source-generated at build time
    - tests run in parallel by default
@@ -55,13 +55,13 @@ 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`
+   - `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
+   - 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`.
+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
diff --git a/skills/mcaf-dotnet-xunit/SKILL.md b/skills/mcaf-dotnet-xunit/SKILL.md
diff --git a/skills/mcaf-dotnet/references/task-flow.md b/skills/mcaf-dotnet/references/task-flow.md
diff --git a/skills/mcaf-feature-spec/SKILL.md b/skills/mcaf-feature-spec/SKILL.md
diff --git a/skills/mcaf-human-review-planning/SKILL.md b/skills/mcaf-human-review-planning/SKILL.md
diff --git a/skills/mcaf-human-review-planning/references/review-plan-format.md b/skills/mcaf-human-review-planning/references/review-plan-format.md
diff --git a/skills/mcaf-source-control/references/naming-branches.md b/skills/mcaf-source-control/references/naming-branches.md
