agentleFS
selamy-labsselamy-labs/agent-skills/skills/complexity-budgets/SKILL.md

complexity-budgets

Skill0 starsChanged 4 days agoMITView on GitHub

Use when code review or implementation needs enforceable limits on branching, nesting, cognitive complexity, function size, or parameter count. Compose language-specific complexity analyzers with repo-native lint gates.

The file

We split this skill into the rules it gives an agent

6 rules. About 0 are common, 5 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈5

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use this skill when functions are hard to understand because they branch too much, nest too deeply, take too many parameters, or own too …

    line 8
  2. Distinctive:

    Run the repository's existing formatter and linter first.

    line 13
  3. Very specific:

    If a repository is indexed by CodeGraph, use codegraph-worktree-startup for navigation and blast radius before selecting files to measure.

    line 14
  4. Distinctive:

    Run the appropriate language analyzer to find hotspots before choosing a threshold:

    line 17
  5. Distinctive:

    Add the smallest rule that catches the problem — cyclomatic complexity, cognitive complexity, max nesting depth, max function length, or …

    line 38
  6. Distinctive:

    Add focused tests around a complex function before reducing its complexity.

    line 45

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Complexity Budgets

Use this skill when functions are hard to understand because they branch too much, nest too deeply, take too many parameters, or own too many responsibilities.

Workflow

  1. Run the repository's existing formatter and linter first.
  2. If a repository is indexed by CodeGraph, use codegraph-worktree-startup for navigation and blast radius before selecting files to measure. CodeGraph finds the code; complexity analyzers score it.
  3. Run the appropriate language analyzer to find hotspots before choosing a threshold:

    # Python
    complexipy . --top 20 --sort desc
    complexipy . --max-complexity-allowed 10 --failed --suggest-refactors
    
    # TypeScript / JavaScript, when @genese/complexity is installed
    complexity src
    genese cpx src --language ts --console

    For changed-code checks, prefer the repository's base reference or staged diff when the tool supports it:

    complexipy . --diff main
    complexipy . --staged=true
  4. Add the smallest rule that catches the problem — cyclomatic complexity, cognitive complexity, max nesting depth, max function length, or max parameter count — not all of them.
  5. Set the first threshold to the current worst offender, so it stops new outliers without forcing a cleanup PR. For cyclomatic complexity, a starting threshold of 10 is the conventional default across the linters below; raise it to fit existing debt, then ratchet down.
  6. Add focused tests around a complex function before reducing its complexity.
  7. Lower a threshold only after the code is already below the new value.

Tool Bindings

Each tool's cyclomatic-complexity check defaults to a limit near 10 — a sound starting point before ratcheting:

  • Python: Ruff with McCabe (C901) for cyclomatic complexity; complexipy for cognitive complexity, diff reports, and refactor suggestions.
  • TypeScript and JavaScript: ESLint complexity and max-depth; use typescript-eslint where type information matters. When the complexity CLI from @genese/complexity is available, use it for cognitive and cyclomatic reports over ts, js, tsx, and jsx code.
  • TypeScript hotspot scans: fta-cli is a good fast file-level triage tool when the repository already uses it, but do not substitute a file-level score for function-level thresholds when a function budget is needed.
  • Go: golangci-lint with gocyclo or gocognit.
  • Java: Checkstyle complexity checks plus SpotBugs for bug patterns.
  • Kotlin: detekt complexity rules.
  • Shell: ShellCheck plus shfmt; extract shell functions once branches grow.

Review Checks

  • The rule runs in CI and blocks only changed or newly violating code when the repository has existing debt.
  • CI should invoke the same language analyzer used during review. Python CI may use complexipy JSON, GitLab, or SARIF output; TypeScript/JavaScript CI may use complexity/genese cpx reports or ESLint complexity rules, depending on whether the budget is cognitive, cyclomatic, or both.
  • Suppressions are rare, local, and include a reason.
  • Complexity reduction does not remove behavior coverage.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.