This Skill only performs review; it does not design from scratch, modify code in bulk, or review engineering issues unrelated to interface design.
Default stance:Passing requires evidence, and problems also require evidence.
1. Review Scope
- User tasks and navigation;
- Adaptation for phones, tablets, foldables, PCs, wearables, smart screens, and car machines;
- Input from touch, mouse, keyboard, remote control, etc.;
- Normal, disabled, pressed, focused, activated, and hovered states of controls;
- Visual Tokens, vp/fp, large fonts;
- Motion purpose, curve, duration, follow-finger, speed, and interruptibility;
- Truthfulness of asynchronous states;
- Accessibility;
- Animation performance;
- Stable principles and versioned platform layers;
- Evidence from interactive prototypes and real implementations.
2. Out of Scope
For the following requests, state that they are not applicable and point to general engineering review:
- HAP/APP signing;
- Compiler errors;
- Networking, permissions, databases;
- Non-UI business logic;
- Design specifications of other mobile platforms;
- Directly implementing new features.
3. Establish Context First
Reuse information already provided by the user:
目标设备:
窗口形态:
主要输入:
API_Level:
主题与字号:
任务路径:
证据:
假设:
When missing information does not affect the current finding, do not ask repeatedly. Conclusions with insufficient evidence should be marked as low confidence.
4. Thirteen Non-Negotiable Standards
- Clear navigation. Users know where they are, where they are going, how to go back, and how to exit.
- Cross-device is not proportional scaling. There must be a specific adaptation strategy.
- System first. Customization must not weaken system states and accessibility.
- Complete input states. Under the target input, pressed, focused, hovered, activated, etc. must be distinguishable.
- Immediate feedback. There is local feedback during the press phase.
- Continuous gestures. Follow-finger, release velocity inheritance, and target changes must be interruptible.
- Motion expresses real relationships. Curves, directions, shared elements, and hierarchy are consistent.
- Asynchronous states do not lie. Pending must not masquerade as Confirmed; success feedback must not precede real confirmation.
- Separation of foundations and versions. The current visual language must not overturn direction sense, readability, accessibility, and state truthfulness; old principles must not block new platform capabilities either.
- Product context first. Do not turn all products into the same kind of glass, rounded corners, bounce, or "premium feel".
- Executable prototype. High-risk gestures, transitions, and cross-device solutions must not pass based on static mockups alone.
- Accessible. Non-text semantics, states, focus, large fonts, and custom-drawn content must be usable.
- Performance has evidence. Avoid hand-written per-frame animation, continuous layout animation, and redundant refreshes, and validate on real devices.
Detailed review criteria are set out in references/STANDARDS.md。
5. Issues that warrant immediate escalation
Typically marked as BLOCKER or MAJOR：
- A key page has no way to go back or exit;
- core actions are clipped on tablets or with large fonts;
- core buttons have no pressed feedback;
- the velocity drops to zero after a gesture is released, causing a noticeable pause;
- input is locked during animation;
- shared transitions and the default Navigation transition are stacked;
- success is displayed or announced before a remote request is confirmed;
- icon buttons have no accessible name;
- focus traps;
- high-frequency gestures modify
width/height； - House Style is claimed to be official rules;
- current visual trends are used as a reason to remove necessary contrast, focus, or directionality;
- high-risk gestures have only static comps, with no runnable prototype or target-device evidence.
6. Fix priority
- Fix tasks, navigation, and state truthfulness;
- restore system default capabilities;
- fix cross-device and input;
- fix accessibility;
- remove purposeless motion;
- fix tracking, velocity, and interruption;
- unify semantic tokens;
- optimize performance;
- finally handle brand micro-motion.
7. Required output format
Context card
List known conditions and assumptions.
Findings table
| Priority | Rule ID | Evidence | Issue | User impact | Recommendation | ArkUI touchpoint | Source level | Confidence |
|---|
One issue per row. Issues without evidence do not go into Findings.
Impact summary
In the following order, output only non-empty categories:
- Tasks and navigation;
- asynchronous truthfulness;
- cross-device and input;
- gestures and motion;
- accessibility;
- performance;
- stability principles and platform versions;
- visual consistency;
- prototypes and evidence;
- to be verified.
Minimal fix plan
Give dependency order, scope of changes, and verification methods; do not directly rewrite the entire project.
Conclusion
Can only be:
- Fail: Blocker exists;
- Conditional pass: no Blocker, but unresolved Major issues exist;
- Pass: no Blocker/Major, and evidence exists for key devices, input, font sizes, accessibility, and performance.
8. Source wording
- H1: Huawei official;
- H2: OpenHarmony official;
- H3: official observation;
- H4: project recommendation.
Do not write 0.97, unified springs, staggered entrances, glass materials, etc. as official HarmonyOS requirements.
9. Anti-homogenization check
For each review, add:
应保留的产品特征：
不应套用的通用风格：
允许的 House Style：
The goal of the review is appropriateness, not trendiness.