dxe

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 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 behaviour without weakening it.

Feel

• Check input discoverability across keyboard, touch, and fine pointers.
• Motion should be responsive, interruptible where needed, and have a reduced-motion path.
• Delight should improve anticipation, reliability, or care—not add novelty without purpose.

Bridge

• Check that design structure maps deliberately to code, tokens, primitives, rendering, and accessibility.
• Flag one-off values or abstractions that fight the existing system.

Shipping

• Exercise relevant loading, empty, error, auth, validation, focus, metadata, and repeat-use paths.
• Separate prototype shortcuts from confirmed release risks.
• Look for tests around critical contracts rather than requiring blanket coverage.

Progressive sibling routing

Load a sibling SKILL.md only when the materials map, initial evidence, or requested depth triggers it. Collection siblings are installed adjacent to this skill, so first resolve ../<skill-name>/SKILL.md before treating a lens as unavailable. If a sibling exists and is readable, use its content even when this session’s discovery registry omits it. A registry refresh is needed only to expose it as a separately invocable skill, not to continue the current pass. If neither discovery nor the adjacent path provides a readable skill, continue with the shared rubric, disclose the missing lens, and avoid inventing its detailed guidance.

Trigger	Read
Product intent is unclear or decisions need rationale	write-first-design
Decorative, redundant, or cognitively heavy UI	subtractive-design
A Danish functionalist design lens is requested	humane-functionalism
Web forms, menus, dialogs, custom controls, or semantic failures	semantic-html-first
Web responsive layout or CSS/HTML implementation questions	modern-css-html
SwiftUI, UIKit, AppKit, Xcode, or Apple-platform UI	apple-native-ui
Kotlin, Android Gradle, Jetpack Compose, Android Views, or Compose Multiplatform	android-native-ui
Gestures, springs, interruption, or shared-element motion	fluid-design
Weak discoverability, hover-only actions, or input mismatch	interface-affordances
A specific opportunity for useful polish	product-delight
Design/code structure or token translation is breaking down	design-engineering
Consequential interaction behaviour is unspecified or inconsistent	interaction-contracts
A shared component or token model needs a compatibility or migration decision	design-system-evolution
Recurring setup, waiting, or interruption makes repeated work costly	design-for-repetition
Placeholder or uniform content obscures hierarchy or layout decisions	real-content-design
Template-like or AI-generated residue needs judgement	ai-output-judgement
Auth, validation, state, resilience, or release concerns	prototype-to-production

dxe exhaustive is the only mode that requires reading every sibling skill in the routing table.

Severity and confidence

• Critical: blocks a primary task, risks data/security loss, causes a confirmed serious accessibility failure, or breaks production rendering.
• Should fix: confirmed damage to comprehension, navigation, semantics, resilience, or trust with a bounded correction.
• Nice to have: polish, consistency, dormant primitive risk, or non-blocking cleanup.

Every finding must include one confidence tag. Never classify unverified or environment-only observations as Critical. Quote only the smallest useful source snippet and anchor findings to a path or rendered surface.

Report

# dxe pass — [scope]

## Hypothesis
## Evidence collected
## Verified strengths
- [skill or core] path/surface — what should be preserved

## Findings
### Critical
- [confidence] [skill or core] path/surface — issue — bounded fix
### Should fix
### Nice to have

## Cuts
## Proposed changes
## Verification status
## Limits and unresolved observations

Verified strengths are evidence, not consolation: record systems that work and should survive later changes. An empty severity section is acceptable. Findings should never be failure quotas.

Verification recipe

When tools and repository scripts permit:

1. Run the existing typecheck, tests, and production build.
2. Render the primary target and one contrasting viewport, window, device, or form factor.
3. Check clipping/overflow, safe areas/insets, and primary task hierarchy as the platform requires.
4. Record the first meaningful keyboard, touch, pointer, remote, or assistive-technology sequence.
5. Exercise one menu, dialog, sheet, or navigation transition; wait for settled state, then verify state and focus/return.
6. Repeat one motion-bearing task with reduced motion; wait for settlement before recording animation state or counts.
7. Capture the platform's runtime errors: browser console.error/pageerror, Apple simulator/device diagnostics, or Android Logcat errors/fatals. Classify them separately from tooling noise.
8. In fix mode, repeat affected checks and report exact results.

Never mutate production or external systems as part of a review.

Done when

• Scope, hypothesis, non-goals, sampling, and limits are explicit.
• Every phase was considered; only triggered sibling skills were loaded.
• Claims are tied to evidence, severity, confidence, and a path or surface.
• Confirmed product defects are separated from tooling noise and suspicions.
• Existing strengths and subtractive cuts are recorded when warranted.
• Fixes, when authorized, are bounded and verified in proportion to risk.