| name | fabrico-improving-ui |
| description | Audit and verify existing web, iOS, Android, and shared-mobile UIs using runtime evidence, platform conventions, accessibility, prioritized findings, and before/after comparisons. Use for UI improvement audits, mobile visual reviews, responsive checks, or cross-platform UI verification without requiring Figma. |
Improving UI
Provides the cross-platform audit and evidence rules used when improving an existing product UI. Apply it to web,
iOS, Android, React Native, Flutter, Kotlin Multiplatform, and other shared-mobile projects without assuming that a
Figma design or browser target exists.
This skill audits an existing platform. It does not authorize creating a missing application target, inventing a
new visual language, or changing product behavior.
Audit Process
Use the checklist below and track progress:
UI improvement audit:
- [ ] Resolve platforms and coverage
- [ ] Establish product and design intent
- [ ] Capture a rendered baseline
- [ ] Audit and prioritize findings
- [ ] Classify the authorized change set
- [ ] Verify comparable after-state evidence
1. Resolve platforms and coverage
Detect the actual web, iOS, Android, and shared-code targets. Build a matrix of requested platforms, screens,
flows, states, themes, device classes, orientations, and accessibility conditions. Mark absent requested targets as
NOT PRESENT. State whether coverage is exhaustive or sampled.
2. Establish intent
Use approved specifications and designs, the existing design system and tokens, platform conventions, and available
research. An approved design is authoritative only for its stated scope. Record accessibility, usability, or
product conflicts instead of silently reproducing them. Without a design, preserve the existing visual direction.
3. Capture a baseline
Prefer a current build on a supported browser, simulator, emulator, or device. Exercise representative default,
loading, empty, error, validation, disabled, selected, focus, keyboard, text-scaling, theme, responsive, safe-area,
permission, and rotation states where supported. Collect screenshots, accessibility evidence, interactions, and
relevant runtime diagnostics.
Label each finding OBSERVED or INFERRED. Source, preview, snapshot, or stale screenshot inspection is secondary
evidence and must not be described as rendered or interaction verification.
Read and apply only the relevant platform UI audit checks.
4. Audit and prioritize
Record each finding with platform and screen, evidence, issue, user impact, recommendation, severity, confidence,
effort, implementation risk, authority class, affected scope, and verification method.
Use this severity scale:
CRITICAL — prevents a core task or creates a serious accessibility, safety, or unusable-layout failureMAJOR — materially harms usability, accessibility, responsive behavior, or an important stateMINOR — a limited, non-blocking defect with clear evidenceOPPORTUNITY — an optional enhancement rather than a defect
Prioritize user impact over cosmetic preference. Do not present taste as evidence.
5. Classify the change set
AUTO — objective, high-confidence, local, reversible, and preserves behavior, information architecture, brand,
existing tokens, dependencies, and public contractsAPPROVAL REQUIRED — subjective, broad, behavioral, brand, navigation, copy, dependency, asset, design-token,
cross-platform parity, public-contract, or otherwise high-impact changeDEFERRED — unsupported, out of scope, explicitly declined, or accepted for later
6. Verify the after state
Repeat the same platform, screen, state, device, theme, interaction, and accessibility matrix used for the baseline.
Capture comparable before/after evidence and run the project's relevant lint, type-check, unit, integration, UI,
snapshot, screenshot, build, and platform checks. A passing build is necessary evidence where applicable, but not
proof of visual quality by itself.
Allow at most three complete correction cycles. Re-run affected evidence after every correction.
Evidence Confidence
| Confidence | Minimum evidence |
|---|
HIGH | Current rendered target, representative states and interactions, relevant accessibility checks, and executable project gates |
MEDIUM | Current screenshots or recordings plus source inspection and successful build or tests, but no interactive target inspection |
LOW | Source, design, preview, snapshot, or stale captures only |
Do not make subjective visual changes from LOW-confidence evidence. Do not mark a platform VERIFIED without
HIGH-confidence after-state evidence.
Completion States
VERIFIED — runtime visual, interaction, accessibility, and required project checks passedPARTIALLY VERIFIED — safe work completed but runtime, device, state, screenshot, or assistive-technology evidence is incompleteNOT PRESENT — the requested target is absentBLOCKED — no safe implementation or verification path exists
Connected Skills
fabrico-technical-context-discovering — target and project convention discoveryfabrico-implementing-frontend — compatible web and shared-framework implementation patternsfabrico-ensuring-accessibility — detailed web accessibility checksfabrico-ui-verifying — strict web Figma-versus-running-app comparison onlyfabrico-reviewing-frontend and fabrico-code-reviewing — implementation review
