Evaluates whether abstractions provide a genuinely different way of thinking or are structurally shallow. Use when adjacent layers feel redundant, wrappers add boilerplate without depth, or an abstraction feels leaky. Not for a single module's interface-to-implementation ratio (use deep-modules) or information leakage across boundaries (use information-hiding).
Evaluates whether changes to existing code maintain or degrade design quality. Use when reviewing diffs, PRs, or recently modified files to judge whether each change looks designed-in or bolted-on. Not for scanning design smells (use red-flags) or assessing overall design investment (use strategic-mindset).
Reviews comment quality and documentation practices: the four comment types, comments-first workflow, and comment rot. Use when reviewing comments or docs, when comments just repeat the code, or when something is hard to describe in a sentence. Not for naming or code obviousness (use naming-obviousness).
Diagnoses whether complexity exists and where it comes from, using the three-symptom, two-root-cause framework. Use when code feels harder to work with than it should but the specific problem is unclear. Not for scanning known design smells (use red-flags) or evaluating a module's depth (use deep-modules).
Measures module depth: whether the interface is simple relative to the implementation behind it. Use when an interface has too many parameters or methods, many small classes each do too little, or methods just forward calls. Not for whether adjacent layers provide different abstractions (use abstraction-quality) or merging/splitting modules (use module-boundaries).
Generates and compares at least two fundamentally different design alternatives on concrete criteria before committing. Use when the user asks to design something twice, or before committing to any significant design of classes, modules, APIs, or architecture. Not for judging strategic vs. tactical investment in existing code (use strategic-mindset) or whether a change degrades design (use code-evolution).
Orchestrates a structured design review, running the other skills as a diagnostic funnel from complexity triage to a full red-flags sweep. Use when reviewing a file, module, or PR for overall design quality and you want a comprehensive, prioritized assessment. Not for applying one specific lens (use that skill directly) or analyzing how code changed over time (use code-evolution).
Routes a vague symptom or complaint to the most relevant Clairvoyance skill via a decision tree. Use when someone describes a problem but doesn't know which skill to reach for. Not for a comprehensive review (use design-review) or a checklist scan (use red-flags).