Conciseness

The "Built-in Functions (GLSL)" table restating `abs`, `sign`, `sin`, `cos`, `mix`, `pow`, `sqrt` etc. is knowledge Claude already has, and the header "**Version:** makepad-widgets (dev branch) | **Last Updated:** 2026-01-19" is time-sensitive information outside any deprecated/old-patterns section. Most other tables (Sdf2d functions, `self.pos`/`self.rect_size` built-ins) are genuinely niche Makepad knowledge that earns its place, so this sits between anchors 3 and 4 rather than at 2.

Actionability

Four complete, copy-paste-ready shader examples (solid color, rounded rect with border, gradient, circle) plus concrete rules ("Always use `show_bg: true`", "Use `Sdf2d::viewport()` to create SDF context") make the core writing task fully executable. Not 5 because the "Advanced Patterns" table lists pattern names ("01-shader-structure", "05-progress-track") with no usable file paths or instructions for what to do with them, leaving the advanced guidance not directly actionable.

Workflow Clarity

The "Documentation Completeness Check" gives a clear sequenced decision flow with an explicit failure fallback: read references → "If file read fails or file is empty: Inform user... Still answer based on SKILL.md patterns + built-in knowledge" → otherwise incorporate. Not 5 because there is no validation or verification step for generated shader code and the code-writing path has no sequence; not 3 because the failure checkpoint is explicit, not implicit.

Progressive Disclosure

The body clearly signals one-level-deep references ("`./references/shader-basics.md` - Shader language fundamentals", "`./references/sdf2d-reference.md` - Complete Sdf2d API reference", "`_base/` directory", "`./community/"), but the actual bundle contains none of these files or directories — every external pointer is dangling, so navigation fails outright despite the good in-file sectioning. This is worse than anchor 3's "references present but not clearly signaled" because the referenced content is entirely absent from the bundle.

Specificity

"Use for Makepad shader system" names the domain but lists zero concrete actions — no writing, explaining, or debugging capabilities appear anywhere in the description; the remainder is a keyword trigger list, not a capability statement. This matches anchor 2 ("Names the domain but actions are minimal or generic") rather than 3, which requires 1-2 concrete actions to be named.

Completeness

Both parts are present: the "when" is fully explicit ("Triggers on: makepad shader, Sdf2d, draw_quad...") with concrete trigger phrases, while the "what" is only domain-level ("Use for Makepad shader system") without naming what the skill actually does. Falls between anchor 3 (what clear, when missing) and anchor 5 (both explicit) — the explicit trigger list lifts it above 3, but the unnamed capabilities keep it below 5.

Trigger Term Quality

Good keyword coverage: "makepad shader, makepad draw_bg, Sdf2d, makepad pixel, makepad glsl, makepad sdf, draw_quad, makepad gpu, makepad 着色器" plus Chinese variants covers many ways a user would phrase the need, including non-English synonyms. Not 5 because most terms are permutations of "makepad + X" and natural standalone phrases users might say (e.g. "custom shader", "shader syntax help") and file extensions are absent.

Distinctiveness Conflict Risk

The trigger set is almost entirely Makepad-qualified ("makepad shader", "makepad glsl", "makepad gpu", "makepad 着色器") and "Sdf2d" is a term essentially unique to Makepad, giving this a clear niche with minimal conflict risk. Only "draw_quad" could plausibly arise in another GPU framework, which is too minor to drop it from anchor 5.