# dxe

Review interface work in this precedence order:

1. Intent before decoration.
2. Correct semantics and accessibility before visual convenience.
3. Interaction feel before implementation technique; use the most native implementation that preserves the intended feel.
4. Production trust before prototype cleverness.

Read [references/dxe-core.md](references/dxe-core.md) before starting. It is the shared rubric for every mode. Do not load every sibling skill by default.

## Modes

Infer the mode from the request; use `review` when unspecified.

A path after `dxe` scopes any mode to that path. Treat “apply all skills” as `dxe exhaustive`.

| Mode | Scope | Mutation |
| --- | --- | --- |
| `dxe quick` | Shared rubric on one representative surface; load no sibling unless essential | No |
| `dxe` / `dxe review` | Full evidence matrix and representative repo sampling; progressively load triggered siblings | No |
| `dxe fix` | Review, then implement and verify bounded high-confidence fixes | Yes, within the requested scope |
| `dxe exhaustive` | Inspect every available surface and read the full sibling suite | No unless the user also asks to fix |

Review mode is strictly non-mutating. Do not edit files, install dependencies, start external mutations, or change production systems. Read-only inspection and local verification are allowed. In fix mode, preserve unrelated work and existing design-system materials.

## Scope and sampling

Identify the repository or paths, primary user tasks, stack, tokens, primitives, and interaction/runtime libraries. Prefer existing materials over invented replacements.

For a repository review, select representative surfaces rather than implying equal inspection of every screen:

- primary landing or task page;
- content/detail and list/index pages when present;
- one form or mutation flow;
- one overlay, dialog, or menu;
- an available loading, empty, or error state;
- primary and contrasting target form factors, relevant input methods, and reduced-motion variants.

State omissions in the report. In exhaustive mode, enumerate all discoverable surfaces and states before inspection.

## Evidence protocol

Write a short hypothesis and non-goals, then collect the minimum evidence appropriate to the mode. For normal review/fix, record:

| Evidence | Minimum |
| --- | --- |
| Materials | Stack, tokens, primitives, motion/runtime libraries |
| Source | Representative routes and shared components |
| Verification | Existing typecheck/tests and production build, when safe and available |
| Form factors | Rendered primary and contrasting layouts, clipping/overflow, and task hierarchy |
| Interaction | First meaningful input sequence; overlay/menu/sheet state, return, and touch/pointer/keyboard parity where relevant |
| Accessibility | Platform names, roles/traits/semantics, states, focus/return, and reduced motion |
| Production | Loading/error/empty behaviour, platform metadata, and platform-specific runtime logs |
| Confidence | `confirmed-rendered`, `confirmed-source`, `likely`, `unverified`, or `environment-only` |

Do not claim a rendered defect from source inspection alone. If rendering or a check is unavailable, label the limit instead of guessing.

Separate observations into:

1. confirmed product defects;
2. source-level risks;
3. environment or tooling failures;
4. unverified suspicions.

Reproduce a user-facing failure before promoting tooling noise to a product finding. Distinguish browser errors, server errors, expected local-service failures, and framework/tooling warnings.

For checks that trigger a state change, wait for an observable settled condition before recording state. Prefer the target platform accessibility/semantics value, focus destination, transition completion, or animation settlement over an arbitrary delay. Do not report the immediate post-action sample as final evidence when rendering or animation is still in flight.

Choose the verification lane that matches the delivered platform:

| Platform | Required runtime evidence |
| --- | --- |
| Web | Browser `console.error`, uncaught `pageerror`, server logs, responsive overflow, keyboard sequence |
| Apple native | Xcode build/tests when available, simulator/device diagnostics, accessibility inspection, Dynamic Type, target form factors |
| Android native | Gradle build/tests when available, Logcat errors/fatals, semantics/TalkBack checks, font scale, target window sizes |

## Compact cross-phase pass

Consider every phase, but do not manufacture a finding for each one.

### Intent

- State what the interface helps the user accomplish.
- Mark duplicate actions, unexplained chrome, and generated residue for removal.
- Preserve elements whose purpose is clear and useful.

### Platform

- Prefer native elements and state contracts over `div` plus ARIA reconstructions.
- Check navigation/focus order, names, roles, states, disabled behaviour, and form participation.
- Prefer native CSS/HTML where it can express the

…