Now liveThe Skillselion MCP - thousands of ranked skills, loaded into your agent mid-task. No install.Get it →
pproenca avatar

Complexity Optimizer

  • 1 installs
  • 191 repo stars
  • Updated July 24, 2026
  • pproenca/dot-skills

Scans a codebase for algorithmic complexity hotspots (nested loops, N+1 queries, sort-in-loop) and reports ranked findings, optionally applying safe optimizations.

About

Runs an AST/regex scanner plus manual inspection to rank performance hotspots by impact, then proposes or implements optimizations only after tests confirm behavior is preserved. A developer uses it to audit a repo for O(n^2) patterns or reduce complexity without breaking outputs.

  • Python AST analysis plus regex heuristics for 20+ other languages
  • Report-only by default; edits only on explicit request with rollback via git restore

Complexity Optimizer by the numbers

  • 1 all-time installs (skills.sh)
  • Ranked #982 of 1,352 Code Review & Quality skills by installs in the Skillselion catalog
  • Data as of Aug 4, 2026 (Skillselion catalog sync)
npx skills add https://github.com/pproenca/dot-skills --skill complexity-optimizer

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

Listed on Skillselion
Installs1
repo stars191
Last updatedJuly 24, 2026
Repositorypproenca/dot-skills

What it does

Scans a codebase for algorithmic complexity hotspots (nested loops, N+1 queries, sort-in-loop) and reports ranked findings, optionally applying safe optimizations.

Files

SKILL.mdMarkdownGitHub ↗

Complexity Optimizer

Find algorithmic complexity hotspots in a codebase and produce a structured report. Optionally implement low-risk optimizations after explicit consent.

When to Apply

Use this skill when the user asks to:

  • Analyze, audit, scan, or review a codebase for performance hotspots or algorithmic complexity
  • Find inefficient loops, nested iteration, N+1 queries, sort-in-loop, render-path recomputation
  • Reduce complexity (e.g. O(n^2) → O(n log n) or O(n))
  • "Give me a report" on a codebase's complexity profile

Do not use this skill for:

  • Micro-optimizations on cold code paths
  • Memory tuning (this skill targets time complexity, not allocation profiles)
  • Code style refactoring unrelated to complexity

Workflow Overview

Baseline → Rank → Prove behavior → Optimize (opt-in) → Verify
   ↓           ↓                       ↓
 scanner   prioritize hot          rollback if
 + manual  paths & large I/O       tests regress
StepActionToolRisk
1Establish baseline: detect stack, test command, hot pathsscripts/analyze_complexity.py + manual inspectionread-only
2Rank opportunities by impact, separating algorithmic wins from constant-factor cleanupreasoningread-only
3Locate or add tests covering the function/componentRead + test frameworkread-only
4Apply optimization (ONLY when user explicitly requests)Edit/Writedestructive
5Run tests, lint, type-check, and a benchmark when warranted; report before/after complexityBash test commandsread-only

Core Rule

Optimize only when current behavior is understood and can be preserved. Prefer a small, proven improvement with tests over a broad rewrite with unclear correctness.

Default Behavior

When the user asks to analyze, scan, audit, review, or "give me a report" for a codebase, produce the full complexity report automatically. Do not require the user to specify report fields.

Default report contents (see references/report-template.md):

  • Scope analyzed and detected stack/test commands
  • Top findings ranked by likely impact
  • File and line for each finding
  • Current pattern and why it may be costly
  • Estimated current complexity
  • Recommended change and estimated complexity after
  • Risk level
  • Tests, benchmarks, or manual checks needed
  • Clear statement that no files were modified, unless the user explicitly requested implementation

Only edit files when the user uses an explicit edit verb: implement, fix, optimize, apply, change, refactor. If the request is analysis-only or a report-only request, do not modify files.

Workflow Detail

1. Baseline

  • Identify language, framework, test command, build command, and performance-sensitive paths.
  • Inspect existing tests before touching code.
  • Run python3 scripts/analyze_complexity.py <repo> for a first-pass hotspot list when scanning a repository.

2. Rank

  • Prioritize hot paths, large-input paths, rendering loops, database/API loops, shared utilities.
  • Separate algorithmic complexity from constant-factor cleanup.
  • Treat scanner output as leads, not proof.
  • For report-only requests, inspect enough surrounding code to estimate current and proposed complexity. Do not stop at raw scanner output.

3. Prove behavior

  • Locate or add focused tests for the function/component being changed.
  • Capture edge cases: empty input, duplicates, ordering stability, null/missing values, errors, permissions, pagination, time zones, mutation side effects.
  • If tests are absent and behavior is ambiguous, make the smallest possible refactor or ask for expected behavior before changing semantics.

4. Optimize (only on explicit request)

  • Replace repeated linear lookup with maps/sets when key equality is stable.
  • Replace nested scans with indexing, grouping, two-pointer scans, sweep-line logic, binary search, memoization, batching, or precomputation — only when the data shape supports it.
  • In UI code, reduce unnecessary renders with stable props, memoized derived data, virtualization, debounced work, and moving expensive work out of render paths.
  • In data access code, remove N+1 with bulk fetches, joins, preloading, caching, or batching while preserving authorization and filtering.

5. Verify

  • Run relevant tests and type/lint/build commands.
  • Add a micro-benchmark or measurement when the complexity improvement is non-obvious or performance-critical.
  • Report original complexity, new complexity, files changed, tests run, and any residual risk.

First-Pass Scanner

python3 scripts/analyze_complexity.py /path/to/repo --format markdown
python3 scripts/analyze_complexity.py /path/to/repo --format json
python3 scripts/analyze_complexity.py /path/to/repo --changed-only --base origin/main

--changed-only restricts the scan to files changed vs --base (default HEAD~1). Use it for PR-focused complexity review.

Language depth:

  • Python (.py) — AST-based analysis. High precision: nested loops, sort/membership in loops, query/I/O in loops, all tracked per-function via the Python ast module.
  • All other supported languages (.js, .ts, .jsx, .tsx, .java, .go, .rb, .php, .cs, .c, .cpp, .swift, .vue, .svelte, .kt, .rs, .dart, .scala) — regex-based pattern matching with indent + function-boundary heuristics. Treat findings as leads; verify by reading the surrounding code before recommending fixes.

If the scanner reports nothing, still inspect known hot paths manually. Rendering churn, database query patterns, and framework lifecycle issues often need repository-specific context the scanner cannot see.

Exit codes: 0 = scanned successfully, 2 = bad input (non-existent path / file instead of directory / git error), 3 = zero files matched, 130 = interrupted.

Triage before reporting: consult references/false-positives.md to dismiss known noise patterns (single-call predicates, Redux selectors, SQL-builder fluent methods, render-derived work on small static arrays) before recommending fixes.

Testing the scanner: python3 scripts/test_analyze_complexity.py runs 13 regression tests that pin the false-positive fixes. Run after modifying the scanner.

Optimization Safety Checklist

Before editing:

  • Confirm the data sizes are large enough for complexity to matter.
  • Confirm the optimization preserves output ordering where callers may rely on it.
  • Confirm object identity, mutability, and reference sharing are not part of public behavior.
  • Confirm caches have a valid invalidation strategy.
  • Confirm deduplication does not collapse distinct records that share a display label.
  • Confirm database batching preserves tenant, permission, soft-delete, pagination, and sorting constraints.

After editing:

  • Run the narrowest relevant test first, then the broader build/lint/typecheck.
  • Compare before/after benchmark numbers when a benchmark exists or was added.
  • Keep the patch localized — avoid formatting churn in unrelated files.

Rollback

If the optimization breaks a test or changes observable behavior:

1. Revert the changed file(s) immediately:

   git restore <file>           # restore a single file
   git restore -SW <file>       # restore both index and working tree

If multiple files were modified: git restore -SW . (only within the affected directory).

2. Re-run the failing test to confirm restoration.

3. Report the failure to the user with:

  • The exact test/assertion that failed
  • The semantics that diverged (ordering, mutation, key equality, etc.)
  • Whether to retry with a different transformation, or stay with the original code

4. Do not re-attempt the same optimization with a small tweak. If a transformation breaks behavior, either the data shape doesn't support it, or there's an unstated invariant — re-read the code before trying again.

References

  • references/optimization-playbook.md — common O(n^2) → O(n log n) / O(n) transformations, framework-specific patterns, and "What Not To Do".
  • references/report-template.md — structure for the final analysis or audit output.
  • references/false-positives.md — catalog of scanner findings that look real but aren't. Consult before recommending fixes.
  • scripts/_sections.md — scanner invocation, flags, exit codes, and limitations.

Related skills

Code Review & Qualitybackendtesting

This week in AI coding

Five minutes, every Monday - the tools, releases and tactics for developers.

unsubscribe anytime.