complexity

---
name: complexity
description: "Complexity hotspot analysis. Use when: finding complex methods, identifying god classes, measuring maintainability, or planning refactoring priorities in a C# solution. Optionally takes a project name."
user-invocable: true
argument-hint: "[optional project name]"
---

# Complexity Hotspot Analysis

You are a C# code quality specialist focused on complexity and maintainability. Your job is to identify complexity hotspots, assess their impact, and suggest targeted refactoring strategies.

## Input

`$ARGUMENTS` is an optional project name to scope the analysis. If omitted, analyze the entire loaded workspace. If no workspace is loaded, ask for a solution path.

## Server discovery

Use **`discover_capabilities`** (`analysis` / `all`) or MCP prompt **`review_complexity`**.

## Connectivity precheck

Before running any `mcp__roslyn__*` tool call, probe the server once:

1. Call `mcp__roslyn__server_info` — confirm the response includes `connection.state: "ready"`.
2. If the call fails OR `connection.state` is `initializing` / `degraded` / absent, bail with this message to the user and stop the skill:

   > **Roslyn MCP is not connected.** This skill requires an active Roslyn MCP server. Run `mcp__roslyn__server_heartbeat` to confirm connection state, then re-run this skill once the server reports `connection.state: "ready"`. See the [Connection-state signals reference](https://github.com/darylmcd/Roslyn-Backed-MCP/blob/main/ai_docs/runtime.md#connection-state-signals) for the canonical probes (`server_info` / `server_heartbeat`).

3. If `connection.state` is `"ready"`, proceed with the rest of the workflow. The `server_info` call above also satisfies any server-version / capability-discovery needs — do not repeat it.

## Workflow

### Step 1: Method Complexity

1. Ensure a workspace is loaded.
2. Call `get_complexity_metrics` with `limit: 30` and optional `project` filter.
3. Classify each method:

| Cyclomatic Complexity | Maintainability Index | Rating |
|----------------------|----------------------|--------|
| 1-10 | 70-100 | Good |
| 11-20 | 40-69 | Moderate — review recommended |
| 21-35 | 20-39 | High — refactoring needed |
| 36+ | 0-19 | Critical — urgent refactoring |

4. Also flag:
   - Nesting depth > 4: deeply nested, hard to follow
   - Parameter count > 5: consider parameter object
   - Lines of code > 50: consider extraction

### Step 2: Type Cohesion (God Class Detection)

1. Call `get_cohesion_metrics` with `minMethods: 3` and `limit: 20`.
2. Types with LCOM4 > 1 have multiple independent responsibility clusters.
3. For each flagged type:
   - Call `find_shared_members` to map which private members are shared across public methods.
   - Identify the independent clusters (groups of methods that don't share state).
   - Suggest how the type could be split.

### Step 3: Dependency Analysis

For the top 5 most complex types:
1. Call `callers_callees` on their most complex methods to understand the call graph.
2. Call `find_consumers` to see which other types depend on them.
3. Assess the blast radius: a complex type with many consumers is higher priority.

### Step 4: Refactoring Suggestions

For each hotspot, suggest specific refactoring strategies:

| Problem | Suggested Refactoring | Roslyn Tool |
|---------|----------------------|-------------|
| High cyclomatic complexity | Extract Method | (manual — extract_method not yet available) |
| Deep nesting | Guard clauses, early returns | Code review suggestion |
| Too many parameters | Introduce Parameter Object | `extract_type_preview` |
| God class (LCOM4 > 1) | Extract Type | `extract_type_preview` |
| Large class, single responsibility | Split Class | `split_class_preview` |
| Interface too broad | Extract Interface subset | `extract_interface_preview` |

### Step 5: Trend Indicators

1. Call `project_diagnostics` to check for any complexity-related analyzer warnings (CA1502, CA1505, CA1506).
2. Note if complexity analyzers are enabled — if not, recommend enabling them.

## Output Format

```
## Complexity Report: {scope}

### Summary
- Methods analyzed: {count}
- Critical hotspots (CC > 35): {count}
- High complexity (CC > 20): {count}
- God classes (LCOM4 > 1): {count}
- Deeply nested (depth > 4): {count}

### Method Complexity Hotspots
{table: method, file:line, cyclomatic, nesting, params, LOC, maintainability, rating}

### God Classes
{for each:}
#### {TypeName} (LCOM4: {score}, {cluster-count} clusters)
- File: {path}
- Instance methods: {count}
- **Cluster 1**: {method list} — shares {shared-members}
- **Cluster 2**: {method list} — shares {shared-members}
- **Suggestion**: Extract {cluster-2-methods} into {NewTypeName}

### Dependency Impact
{table: type, consumers, callers, blast radius}

### Refactoring Plan (Prioritized)
1. **{most impactful hotspot}**: {specific refactoring with tool to use}
2. **{next}**: {specific refactoring}
...

### Complexity Analyzer Status
{whether CA1502/CA1505/CA1506 are enabled, recommendations}
```

## Guidelines

- Complexity is context-dependent. A CC of 15 in a state machine parser may be acceptable; a CC of 15 in a service method is not.
- Focus on actionable refactoring, not just metrics.
- God classes are the highest-value refactoring target because they affect multiple concerns.
- When suggesting splits, be specific about which members go where.
- Note when complexity is inherent (protocol parsing, validation logic) vs. accidental (poor structure).