| 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
- Scans codebase or specific path
- Analyzes code quality metrics
- Identifies patterns and anti-patterns
- 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
