Conciseness

Every line carries project-specific, non-obvious knowledge — e.g. "Dense rows use minimum dimensions rather than a fixed width: the text column needs `min-width: 0` plus ellipsis, while logos and trailing actions use `flex-shrink: 0`" and "Stateful collection loading, persistence, and cross-provider orchestration belong in `@iptvnator/portal/shared/data-access`, not UI or util". Nothing explains concepts Claude already knows, and nothing can be trimmed without losing actionable information.

Actionability

Concrete and executable in most places: exact commands ("`pnpm run styles:icon-ligatures:validate` checks them", "also runs `pnpm run perf:compositing`"), specific CSS mechanics, and exact library/package paths to inspect. Not 5 because "Run the focused component/unit target and the closest Playwright workflow" gives no example of how to select or invoke those targets, and "Record any uncovered visual state" specifies no destination or format; not 3 because the guidance is largely copy-paste-ready and specific.

Workflow Clarity

A clear implicit sequence — Inspect First → Design Contract → Validation — with explicit and even conditional checkpoints ("Electron CDP is a fallback for Electron-only gaps", "A change that adds `backdrop-filter`, `filter`, animations or a rounded scroller also runs `pnpm run perf:compositing` ... and quotes the numbers"). Not 5 because there is no error-recovery loop for failed validation and "record any uncovered visual state" lacks a checkpoint destination; not 3 because the checkpoints are explicit and the conditional validation rules are precise.

Progressive Disclosure

A single-file skill under 50 lines with no bundle files, organized into three well-labeled sections. Its references are one level deep and clearly signaled — "Policy: `docs/architecture/iptvnator-ui-guidelines.md`", specific source paths, and "see the theme/style skill's Rendering Cost section" — so navigation is easy and nothing needs splitting.

Specificity

Enumerates many concrete surfaces — "channel rows or lists, EPG views, settings and playlist surfaces, selection states, shared portal components, or light/dark styling" — which goes well beyond naming the domain. It is not 5 because it expresses a single action ("changing") applied to targets rather than multiple concrete capabilities, and it never states what the skill itself provides (design conventions, inspection pointers, validation); it is not 3 because the surface coverage is comprehensive, not just 1-2 items.

Completeness

The "when" is explicit and rich — "Use when changing user-visible Angular UI in IPTVnator, especially..." with concrete trigger phrases — but the "what" (apply IPTVnator's design conventions, inspect shared components, run validation) is never stated, only implied by the trigger context. Not 4 because the what is absent rather than merely under-specified; not 2 because unlike the vague "only when" anchor ("Use when working with documents"), this names the concrete activity and scope, so it sits above that anchor.

Trigger Term Quality

Contains natural terms a contributor would actually say: "Angular UI", "channel rows", "EPG", "settings", "playlist", "selection states", "light/dark styling". Not 5 because common synonyms and variations are missing — "theme/theming", "styles/SCSS/CSS", and generic "component styling" phrasing are absent; not 3 because the keyword coverage is genuinely good and domain-natural rather than merely "some relevant keywords".

Distinctiveness Conflict Risk

Scoped to a single application with app-specific vocabulary — "IPTVnator", "EPG views", "shared portal components" — creating a clear niche with distinct triggers and minimal risk of firing for an unrelated skill. No other generic skill would plausibly match this trigger set.