Conciseness

The body is dense, imperative, and free of padding — it never explains what Iced or the Elm architecture is, and every line carries non-obvious hard-won knowledge (e.g. "A widget that 'only updates on the second click' has stale layout. Add `invalidate_layout()`"). It fully matches 'lean and efficient; assumes Claude's competence; every token earns its place'.

Actionability

Guidance is concretely executable throughout: exact API names (`Theme::custom_with_fn`, `Subscription::run_with`, `sensor.on_show`), a runnable WRONG/RIGHT code pattern for conditional wrapping, specific tool commands (`ctx7 docs /websites/iced_rs "<query>"`), panic signatures for diagnosis ("`container.rs unwrap() on None`"), and precise thresholds (8px tab-drag). This matches 'fully executable... specific examples cover the common cases'.

Workflow Clarity

The Workflow section is a clear 4-step sequence (classify surface → read canonical example → read the surface's guide → stuck-path: gotchas then `guide-animation-debugging.md`, with the three most common failures named), which is a real error-recovery loop. It falls short of the level-5 anchor only because there is no explicit validation checkpoint that generated code is checked against the canonical example before proceeding — a minor gap.

Progressive Disclosure

Structure is strong: need→file tables for guides and examples, an `INDEX.md` hub for the full reference catalog, and one-level-deep references with clear use-case signaling (all reference paths cited in the body — `guide-surface-selection.md`, `animation.md`, `theme.md`, `debug.md`, etc. — verified present in `references/`). It is not 5 because the `examples/` table and the `iced_wgpu/src/` section point to directories that do not exist in the bundle, leaving those navigation paths dead as shipped.

Specificity

"Load whenever building or debugging an Iced UI" names the domain and the two activities of building and debugging, but enumerates no concrete capabilities — the coverage of custom widgets, overlays, Canvas, Shader, pane_grid, and theming lives in the summary field, not the description. It matches 'names domain and 1-2 concrete actions, but not comprehensive' rather than the level-4 anchor, which requires several specific listed actions.

Completeness

The 'when' is explicit and dual-trigger ("whenever building or debugging an Iced UI"), but the 'what' is only weakly implied — the description never states what the skill provides (an API reference and guides), which is instead relegated to the summary field. This sits between the level-2 anchor (when-only, no what) and level-4 (both present): above 2 because the when-clause is explicit and the domain names the content, below 4 because there is no real 'what'.

Trigger Term Quality

"Iced", "UI", "building", and "debugging" are natural trigger terms, but the description omits common variations and synonyms a user would plausibly say: "GUI", "iced-rs", "Rust GUI", "widget", or "app". Coverage rests on a single domain noun, matching 'some relevant keywords but missing common variations or synonyms' rather than the 'good coverage, a few terms missing' anchor.

Distinctiveness Conflict Risk

"Iced UI" carves out a clear niche — the Iced Rust GUI framework — and the trigger would not fire for egui, GTK, or other UI toolkits, so conflict risk is minimal. It matches the 'clear niche with distinct triggers' anchor.