// UI verification criteria, structure checklists, severity definitions, and tolerance rules for comparing implementations against Figma designs. Use for verifying UI matches design, understanding what to check, and determining acceptable differences.
[HINT] Download the complete skill directory including SKILL.md and all related files
| name | tsh-ui-verifying |
| description | UI verification criteria, structure checklists, severity definitions, and tolerance rules for comparing implementations against Figma designs. Use for verifying UI matches design, understanding what to check, and determining acceptable differences. |
| user-invocable | false |
Verification process, criteria, and tolerances for comparing UI implementations against Figma designs.
Use the checklist below and track your progress:
Progress:
- [ ] Step 1: Validate inputs
- [ ] Step 2: Get EXPECTED from Figma
- [ ] Step 3: Get ACTUAL from implementation
- [ ] Step 4: Compare using verification categories
- [ ] Step 5: Generate report
Step 1: Validate inputs
Before starting verification, confirm:
package.json scripts, .env, vite.config, next.config, etc.) for the configured portps, netstat, or lsof output — multiple services may run on different ports and you cannot reliably distinguish frontend from backend.playwrightStep 2: Get EXPECTED from Figma
Use figma to extract the design specifications:
Step 3: Get ACTUAL from implementation
Use playwright to capture the running implementation. You MUST collect all three types of data — a verification that skips any type is incomplete:
specifications/<task-id>/screenshots/) with descriptive filenames including the component name and iteration number (e.g., establishment-details-form-iteration-1.png). This creates a visual audit trail for each verification cycle.CRITICAL: The accessibility tree does NOT contain CSS dimensions. A full-width container and a narrow centered container produce identical accessibility trees. If you only collected structure without measuring actual rendered dimensions, your verification is INVALID — mark confidence as LOW and report what's missing.
Step 4: Compare using verification categories
Compare EXPECTED (Figma) against ACTUAL (implementation) following the Verification Order and Categories below. The Figma design is the source of truth for every comparison. When in doubt, the design wins.
IMPORTANT: Complete ALL verification categories in a single pass. Do not stop after finding differences in one category — continue through every category and collect every difference. The report must contain ALL differences found across all categories so the engineer can fix them all at once, minimizing verification iterations.
Step 5: Generate report
Produce a structured report following the Report Format below. Include exact values from both Figma and implementation for every difference found.
Always verify in this order — complete ALL categories regardless of findings. Do not stop after finding differences in one category. The goal is to catch every difference in a single pass so all fixes can be applied at once.
| Check | Description |
|---|---|
| Container hierarchy | Does DOM structure match Figma's layer hierarchy? |
| Nesting depth | Are elements nested at the same level as in Figma? |
| Grouping | Are related elements grouped together as in design? |
| Element order | Is the visual order of elements the same? |
| Wrapper elements | Are there extra/missing wrapper divs that change layout? |
| Sections present | Are ALL sections from Figma present in implementation? |
| Check | Description |
|---|---|
| Flex/Grid direction | row vs column, wrap behavior |
| Alignment | justify-content, align-items values |
| Distribution | How space is distributed between elements |
| Positioning | relative, absolute, fixed - matches design intent? |
| Centering | Is content centered as in design? |
| Check | Description |
|---|---|
| Container width | max-width, fixed width constraints |
| Card/panel boundaries | Does card have same width as in Figma? |
| Content area vs viewport | Ratio of content width to available space |
| Width/Height | Fixed, percentage, auto, min/max constraints |
| Spacing | Padding, margin, gap between elements |
| Gaps | Space between flex/grid children |
WARNING: Accessibility tree does NOT contain CSS dimensions. A full-width container and a narrow centered one look identical in it. You must measure actual computed styles to detect width/sizing differences.
| Check | Description |
|---|---|
| Typography | font-family, size, weight, line-height, letter-spacing |
| Colors | Text, background, border colors |
| Radii | border-radius values |
| Shadows | box-shadow, drop-shadow |
| Backgrounds | Solid, gradient, image |
| Check | Description |
|---|---|
| Correct variants | Is the right variant of a component used? |
| Design tokens | Are correct tokens used (not hardcoded values)? |
| States | hover, focus, active, disabled states |
| Category | Tolerance | Notes |
|---|---|---|
| Structure | None | Any structural difference = FAIL |
| Layout direction | None | row vs column must match exactly |
| Alignment | None | Centering, justify, align must match |
| Dimensions | 1-2px | Only for browser rendering variance |
| Colors | Exact match | Must use correct design tokens |
| Typography | Exact match | Font properties must match |
| Spacing | 1-2px | Only for browser rendering variance |
| Severity | Description | Action |
|---|---|---|
| Critical | Structure/layout differences, wrong component used | Must fix immediately |
| Major | Dimensions off by >2px, wrong colors/typography | Must fix before merge |
| Minor | 1-2px browser rendering variance | Acceptable, document if recurring |
Before reporting PASS:
## Verification Result: [PASS | FAIL]
### Component: [name]
**Confidence:** [HIGH | MEDIUM | LOW]
### Differences
| Property | Expected (Figma) | Actual (Implementation) | Severity |
| -------- | ---------------- | ----------------------- | ---------- |
| [prop] | [expected] | [actual] | [severity] |
> **List ALL differences found across ALL verification categories.** Do not omit lower-severity items when critical ones exist. The engineer needs the complete list to fix everything in one iteration.
### Recommended Fixes
- [specific fix with exact values]
Confidence levels:
tsh-implementing-frontend - for implementing fixes following design system patternstsh-technical-context-discovering - for understanding project's design token conventions