Usage is not quality. In eligible Claude Code terminal sessions, /skill-doctor reports past invocations and listing cost. It does not establish that a screen improved. Compare one invoked skill with the same no-skill brief. See the check.

Dashboard choice. For an existing-system dashboard, begin with the user decision, real data, units, freshness, components, tokens, and empty or error states. Try a careful no-skill brief before adding a design skill. See the dashboard decision.

Invocation before outcome. For Claude Code, confirm the skill is available and its full instructions were invoked. An installed file alone is not evidence that it guided the screen. See the check.

Instruction revision tests. A screenshot comparison between two versions can test wording under one setup. It cannot show whether adopting the current skill beats a no-skill brief or preserves a working flow. See the Frontend Design example.

Exact source and revision. We record an original publisher, immutable commit or declared version, license, stated requirements, and last check. When the skill source is mutable, we say so; a plugin version is not a substitute for a skill-file pin.

Fetched review rules. For Web Design Guidelines, the pinned skill still fetches changing rules. Record the skill commit and the fetched rules commit. Heka News documents one local-copy approach; its record does not prove a better UI review.

Package validity and contents. Check that the visible skill metadata renders without a parser error, identify the target-agent path, and inspect bundled files before installation. A method can look useful and still be a bad adoption choice if the package cannot be identified reliably. This check does not prove the method works.

Existing-system design work. When an existing system already constrains the work, record one direction, the route, tokens and constraints, relevant states and widths, local checks, and rendered evidence. That can be a better fit than generating options. It is still not proof that a borrowed instruction installed, loaded, or improved the result.

Image-based direction selection. An image-based direction skill needs plugin availability, a minimum brief, relevant references, generated alternatives, and a human selection. It does not prove that the selected direction is usable, on-brand, accessible, or faithfully implemented.

Project preview and live route. A project-bound local preview can help a person choose tokens, copy, and element-level changes before implementation. It is not evidence that the live route matches, works at required widths, or supports keyboard use. Compare it with the real route after applying the decision packet.

Ready-made versus source-derived. A pipeline that reads your design system and generates a skill is not a ready-made skill. For an existing-system task, compare a precise repository brief with a constrained ready-made skill before paying the cost to generate and maintain a project-specific one. Vercel Labs documents such a pipeline, but this pool has not tested its output.

Outcome comparison. Name unwanted visual defaults before the run and inspect the actual render; a shape count alone is not a quality score. For a substantial task, compare the candidate skill with a careful no-skill brief on the same project and model. Keep the source revision, loading method, acceptance checks, rendered result, and token cost. WebDev-Skills-Bench found that functional skill effects barely transferred between its four models. Its prompt-injection setup and functional tests cannot rank these listings or measure design quality.

Evidence categories. Author guidance, community reports, and pool verification are different evidence tiers.

Task fit. Visual-direction selection, concept-led build, visual direction, design-and-build state modeling, project-bound visual feedback, component refactor, motion, state capture, exploratory QA, captured flow audit, code review, and performance review are different jobs.

Required product states. For a substantial product surface, record the user and screen job, project components and tokens, real content, relevant empty, error, busy, success, and recovery states, viewports, and input methods. A happy-path screenshot does not certify a design system, accessibility, or resilient behavior.

Browser evidence requirements. A browser check needs a runnable target, isolated session, named route, retained output, backend, viewport, and session context. Targeted QA also needs one interaction and expected rendered state. Exploratory QA needs a reachable target, replayable repro evidence, and review of each finding. A flow audit needs a known journey and accepted screenshots. A code-first review needs the relevant files.

Required tools and artifacts. A browser capture or QA report is evidence to inspect, not a verdict on the design. If required tools are unavailable, the workflow does not fit the current environment.

Update check. If you changed an installed skill, keep the source revision and your local diff. For the inspected Vercel Skills global-update path, “up to date” compares upstream with the lock, not installed files. Check the installed SKILL.md, bundled files and copy or symlink layout after an update. Read the scope and evidence.

Project context. A borrowed skill cannot reliably infer the components, tokens, constraints, state model, and view states that define your product. Name them before asking a workflow to judge consistency.