It is a refactoring checklist, not a complexity analyzer
Cyclomatic Complexity gives Claude a fixed routine for cleaning up branch-heavy functions. The skill says to measure touched functions, rank the worst ones, refactor one at a time, measure again, and finish with a table of before-and-after counts. It prefers project lint settings over its own defaults and names Radon for Python, ESLint for JavaScript and TypeScript, gocyclo for Go, and Lizard for mixed-language codebases. If none is installed, Claude is told to count decisions manually.
That distinction matters because the repository does not implement any measurement code. At commit 567886f, its useful payload is a Markdown instruction file plus marketplace metadata. Our 3-CPU, 8 GB sandbox found no supported ecosystem and no Dockerfile, leaving the harness with nothing it could install or execute. You are adopting a prompt and workflow. Accuracy still depends on the external analyzer, the project's tests, and Claude following the instructions without skipping inconvenient branches.
The default thresholds force action above 15
The policy is more opinionated than a generic request to simplify code. Complexity from 1 through 5 is left alone, 6 through 10 gets attention only when the function is already being touched, 11 through 15 should be refactored, and anything above 15 must be split. Existing linter configuration wins, which is the right order for a shared codebase. The skill also counts boolean operators inside conditions, a detail that can differ between complexity tools and should be reconciled with whichever analyzer your team uses.
Its tactics are ordinary and mostly sound: guard clauses first, then extracted functions, lookup tables, named predicates, and flatter loop bodies. Strategy objects are reserved for type switches repeated in at least 2 places. Our lab did not test those choices against a real project because commit 567886f supplied no runnable target. The skill does instruct Claude to preserve public signatures, run tests before and after, and admit when no tests exist. Those safeguards are written rules, not enforced checks.
What happened when we ran it
We did not run the repository. The checkout at commit 567886f had no supported package ecosystem, GitHub listed its primary language as null, and no Dockerfile gave our fresh Debian sandbox another route. As a result, there is no measured install result, build result, dependency audit, or test result to report. Claiming that the skill works from this lab pass would be misleading.
The environment had 3 CPUs and 8 GB of RAM, but those resources were irrelevant because the project is declarative. A useful future test would need a fixture repository with known complexity hotspots, a pinned analyzer, behavior tests, and expected before-and-after counts. None of that exists here. The README's example shows a function falling from 14 to 4, but it is presented as example output rather than a result from our sandbox, so it should not be read as measured performance.
Claude Code has an install path, while Claude.ai does not have its promised file
For Claude Code, the README provides marketplace-add and plugin-install commands. The marketplace manifest points the plugin at the repository root, where the skill lives under skills/cyclomatic-complexity. Claude API users are directed to the Skills API. No account token, remote service, or runtime daemon is named. You still need the language-specific analyzer and whatever command proves the refactor preserved behavior. On a mature project, those pieces may already be present.
Claude.ai users get shakier instructions. The README says to download a .skill file from Releases or zip the skill folder, but GitHub returned no latest release on August 29, 2026. The manual zip route remains possible, yet it shifts packaging onto the user. The repository also had a single commit, dated August 26, and no issues or pull requests. That is enough to inspect the full history, not enough to judge how the instructions behave across different codebases.
Fixed advice is useful only when the project can overrule it
The strongest part of the skill is its refusal to reward compressed code that merely hides branches. It asks for named units and a reviewable diff, and it requires the report to say how behavior was checked. That can improve a Claude refactoring session because the expected evidence is explicit. The limitation is equally plain: a Markdown rule cannot stop an agent from miscounting, extracting poor abstractions, or accepting a weak test suite. Human review still decides whether the new shape is easier to maintain.
Our unexecuted 567886f snapshot is best treated as a readable policy draft. Install it when your team wants this exact routine and already trusts its analyzers and tests. Choose Lizard or Radon when measurement itself is the need, and Xenon when a Python build must reject rising complexity automatically. For broader adoption, the author needs a published skill artifact and fixture-based checks that show Claude preserves behavior while reducing counts across more than one language.