dxe
Review interface work in this precedence order:
- Intent before decoration.
- Correct semantics and accessibility before visual convenience.
- Interaction feel before implementation technique; use the most native implementation that preserves the intended feel.
- 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:
- confirmed product defects;
- source-level risks;
- environment or tooling failures;
- 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
divplus 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
markdown# 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:
- Run the existing typecheck, tests, and production build.
- Render the primary target and one contrasting viewport, window, device, or form factor.
- Check clipping/overflow, safe areas/insets, and primary task hierarchy as the platform requires.
- Record the first meaningful keyboard, touch, pointer, remote, or assistive-technology sequence.
- Exercise one menu, dialog, sheet, or navigation transition; wait for settled state, then verify state and focus/return.
- Repeat one motion-bearing task with reduced motion; wait for settlement before recording animation state or counts.
- 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. - 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.
