find-complexity
Find functions and methods with high cyclomatic complexity, excessive length, or too many parameters. Use when the user asks to find complex code, complexity hotspots, refactoring candidates, or wants to improve code maintainability.
Works with
Agent Skills format with YAML frontmatter. Claude Code reads it as-is.
--- name: "find-complexity" description: "Find functions and methods with high cyclomatic complexity, excessive length, or too many parameters. Use when the user asks to find complex code, complexity hotspots, refactoring candidates, or wants to improve code maintainability." license: "Apache-2.0" --- # Find Complexity Hotspots Identify functions that are hard to review, test, and maintain. ## Rules - Report findings, do not refactor. Refactoring is a separate task. - Focus on production code (`ols/`). Skip tests unless explicitly asked. - Rank by severity: highest complexity first. ## Step 1: Determine Scope Ask the user: - **Branch mode**: only files changed in the current branch vs main. - **Full mode**: scan the entire `ols/` directory. For branch mode: ```bash git diff --name-only origin/main -- 'ols/' | grep '\.py$' ``` ## Step 2: Cyclomatic Complexity ```bash uvx radon cc <target> -s -n C -a ``` This shows functions with complexity grade C or worse (threshold: 11+). Grades: A (1-5), B (6-10), C (11-15), D (16-20), E (21-25), F (26+). ## Step 3: Maintainability Index ```bash uvx radon mi <target> -s -n B ``` This shows files with maintainability grade B or worse. Grades: A (20+, good), B (10-19, medium), C (0-9, poor). ## Step 4: Cognitive Complexity Cognitive complexity weights nesting depth — a 5-deep `if` scores much higher than 5 sequential `if`s. ```bash uvx --with flake8-cognitive-complexity flake8 --select=CCR001 --max-cognitive-complexity=10 <target> ``` ## Step 5: Function Length Find long functions (30+ lines of logic, excluding docstrings and blank lines): ```bash uvx radon raw <target> -s ``` Also use pylint for method length: ```bash uv run pylint --disable=all --enable=too-many-statements,too-many-branches,too-many-return-statements,too-many-arguments,too-many-locals <target> ``` ## Step 6: File Size Find large files (500+ lines): ```bash wc -l $(find <target> -name '*.py') | sort -rn | head -20 ``` Files over 500 lines are candidates for splitting into focused modules. ## Step 7: Classify Findings For each function found, classify: | Category | Criteria | Action | |----------|----------|--------| | **Split** | High complexity + long body | Break into smaller functions | | **Simplify** | High complexity + short body | Reduce branching (early returns, lookup tables) | | **Parameterize** | Too many arguments (6+) | Group into config/dataclass | | **Monitor** | Grade C, not growing | Note it, revisit if it gets worse | | **Split file** | File over 500 lines | Break into focused modules | ## Step 8: Report For each finding: 1. File, function name, line number 2. Complexity grade and score 3. Number of statements / arguments 4. Classification (split / simplify / parameterize / monitor) 5. Brief suggestion Summary: total hotspots by grade, top 5 worst offenders.
More Refactoring skills
vercel-react-best-practices
vercel-labs/agent-skills
React and Next.js performance optimization guidelines from Vercel Engineering. This skill should be used when writing, reviewing, or refactoring React/Next.js code to ensure optimal performance patterns. Triggers on tasks involving React components, Next.js pages, data fetching, bundle optimization, or performance improvements.
analyze-project
lllllllama/rigorpilot-skills
Rigor Analyze / Rigor Audit read-only skill for deep learning research repositories. Use when the user wants to read and understand a repository, inspect model structure and training or inference entrypoints, review configs and insertion points, or flag suspicious implementation patterns without modifying code or running heavy jobs. Do not use for active command execution, broad refactoring, speculative code adaptation, or automatic bug fixing.
request-refactor-plan
mattpocock/skills
Create a detailed refactor plan with tiny commits via user interview, then file it as a GitHub issue. Use when user wants to plan a refactor, create a refactoring RFC, or break a refactor into safe incremental steps.

