Mobile Parity

What the source does

• FilesystemNone observedNo reads or writes in the source
• NetworkNone observedNo outbound calls in the source
• ShellNone observedNo commands run in the source
• DependenciesPinnedNothing floats
• SecretsNone foundNo keys in source

Five audit layers

Gates applied: no behavioural pass.

.claude/agents

.claude/skills

.github/CLAUDE.md

CLAUDE.md

apps/backend/CLAUDE.md

import { test, expect } from "../../fixtures/test-base";

apps/web/generated/licenses.json

Audit 0.4.1 · source sha 786d4817799e · 18 Oct 2026Report an issue or request a re-scan

• Publisherkdlbs GitHub organizationOwner of the repository this skill is read from
• Source folderkdlbs/kandev/.agents/skills/mobile-parityThe exact folder we audited
• LicenceAGPL-3.0As the repository states it
• Commit pinned for this verdict786d4817799eA new audit runs when the source changes
• Repository statusNot archivedPushed today
• Sandboxed runNot runSkills are read, not executed; layer L4 is skipped

Its description: 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. Use…

---
name: mobile-parity
description: 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. Use when implementing, planning, reviewing, or testing any new feature, page, component, workflow, form, dialog, sidebar, navigation, dashboard, or visual UI change; if work touches frontend or user-facing UI, this skill must run even when user mentions only desktop or says "new feature".
kandev:
  system: true
  version: "0.51.0"
  default_for_roles: []
---

# Mobile Parity

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](references/kandev-mobile-ui-language.md) 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](references/control-sizing.md). It defines desktop sizes,
touch exceptions, and the sweep procedure.

## When It Applies

Apply when task changes user-facing UI:

- new or changed pages, routes, components, forms, dialogs, drawers, navigation, dashboards, tables, cards, toolbars, editors, settings, onboarding, or visual states
- new frontend behavior attached to backend/API work
- bug fixes where layout, touch behavior, scrolling, or viewport width can affect success

If task has no UI surface, say why this skill does not apply and continue.

## Specification ownership

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.

## Mobile Design Contract

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.

- desktop user outcome and mobile entry point
- nearest shipped mobile exemplar and which interaction/geometry it contributes
- mobile information hierarchy and primary action
- presentation choice: inline, inset bottom drawer, full-height surface, or direct navigation
- surface rationale: why task frequency and content depth make that choice preferable to the alternatives
- single scroll owner, dynamic viewport behavior, safe-area handling, and touch targets
- shared state, view-model, filtering/selection, and business logic versus mobile-specific presentation
- mobile Playwright scenario proving the same user value

For a feature or fix design package, record the desktop and phone composition
as ASCII previews in the plan and relevant UI work orders. Follow
`docs/specs/guide/plans-and-work-orders.md#ascii-ui-previews`; include a compact
preview in the final conversation handoff. During implementation, compare the
rendered phone surface with the assigned preview's structure and annotations.

## Workflow

1. Map affected surfaces.
   - Identify every page, modal, menu, tab, empty state, loading state, and error state the feature touches.
   - Check where desktop layout assumptions can fail: fixed widths, hover-only controls, sidebars, tables, dense toolbars, keyboard shortcuts, overflow, and absolute positioning.
   - Use `rg` to find the nearest existing mobile component and the route's current `useResponsiveBreakpoint` branch. Name the closest curated exemplar from the reference and state which parts are reused.
   - Treat live code as the source of truth for APIs, state, and current behavior. Treat this skill's curated guide and exemplar list as the desired mobile interaction baseline; nearby legacy surfaces that deviate from it need justification, not automatic reuse.

2. Design desktop and mobile behavior together.
   - Preserve capability, data, and state semantics; do not require identical markup or navigation.
   - Apply the surface decision guide in the mobile UI language reference. Prefer a focused, one-dimensional phone flow over stacked desktop panes or two-axis scrolling.
   - Explicitly distinguish temporary choices that belong in a drawer from primary or dense content that deserves direct navigation or a full-height surface.
   - When a card or row has an obvious primary destination and no competing selection, drag, or inline-control behavior, make its body tap perform that action. Otherwise expose an explicit touch control. Put secondary actions behind a visible target, never hover, right-click, or undiscoverable long press.
   - Define mobile navigation, hierarchy, scroll owner, touch targets, truncation, empty/error states, and responsive fallback behavior before coding.

3. Implement responsive UI.
   - Reuse domain hooks, state, view-model derivation, filtering/selection, and action handlers across viewports; keep responsive wrappers focused on presentation. Branch composition when the desktop interaction model depends on width or a fine pointer. Do not mount a heavyweight desktop workbench and merely hide or squeeze it on phones.
   - Use `useResponsiveBreakpoint` and existing `@kandev/ui` or mobile primitives. Reuse current Dropdown/ContextMenu primitives for contextual actions; use `Drawer` or an existing picker shell for structured phone navigation and choices. Use `useTouchDrawer` when a hover disclosure needs

Excerpt, first 6,000 characters of SKILL.md, verbatim from the audited commit. It is text from someone else’s repository, quoted so you can judge it before your agent reads it.

git clone https://github.com/kdlbs/kandev
git -C kandev checkout 786d4817799e

Works in

1. 2026-10-18
   !CAUTION B 89 / 100

   first audit · source 786d4817799e

Questions about Mobile Parity

• github.com/kdlbs/kandev/tree/main/.agents/skills/mobile-parity — the audited source at commit 786d4817799e and every finding aboveObserved · 18 Oct 2026

Spotted something wrong? Report a correction · Methodology