/analyze

name: analyze
description: "Analyzes code quality, complexity, patterns across codebase. Triggers: quality report, hotspot scan, code analysis, architecture signal."
user-invocable: true
effort: medium
argument-hint: "[path or pattern]"
allowed-tools: Read, Grep, Glob

Code Analysis

$ARGUMENTS

Analyze code quality, complexity, and patterns.

Usage

/analyze [path] [--type=<type>]

What This Command Does

1. **Scans** codebase or specific path 2. **Analyzes** code quality metrics 3. **Identifies** patterns and anti-patterns 4. **Reports** findings with recommendations

Analysis Types

| Type | Description | |------|-------------| | `quality` | Code quality metrics (default) | | `security` | Security vulnerability scan | | `complexity` | Cyclomatic complexity | | `dependencies` | Dependency analysis | | `coverage` | Test coverage gaps |

Output Format

## Code Analysis Report

### Summary
- **Files Analyzed**: [count]
- **Issues Found**: [count]
- **Quality Score**: [score]/100

### Metrics
| Metric | Value | Threshold |
|--------|-------|-----------|
| Complexity | [avg] | <10 |
| Duplication | [%] | <5% |
| Coverage | [%] | >70% |

### Issues by Severity
- Critical: [count]
- High: [count]
- Medium: [count]
- Low: [count]

### Top Issues
1. **[Issue]** - [file:line]
   - [Description]
   - Fix: [Recommendation]

### Patterns Detected
- [Pattern 1]: [locations]
- [Pattern 2]: [locations]

### Recommendations
1. [Recommendation with priority]

Automated Complexity Analysis

Run the bundled script for a quick complexity report:

python3 ${CLAUDE_SKILL_DIR}/scripts/complexity.py .

Reports file counts by type, largest files, TODO/FIXME counts, and total code lines.

Common Rationalizations

| Excuse | Why It's Wrong | |--------|----------------| | "The linter is green, the code is fine" | Linters catch syntax, not design flaws — analysis covers architecture and patterns | | "We know where the problems are" | Intuition misses systemic issues — data-driven analysis reveals hidden hotspots | | "Analysis takes too long" | A 5-minute scan prevents weeks of debugging — front-load the investment | | "It's legacy code, analysis won't help" | Legacy code benefits most — find the critical paths before they break |

Tools Used

| Language | Tools | |----------|-------| | Python | ruff, mypy, pylint | | JavaScript | eslint, tsc | | Go | golangci-lint | | Rust | clippy |

Rules

• **MUST** report measured values — never assert "this is fine" without numbers
• **NEVER** modify source files (read-only skill)
• **CRITICAL**: if the requested analysis type is unsupported for the detected language, say so explicitly and stop — do not fake metrics

Gotchas

• Linters that exit `0` still may have **skipped** files (gitignore rules, no-match patterns, parse errors). Always read the "N files checked" line before reporting "clean".
• Coverage percentages silently exclude generated code, migrations, and `__init__.py` by default. Report coverage with the exclude list, not the headline number alone.
• `ruff` and `pylint` disagree on several rules (line length, import order) — pick one as the source of truth for the project and note the choice in the report.
• `mypy --strict` on a codebase that was not authored under strict mode will return hundreds of spurious findings. Start with `--ignore-missing-imports` and a file allowlist before claiming the codebase is untyped.

When NOT to Use

• For a single-PR code review — use `/review` instead
• For fixing a specific bug — use `/debug` or `/fix`
• For architectural friction and module design — use `/architecture-audit`
• For a vulnerability scan of dependencies — use `/cve-scan`

Related Skills

• Found quality issues? → `/refactor` to fix them systematically
• Security issues detected? → `/cve-scan` for dependency audit
• Want deeper architecture review? → `/architecture-audit` for friction discovery
• Performance hotspots found? → `/workflow performance-optimization`