$npx -y skills add softspark/ai-toolkit --skill analyzeAnalyzes code quality, complexity, patterns across codebase. Triggers: quality report, hotspot scan, code analysis, architecture signal.
| 1 | # Code Analysis |
| 2 | |
| 3 | $ARGUMENTS |
| 4 | |
| 5 | Analyze code quality, complexity, and patterns. |
| 6 | |
| 7 | ## Usage |
| 8 | |
| 9 | ``` |
| 10 | /analyze [path] [--type=<type>] |
| 11 | ``` |
| 12 | |
| 13 | ## What This Command Does |
| 14 | |
| 15 | 1. **Scans** codebase or specific path |
| 16 | 2. **Analyzes** code quality metrics |
| 17 | 3. **Identifies** patterns and anti-patterns |
| 18 | 4. **Reports** findings with recommendations |
| 19 | |
| 20 | ## Analysis Types |
| 21 | |
| 22 | | Type | Description | |
| 23 | |------|-------------| |
| 24 | | `quality` | Code quality metrics (default) | |
| 25 | | `security` | Security vulnerability scan | |
| 26 | | `complexity` | Cyclomatic complexity | |
| 27 | | `dependencies` | Dependency analysis | |
| 28 | | `coverage` | Test coverage gaps | |
| 29 | |
| 30 | ## Output Format |
| 31 | |
| 32 | ```markdown |
| 33 | ## Code Analysis Report |
| 34 | |
| 35 | ### Summary |
| 36 | - **Files Analyzed**: [count] |
| 37 | - **Issues Found**: [count] |
| 38 | - **Quality Score**: [score]/100 |
| 39 | |
| 40 | ### Metrics |
| 41 | | Metric | Value | Threshold | |
| 42 | |--------|-------|-----------| |
| 43 | | Complexity | [avg] | <10 | |
| 44 | | Duplication | [%] | <5% | |
| 45 | | Coverage | [%] | >70% | |
| 46 | |
| 47 | ### Issues by Severity |
| 48 | - Critical: [count] |
| 49 | - High: [count] |
| 50 | - Medium: [count] |
| 51 | - Low: [count] |
| 52 | |
| 53 | ### Top Issues |
| 54 | 1. **[Issue]** - [file:line] |
| 55 | - [Description] |
| 56 | - Fix: [Recommendation] |
| 57 | |
| 58 | ### Patterns Detected |
| 59 | - [Pattern 1]: [locations] |
| 60 | - [Pattern 2]: [locations] |
| 61 | |
| 62 | ### Recommendations |
| 63 | 1. [Recommendation with priority] |
| 64 | ``` |
| 65 | |
| 66 | ## Automated Complexity Analysis |
| 67 | |
| 68 | Run the bundled script for a quick complexity report: |
| 69 | |
| 70 | ```bash |
| 71 | python3 ${CLAUDE_SKILL_DIR}/scripts/complexity.py . |
| 72 | ``` |
| 73 | |
| 74 | Reports file counts by type, largest files, TODO/FIXME counts, and total code lines. |
| 75 | |
| 76 | ## Common Rationalizations |
| 77 | |
| 78 | | Excuse | Why It's Wrong | |
| 79 | |--------|----------------| |
| 80 | | "The linter is green, the code is fine" | Linters catch syntax, not design flaws — analysis covers architecture and patterns | |
| 81 | | "We know where the problems are" | Intuition misses systemic issues — data-driven analysis reveals hidden hotspots | |
| 82 | | "Analysis takes too long" | A 5-minute scan prevents weeks of debugging — front-load the investment | |
| 83 | | "It's legacy code, analysis won't help" | Legacy code benefits most — find the critical paths before they break | |
| 84 | |
| 85 | ## Tools Used |
| 86 | |
| 87 | | Language | Tools | |
| 88 | |----------|-------| |
| 89 | | Python | ruff, mypy, pylint | |
| 90 | | JavaScript | eslint, tsc | |
| 91 | | Go | golangci-lint | |
| 92 | | Rust | clippy | |
| 93 | |
| 94 | ## Rules |
| 95 | |
| 96 | - **MUST** report measured values — never assert "this is fine" without numbers |
| 97 | - **NEVER** modify source files (read-only skill) |
| 98 | - **CRITICAL**: if the requested analysis type is unsupported for the detected language, say so explicitly and stop — do not fake metrics |
| 99 | |
| 100 | ## Gotchas |
| 101 | |
| 102 | - 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". |
| 103 | - Coverage percentages silently exclude generated code, migrations, and `__init__.py` by default. Report coverage with the exclude list, not the headline number alone. |
| 104 | - `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. |
| 105 | - `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. |
| 106 | |
| 107 | ## When NOT to Use |
| 108 | |
| 109 | - For a single-PR code review — use `/review` instead |
| 110 | - For fixing a specific bug — use `/debug` or `/fix` |
| 111 | - For architectural friction and module design — use `/architecture-audit` |
| 112 | - For a vulnerability scan of dependencies — use `/cve-scan` |
| 113 | |
| 114 | ## Related Skills |
| 115 | - Found quality issues? → `/refactor` to fix them systematically |
| 116 | - Security issues detected? → `/cve-scan` for dependency audit |
| 117 | - Want deeper architecture review? → `/architecture-audit` for friction discovery |
| 118 | - Performance hotspots found? → `/workflow performance-optimization` |