complexity-recognition

Diagnose code complexity symptoms and underlying causes in software modules.

11|Updated Feb 25, 2026
One-click install
npx skills add https://github.com/codybrom/clairvoyance --skill complexity-recognition
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: complexity-recognition
Source: https://github.com/codybrom/clairvoyance/tree/main/skills/complexity-recognition
Command: npx skills add https://github.com/codybrom/clairvoyance --skill complexity-recognition

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill helps identify why code feels difficult to understand and modify when no single design smell explains the problem. It reveals change amplification, cognitive load, unknown unknowns, hidden dependencies, and obscured information so teams can prioritize meaningful improvements.

Core Features & Use Cases

  • Complexity Diagnosis: Evaluate code through three symptoms—change amplification, cognitive load, and unknown unknowns.
  • Root-Cause Analysis: Distinguish dependency-driven complexity from obscurity and identify hidden connections that increase risk.
  • Refactoring Guidance: Recommend whether to eliminate complexity through redesign or encapsulate it within a deeper module.
  • Use Case: Apply the review to a frequently modified service where small changes touch multiple files and developers struggle to understand implicit invariants.

Quick Start

Ask the complexity-recognition skill to review the specified file or module, identify its main complexity symptoms and root causes, and recommend targeted improvements.

Frequently Asked Questions about complexity-recognition

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I diagnose why a module has high cognitive load and unknown unknowns?

To diagnose software complexity, evaluate code through change amplification, cognitive load, and unknown unknowns. Identify root causes by distinguishing dependency-driven complexity from obscurity and mapping hidden connections that increase modification risk.

What is the best way to reduce change amplification when small edits touch multiple files?

The best way to reduce change amplification is to identify underlying complexity causes and recommend targeted improvements. Decide whether to eliminate the complexity through module redesign or encapsulate it within a deeper module to isolate widespread edits.

Why does refactoring code with hidden dependencies feel risky and obscure?

Refactoring feels risky due to obscurity and hidden dependencies that create unknown unknowns. When implicit invariants and obscured information exist, developers struggle to understand the true impact of modifications, increasing cognitive load and the chance of breaking changes.

Can I use this approach to review a frequently modified service with implicit invariants?

Yes, you can review frequently modified services by reading the target code and assessing its complexity symptoms. This approach evaluates hot paths and implicit invariants to reveal hidden dependencies and cognitive load for prioritizing meaningful improvements.

When should I encapsulate software complexity instead of eliminating it through redesign?

You should encapsulate software complexity instead of eliminating it when the root cause is deeply tied to essential dependencies. Encapsulating it within a deeper module isolates the obscurity and cognitive load from the rest of the system.