Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →kdlbs/mobile-parity
Ensures Kandev UI work uses native mobile interaction patterns instead of compressed desktop adaptations while preserving desktop/mobile capability parity, responsive behavior, and mobile Playwright E2E coverage.
Passed 20 of 22 test cases with the skill, and 13 of 22 without it.
and 8 more in the full report
8 fixed12 passed either way1 still failing1 broke
Tokens, turns and time describe resource use, not a dollar price.
This benchmark measured an earlier version of the skill.
A newer attempt on gemini-3.6-flash on 10/2/2026 did not produce a publishable comparison (not comparable). The snapshot above is the previously measured run.
One of 8 test cases the skill fixed. Same model, same prompt, with and without the skill.
When running Playwright mobile E2E tests against local frontend changes, should we point Playwright directly at the Vite dev server (`localhost:5173`)?
| Checked | Without skill | With skill |
|---|---|---|
| Requires rebuilding production web and backend binaries before executing Playwright tests. | Missed | Passed |
The instructions your model reads when the skill loads.
Use this skill before planning or changing UI. Goal: desktop and mobile deliver the same user value, while each viewport gets an intentional composition and tests prove the mobile path.
Before proposing a mobile design, read Kandev Mobile UI Language and inspect the closest shipped mobile surface. Responsive CSS alone does not establish mobile parity.
For buttons, single-line inputs, selectors, or control-size audits, also read Control sizing. It defines desktop sizes, touch exceptions, and the sweep procedure.
Apply when task changes user-facing UI:
If task has no UI surface, say why this skill does not apply and continue.
When the task uses durable specifications, put mobile outcomes in the system that owns the feature contract. Do not create a second UI requirement or design only because the feature needs a phone surface. Use the UI system only for an independent reusable interaction contract.
Keep the mobile composition in the owning feature design with its backend and desktop boundaries. Link to an existing UI contract when the feature reuses one.
When a task changes composition, navigation, overlays, touch behavior, scrolling, or breakpoint behavior, state these choices in the working plan or task notes. Keep them brief; do not create a separate document unless the task already uses a spec or plan. For copy, icon, color, or content-only styling inside an unchanged surface, identify the nearest mobile exemplar and the rendered mobile check instead of forcing the full contract.
test cases passed, vs 13 / 22 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.