UX Baseline Check

Core pack — always active for visual work. Enforces UX quality standards on any screen, flow, form, or dashboard. Ensures nothing ships with missing states....

Security Scan

An instruction-only UX checklist that is internally consistent with its stated purpose and requests no credentials, installs, or system access; minor metadata/wording mismatches do not indicate malicious behavior.

Purpose & Capability

The name, description, and SKILL.md all describe a UX checklist for frontend visual work; nothing requested (no env vars, no binaries, no installs) is out of scope for that purpose. Minor inconsistency: the prose repeatedly calls this a "core" and "always active" pack, but the registry flags show always: false — the claim of automatic always-on activation is not reflected in the metadata.

Instruction Scope

Runtime instructions are a human-facing checklist and process guidance. They do not instruct the agent to run commands, read files, access environment variables, or send data to external endpoints. The only non-technical directive is to "tell Aaron explicitly" when gaps are documented (an internal workflow instruction, not a technical operation).

Install Mechanism

No install spec and no code files — instruction-only. Nothing is written to disk and there are no download URLs or package installs to evaluate, which is lower risk.

Credentials

The skill declares no required environment variables, credentials, or config paths. There is no disproportionate access requested.

Persistence & Privilege

The SKILL.md claims the pack auto-activates alongside design reviews and is "always active," but the registry flags do not set always: true. The skill is user-invocable and allows autonomous invocation (platform default); this combination is normal. If you expect it to be forced on for all agents, that is not reflected in metadata.

Assessment

This is a low-risk, instruction-only UX checklist that matches its stated purpose. Before installing: (1) Note the mismatch between the README wording ("core / always active") and the registry flag (always: false) — if you want it enforced globally, confirm how that will be configured. (2) The skill references an individual ("Aaron"); confirm that contact is meaningful within your team or adjust the workflow text. (3) Source/homepage are missing; if you require publisher provenance, verify the owner ID or obtain an internal version of the checklist. (4) Because it is instruction-only and requests no credentials, there is no technical risk from installs or env-var exfiltration — treat it as a policy/checklist document and review the wording to fit your org processes before enabling autonomous invocation if you have concerns.

Core Pack — Always Active

This is a core skill. Apply it on ALL visual and frontend work alongside design-review.

Every screen ships with ALL states covered. No exceptions. This is the minimum bar.

The State Inventory

Before any page or component is "done", verify each applicable state exists:

1. Data States

• Empty — no data yet. Helpful message + clear CTA, not a blank screen
• Loading — skeleton, spinner, or shimmer. Never a white flash
• Loaded — the happy path, obviously
• Error — API failure, network issue. User-friendly message + retry action
• Partial — some data loaded, some failed. Don't hide what works
• Long content — what happens with 200 items? 2000-character names? Test it

2. Interaction States

• Hover — every clickable element has a hover state
• Focus — keyboard navigation works, focus rings visible
• Active/pressed — buttons respond to clicks visually
• Disabled — grayed out with clear reason why (tooltip or helper text)
• Selected — multi-select, current tab, active filter all visually distinct

3. Form States

• Validation — inline errors on blur, not just on submit
• Required fields — clearly marked
• Success feedback — user knows their action worked (toast, inline, redirect)
• Destructive confirmation — delete/remove actions require confirmation
• Autofill — doesn't break layout when browser autofills

4. Responsive

• Mobile (375px) — usable, not just visible. Touch targets ≥48px with ≥8px spacing between them
• Tablet (768px) — layout adapts, not just shrinks
• Desktop (1280px) — the primary target, looks intentional
• Wide (1800px+) — content doesn't stretch absurdly. Max-width or centered

5. Accessibility

• Keyboard nav — can reach all interactive elements with Tab
• Screen reader — semantic HTML, aria-labels on icons, alt text on images
• Color contrast — 4.5:1 minimum for text (use WebAIM checker)
• No color-only indicators — don't rely solely on red/green for status

6. Edge Cases

• First-time user — onboarding or empty state guides them
• Permission denied — user sees why they can't access, not a broken page
• Stale data — timestamps or refresh indicators when data might be outdated
• Concurrent edits — what happens if two people edit the same thing?

How to Use

Run this checklist AFTER the feature works but BEFORE design review. For each missing state, either:

1. Implement it (preferred)
2. Document it as a known gap and tell Aaron explicitly

Never silently skip a state. If it's intentionally deferred, say so.

Quick Pass vs Full Pass

Quick pass (components, small features): States 1-2 only Full pass (pages, flows, shipping features): All 6 sections

The Test

Ask yourself: "What happens if the network is slow, the data is weird, the user is on a phone, or they're using a keyboard?" If you don't know, you haven't finished.