complexity
.NET Complexity Review
Trigger On
- the team wants to find overly complex methods
- cyclomatic complexity thresholds are needed in CI
- maintainability metrics or coupling thresholds need to be configured
Value
- produce a concrete project delta: code, docs, config, tests, CI, or review artifact
- reduce ambiguity through explicit planning, verification, and final validation skills
- leave reusable project context so future tasks are faster and safer
Do Not Use For
- formatting-only work
- generic analyzer setup with no complexity policy change
Inputs
- the nearest
AGENTS.md - current analyzer settings
- current maintainability limits
Quick Start
- Read the nearest
AGENTS.mdand confirm scope and constraints. - Run this skill's
Workflowthrough theRalph Loopuntil outcomes are acceptable. - Return the
Required Result Formatwith concrete artifacts and verification evidence.
Workflow
- Start with the built-in maintainability analyzers before reaching for non-standard tooling.
- Use these rules deliberately:
CA1502for excessive cyclomatic complexity in methodsCA1505for low maintainability indexCA1506for excessive class couplingCA1501when inheritance depth is also part of the design problem
- Keep rule severity in the root
.editorconfig. - Keep metric thresholds in a checked-in
CodeMetricsConfig.txtadded asAdditionalFiles. - Pair analyzer findings with MCAF maintainability limits in
AGENTS.md.
Bootstrap When Missing
If complexity thresholds are not configured yet:
- Detect current state:
rg -n "CA1501|CA1502|CA1505|CA1506|CodeMetricsConfig" -g '.editorconfig' -g '*.csproj' -g 'Directory.Build.*' .rg --files -g 'CodeMetricsConfig.txt'
- Add severity entries for
CA1502,CA1505,CA1506, andCA1501in root.editorconfig. - Add checked-in
CodeMetricsConfig.txtand include it asAdditionalFilesin project props. - Keep maintainability limits aligned with
AGENTS.md. - Run
dotnet build SOLUTION_OR_PROJECTand returnstatus: configuredorstatus: improved. - If policy relies only on
AGENTS.mdlimits with no analyzer gate by design, returnstatus: not_applicable.
Deliver
- explicit complexity and maintainability policy
- checked-in metric thresholds
- CI commands that surface complex methods early
Validate
- method-complexity checks are enabled where the repo wants them
- thresholds are versioned in repo, not held in IDE memory
- complexity findings map to real refactoring decisions
Ralph Loop
Use the Ralph Loop for every task, including docs, architecture, testing, and tooling work.
- Plan first (mandatory):
- analyze current state
- define target outcome, constraints, and risks
- write a detailed execution plan
- list final validation skills to run at the end, with order and reason
- Execute one planned step and produce a concrete delta.
- Review the result and capture findings with actionable next fixes.
- Apply fixes in small batches and rerun the relevant checks or review steps.
- Update the plan after each iteration.
- Repeat until outcomes are acceptable or only explicit exceptions remain.
- If a dependency is missing, bootstrap it or return
status: not_applicablewith explicit reason and fallback path.
Required Result Format
status:complete|clean|improved|configured|not_applicable|blockedplan: concise plan and current iteration stepactions_taken: concrete changes madevalidation_skills: final skills run, or skipped with reasonsverification: commands, checks, or review evidence summaryremaining: top unresolved items ornone
For setup-only requests with no execution, return status: configured and exact next commands.
Load References
references/complexity.mdreferences/metrics.mdreferences/config.md
Example Requests
- "Which analyzer finds complex methods in .NET?"
- "Add a complexity gate for our C# code."
- "Configure cyclomatic complexity thresholds."
More from managedcode/dotnet-skills
dotnet
Primary router skill for broad .NET work. Classify the repo by app model and cross-cutting concern first, then switch to the narrowest matching .NET skill instead of staying at a generic layer.
18dotnet-aspnet-core
Build, debug, modernize, or review ASP.NET Core applications with correct hosting, middleware, security, configuration, logging, and deployment patterns on current .NET.
13dotnet-entity-framework-core
Design, tune, or review EF Core data access with proper modeling, migrations, query translation, performance, and lifetime management for modern .NET applications.
12dotnet-code-review
Review .NET changes for bugs, regressions, architectural drift, missing tests, incorrect async or disposal behavior, and platform-specific pitfalls before you approve or merge them.
11dotnet-architecture
Design or review .NET solution architecture across modular monoliths, clean architecture, vertical slices, microservices, DDD, CQRS, and cloud-native boundaries without over-engineering.
11dotnet-signalr
Implement or review SignalR hubs, streaming, reconnection, transport, and real-time delivery patterns in ASP.NET Core applications.
10