Tooling style workflow

.NET Tooling And Style Workflow

Purpose

Keep .NET formatting and analyzer behavior explicit.

The practical job is to respect existing repo conventions, use .editorconfig and dotnet format where they fit, keep analyzers and warnings understandable, and make local validation match CI.

When To Use

• Use this skill when adding or changing .editorconfig, analyzers, or warnings-as-errors.
• Use this skill when dotnet format is part of local or CI validation.
• Use this skill when style drift causes noisy diffs.
• Use this skill when F# and C# projects need one documented validation story.

Source Check

Use repo-local files, checked-out dependency sources, Dash MCP or Dash HTTP for installed docsets, and then official project documentation when Dash/local coverage is missing or stale:

• dotnet format documentation
• .NET code analysis overview
• EditorConfig settings for .NET
• .NET local tools

Inspection Workflow

1. Inspect tooling files:

   rg --files -g '.editorconfig' -g 'Directory.Build.props' -g 'Directory.Packages.props' -g 'dotnet-tools.json' -g '*.fsproj' -g '*.csproj'
   

2. Read existing repo guidance and CI.
3. Identify what is already enforced:
   • dotnet format
   • analyzers
   • warnings-as-errors
   • local tools
   • custom scripts
4. Decide the smallest alignment:
   • document existing commands
   • add missing .editorconfig
   • add format verification
   • adjust analyzers
   • add local tool restore
5. Run validation.

dotnet format Guidance

dotnet format formats a project or solution according to .editorconfig settings when present.

Use verification mode for CI or pre-commit checks:

dotnet format --verify-no-changes

Use normal mode only when the user asked for formatting or when the change is explicitly a formatting pass:

dotnet format

Keep formatting-only sweeps separate from behavior changes when practical.

Analyzer Guidance

Respect existing analyzer settings first.

When adding analyzer rules:

• explain what bug class or style drift the rule catches
• start conservative
• avoid turning every suggestion into a blocking error at once
• keep suppressions narrow and documented

For F#, check whether the proposed tooling actually applies to F# sources before promising enforcement.

For C#, nullable reference types and analyzer severity are often part of the public code quality contract. Do not disable them to make a change pass.

Local Tools

When a repo uses local .NET tools, restore them through:

dotnet tool restore

Do not assume globally installed tools are available in CI or on another contributor's machine.

Output Shape

Return:

1. Existing tooling: .editorconfig, analyzers, warnings-as-errors, local tools, CI.
2. Change: documentation, formatting, analyzer, local tool, or CI alignment.
3. Commands: exact format/build/test/tool commands.
4. F# coverage: what applies to F# sources.
5. C# coverage: what applies to C# sources.
6. Residual risk: anything not enforced automatically.

Guardrails

• Do not make a broad formatting sweep inside an unrelated behavior change.
• Do not promise F# formatting/analyzer coverage from C#-only tooling.
• Do not depend on globally installed tools when a local tool manifest is appropriate.
• Do not disable analyzers or nullable checks to hide real issues.
• Do not add warnings-as-errors across an existing noisy repo without a cleanup plan.