사용 방법
- 설치 명령을 복사하고 자신의 에이전트 환경에 설치하기 전에 소스 패키지를 확인하세요.
- 필요한 도구, 인증 정보, 지원 환경은 원본 문서에서 확인하세요.
- 입력과 원하는 산출물을 설명하고 출처와 결과를 대조하세요.
npx skills add https://github.com/aa-on-ai/agentic-design-system --skill ux-baseline-check시작 전 확인
- 설치에는 모델 구독, API 한도, 파일 접근 권한이 포함되지 않습니다.
- 별점 수와 설치 수는 활동 지표이며 독립적인 품질·보안 검증이 아닙니다.
원본 저장소의 제목, 예시, 코드, 표, 링크, 이미지를 유지해 표시합니다.
UX Baseline Check
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
- [ ] Adjacent-action consistency — when a state is read-only, disabled, offline,
permission-limited, or destructive, inspect every nearby primary, secondary, toolbar, and inline action. Remove, relabel, or visibly explain contradictions; use native disabled semantics when an inactive control remains visible, and preserve active actions in unaffected states.
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:
- Implement it (preferred)
- Document it as a known gap and tell the user 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.
