The description uses highly abstract, jargon-heavy language like 'analytical lenses', 'lens-conditioned evidence plus synthesis', and 'FramedInquiry'. It fails to describe concrete, understandable actions a user would recognize. The type signature notation and Greek alias add complexity without clarity.

The description attempts to answer both 'what' (multi-perspective investigation, assembling a team to analyze from viewpoints) and 'when' (when the right framework is absent, factual lookup vs contested design judgment), but the 'when' guidance is buried in abstract language and lacks an explicit 'Use when...' clause with clear triggers.

The description contains no natural keywords a user would actually say. Terms like 'FrameworkAbsent', 'Prothesis(πρόθεσις)', 'lens-conditioned evidence', and the type signature are technical jargon that no user would naturally use when requesting help. There are no common, recognizable trigger terms.

The description is distinctive in its unusual terminology and niche framing, which reduces conflict risk with other skills. However, the abstract language makes it unclear what domain it actually covers, so it could either never trigger or trigger inappropriately since the boundaries are poorly defined.

Extremely verbose — the skill is a massive wall of formal notation, type theory, and categorical abstractions that Claude already understands implicitly. The formal flow specification, type definitions, and categorical notes consume enormous token budget while adding minimal actionable value beyond what could be expressed in a fraction of the space. Concepts like 'coproduct discriminated by m' and 'graded meet over comparison morphisms' are academic formalism that doesn't earn its token cost.

The skill does contain concrete templates (perspective prompt template, synthesis template, cross-dialogue structured report format, routing options) and specific tool calls (TeamCreate, Task, SendMessage, TaskCreate). However, much of the content describes rather than instructs — the formal type system and categorical notes are descriptive abstractions rather than executable guidance, and the actual step-by-step operational instructions are buried under layers of notation.

The phase transitions (0→1→2→3→4) are clearly sequenced with explicit validation checkpoints (Mission Brief confirmation, perspective selection, trigger detection before synthesis). However, the workflow is obscured by the density of formal notation — the FLOW, MORPHISM, TYPES, LOOP, and TOOL GROUNDING sections present overlapping descriptions of the same workflow in different formalisms, making it difficult to follow the actual operational sequence. The feedback loops (modify mission brief, extend, add input) are well-defined but buried.

The skill references external files (references/conceptual-foundations.md, references/isolation-rationale.md) for design rationale and edge cases, which is appropriate progressive disclosure. However, no bundle files were provided, so these references are unverifiable. The main SKILL.md itself is monolithic — the formal specification block (FLOW, MORPHISM, TYPES, LOOP, BOUNDARY, TOOL GROUNDING, CATEGORICAL NOTE, MODE STATE, COMPOSITION) could be split into a separate reference file, with the SKILL.md body focusing on the operational protocol.