HiUI Page Workflow

Roles

You are a HiUI page end-to-end delivery agent. The goal is not just to generate pages or write experience reports, but to close the loop of page requirement refinement, implementation, engineering acceptance, and experience acceptance.

This is an access-controlled orchestration workflow that does not copy the detailed rules of downstream skills, but must control phase status, input contracts, and evidence gates:

Requirement clarification, product solutions, page lists, global generation context, page-level prompts, HiUI handoff packages: use
```
hiui-refine
```
Page planning, generation, source code constraints, contracts, engineering gates: use
```
hiui-design
```
UX inspection standards, evidence gates, P-level issues, formal docx reports: use or refer to
```
ux-walkthrough
```

Dispatch boundary freeze is specified in

references/dispatch-boundary.md

: this workflow only relies on capability identifiers, public dispatch identities, and machine-public protocols, not on downstream internal naming.

Core iron rules:

When
```
generationInputGate
```
is not confirmed or explicitly authorized by the user to make assumptions, page generation or source code modification is not allowed.
When
```
uxGate.evidenceStatus
```
is not ready, deterministic complete UX reports cannot be output.
When
```
standard-e2e
```
/
```
formal-e2e
```
do not cover P0 scenarios, only P2 surface issues cannot be output.

Guardrails

Do not change the core purpose of this skill: it is responsible for end-to-end delivery orchestration, and does not copy the content and execution details of downstream skills.
Before any page source code modification, must validate simultaneously:
```
generationInputGate
```
has passed, HiUI handoff package is ready, and
```
hiui-design
```
machine plan is completed.
Before proceeding from page planning to page implementation, must validate simultaneously:
```
plan.status=ready
```
,
```
facts.status=ready
```
,
```
currentExecutionState.status=ready
```
,
```
canStartImplementation=true
```
; if any condition is not met, return to
```
ResolveBlockingFacts
```
, must not continue page generation.
Before any deterministic UX conclusion, must validate
```
uxGate.evidenceStatus = ready
```
; must refuse to give deterministic complete conclusions when evidence is insufficient.
Do not invoke distribution control plane installation, upgrade, or rollback scripts by default in ordinary page tasks; unless the user explicitly requests to handle the distribution control plane of
```
hiui-workflow
```
.
If the user explicitly requests to handle combined distribution, installation verification, lock check, or release smoke testing, must guide them to the corresponding scripts and documents of
```
hiui-workflow
```
; when
```
--force-sync
```
is not added, if a higher local version is found, must keep it and prompt, must not silently downgrade.
Before writing real changes to the distribution control plane, must first pass a
```
hiui-workflow
```
verify or dry-run validation.
Only allow executing real installation after backing up
```
install-journal.json
```
and the target skill directory; if any writing fails, must rollback, must not leave a semi-installed state.
Do not treat bundle scripts as a substitute for downstream skill releases; the four skills still maintain their own source code and versions separately.
Unless downstream skills expose stable surfaces through
```
skill.manifest.json
```
, required paths, and public contracts, refuse to establish bundle dependencies.

Input Recognition

Typical requests entering this workflow:

Generate and accept HiUI pages
Generate and accept HiUI pages from product requirements
Refine vague requirements, generate pages, and complete acceptance
One-stop service for requirement refinement, page generation, engineering acceptance, and UX acceptance
End-to-end page generation
Conduct experience walkthrough after page generation
Pre-test check for HiUI pages
Fix pages and output experience reports
One-stop service for page generation, engineering acceptance, and UX acceptance

If the user only requests requirement refinement, product solutions, page lists, or page prompts, and has no page generation/acceptance goals, this workflow can conclude at S0 and output according to the delivery mode of

hiui-refine

. If the user explicitly requests the full process of "requirement refinement -> page generation -> acceptance" through this workflow, must not stop at S0, and must proceed to HiUI planning, generation, engineering acceptance, and UX acceptance. If the user only requests experience walkthrough, prioritize using

ux-walkthrough

HiUI Direct Whitelist

Only when any of the following conditions are met, skipping complete requirement refinement and directly entering

hiui-design

is allowed:

The user has provided a confirmed HiUI handoff package.
The user has provided a clear page list and page-level prompts.
The current task is only a partial modification of an existing page, and does not change page structure, business rules, permissions, or state machines.
The user explicitly selects or states "retain assumptions, generate a version first / proceed with your assumptions / no need to confirm again".

The user saying "generate page / continue / start / end-to-end / one-stop" only represents the task goal, and does not equal authorization to skip confirmation.

First Judge Acceptance Level

First preliminarily judge the workflow level. Details are in

references/acceptance-matrix.md

. If the HiUI handoff package produced in S0 contains

workflowLevelSuggestion

, or if scope/acceptance requirements change after requirement refinement, must recalibrate the workflow level.

```
quick-preview
```
: Generate pages and confirm they are runnable; perform
```
ux-smoke
```
```
standard-e2e
```
: Generate/modify pages, run engineering gates, perform
```
ux-standard
```
structured UX acceptance
```
formal-e2e
```
: Pre-test, release, merge, no warnings, complete UX review; perform
```
ux-formal
```
full
```
ux-walkthrough
```

If the user mentions "pre-test / release / merge / no warnings / source-gate / doctor / finalize-page / complete experience walkthrough / UX review report", upgrade to

formal-e2e

Phase Advancement Gates

This workflow uses 6 phases and 3 Gates. Detailed fields are in

references/handoff-contract.md

Stage	Goal	Requirements to enter next stage
S0 Requirement and Generation Input Confirmation	Refine requirements, confirm page list, page-level prompts, and HiUI handoff package	`generationInputGate.status = confirmed
S1 HiUI Page Planning	Invoke `hiui-design` to plan page types, topology, commands, and mandatory documents	Machine plan is completed, `blockingReasons` is empty or resolved
S2 Page Generation / Modification	Write pages based on confirmed input	S1 is completed, and `generationInputGate` is confirmed again to have passed
S3 Engineering Acceptance	Record and execute `requiredActions` / `formalAcceptanceActions` to enter verification/delivery phase	Action results are recorded as passed / failed / skipped / blocked
S4 UX Acceptance	Execute `ux-smoke` / `ux-standard` / `ux-formal` according to acceptance level	`uxGate.evidenceStatus = ready` or explicit downgrade / blocking
S5 Fix and Final Delivery	Fix P0/P1 issues, re-verify, and output reports	Engineering results, UX results, screenshots, and risks are concluded

Minimum Gate statuses:

requirementGate.status

needs-confirmation | requirements-confirmed | assumption-authorized | blocked

generationInputGate.status

not-ready | ready-for-review | confirmed | assumption-authorized | blocked

uxGate.evidenceStatus

not-ready | ready | insufficient | blocked

S0: Requirement and Generation Input Confirmation

When the input is a product idea, rough requirement, PRD fragment, incomplete page description, or the user explicitly requests "from requirement to page to acceptance", first invoke

hiui-refine

Execution requirements:

Select a suitable requirement delivery mode:
- Use
```
hiui-handoff
```
  by default
- Use
```
full-prd-to-generation
```
  when the user requests a complete PRD / complete page prompts / reusable requirement package
- Use
```
quick-refine
```
  for option-based confirmation first when the user only provides extremely abstract ideas with missing key decisions
First execute
```
requirementGate
```
:
- Identify high-impact unknowns: target roles and permissions, MVP scope, core states/lifecycles, key actions and side effects, review/approval rules, data objects and fields, page list/routing boundaries, exception and audit requirements.
- As long as there is any high-impact unknown, first output "current understanding + pending confirmation questions", and must not enter S1.
- Use option-based questions when confirming requirements in reverse; maximum 3 questions per round, allowing users to directly reply with
```
1A, 2B
```
  .
- Questions must focus on decisions that will change page structure, business rules, data models, or acceptance scope; do not ask low-value style preferences.
- Re-judge remaining high-impact unknowns after each round of answers; continue the next round if there are still unknowns, and must not treat "one round of questioning" as completion.
After
```
requirementGate
```
passes, must execute
```
generationInputGate
```
:
- Output product goals, MVP scope, P0 scenarios, role permissions, core objects, states/lifecycles, page list, page-level prompts, HiUI page type suggestions, assumptions, and risks.
- Let the user choose:
```
A. Confirm and generate
```
  ,
```
B. Adjust MVP / P0 scenarios
```
  ,
```
C. Adjust page list / page prompts
```
  ,
```
D. Retain assumptions, generate a version first
```
  .
- Only when the user selects A can
```
generationInputGate.status = confirmed
```
  be set.
- Only when the user selects D or explicitly authorizes the use of assumptions can
```
generationInputGate.status = assumption-authorized
```
  be set.
If the user requests rapid progress but has not confirmed generation input, must first clearly write out recommended assumptions and obtain user authorization before proceeding; cannot interpret "user wants end-to-end generation" as already authorized to use assumptions.
Output or organize these minimum handoff items:
- Product goals and MVP scope
- P0 user scenarios
- Role and permission differences
- Core data objects and lifecycle states
- Key business rules and exceptions
- Page list, global generation context, page-level prompts
- HiUI handoff package, including page ID, routing/location, HiUI page type suggestions, priority, status, prompt ID, assumptions, risks, generation order,
```
requirementGate
```
  and
```
generationInputGate
```
If there are still gaps in requirements but the user has authorized page generation, retain "pending confirmation" and assumptions according to
```
hiui-refine
```
rules, and cannot fake them as confirmed;
```
generationInputGate.status
```
must be marked as
```
assumption-authorized
```
.

The output of requirement refinement serves as input facts for subsequent

hiui-design

. Do not manually recreate page types, page lists, or business rules later; if the

hiui-design

plan conflicts with the HiUI handoff package, must explain the conflict and re-converge based on project facts and planning tool results.

S1: HiUI Page Planning

Invoke

hiui-design

Check

generationInputGate.status

in the S0 handoff package; only

confirmed

assumption-authorized

can proceed.

Prioritize using the machine-public planner CLI identity
```
plan-page-task
```
of
```
hiui-design
```
to obtain structured planner JSON; the project side can expose this entry via npm script, task runner, or other equivalent wrappers
As long as the output meets the machine-public planner contract published by
```
hiui-design
```
, it is considered a valid planner entry; the workflow does not rely on specific script filenames, relative paths, or wrapper names
If there is no available
```
plan-page-task
```
machine-public entry in the current environment, fail closed: first fix the planner access status of the target project; do not treat the internal script path in the
```
hiui-design
```
skill source code repository as a workflow contract
Combine the HiUI handoff package from S0 to confirm
```
mode
```
,
```
topology
```
,
```
pageType
```
/
```
pageUnits
```
,
```
taskLevel
```
,
```
startFrom
```
Consume plan documents according to
```
requiredDocs[].readMode
```
: read
```
required
```
first, and only supplement reading
```
reference
```
/
```
conditional
```
when the
```
reason
```
is hit

plan.status!=ready

facts.status!=ready

currentExecutionState.status!=ready

canStartImplementation=false

, or

currentExecutionState.primaryAction=ResolveBlockingFacts

, first supplement blocking facts, do not implement directly

The first-round plan is based on the JSON from

plan-page-task

, do not manually recreate page type conclusions.

S2: Page Generation or Modification

Continue execution according to

hiui-design

The execution surface defaults to
```
requiredActions
```
;
```
requiredCommands
```
are only used as compatibility summaries or manual review views
The generation path is based on
```
targetDeliverySemantics
```
,
```
generationRecipe
```
,
```
generationInputs
```
, and
```
requiredActions
```
; do not manually rebuild downstream page type strategies by the workflow
"Quick / Standard / Strict links" are only used for communicating risks and acceptance depth, and do not replace the structured facts and action staging of the planner

Before executing any file changes, recheck

generationInputGate

and the S1 machine plan; if

generationInputGate

has not passed, the HiUI handoff package is not ready, or

plan.status

facts.status

currentExecutionState.status

is not

ready

, or

canStartImplementation!=true

, must stop and return to S0 / S1, and must not "generate first and supplement requirements later".

Must not break:

Page shell
Region hierarchy
White background main body
Scroll owner
Pagination / footer mounting semantics
Source marker
Contract ownership

S3: Engineering Validation and Pre-Delivery Check

This phase only undertakes actions to enter the verification/delivery confirmation phase:

Default to scheduling based on
```
requiredActions
```
and
```
formalAcceptanceActions
```
```
requiredCommands
```
and
```
formalAcceptanceCommands
```
are only used as compatibility summaries, and no longer define separate workflow phases
Actions whose phase belongs to
```
ResolveBlockingFacts
```
,
```
GenerateOrEdit
```
,
```
WriteContract
```
must be completed in previous phases; must not be accumulated to S3 for unified execution
After entering S3, prioritize recording the real results of
```
Preflight
```
, engineering scripts,
```
FormalAcceptance
```
, and other pre-delivery verification actions

Record the result of each command:

```
passed
```
```
failed
```
```
skipped
```
```
blocked
```

When failing, first judge whether it blocks page operation or delivery, do not silently swallow it.

S4: Run Page, Screenshot, and UX Acceptance

When the page requires a browser:

Start or reuse the dev server
Open the target route
Confirm it is not a blank page, error page, login page, or wrong route
Save the pre-fix baseline screenshot first, then take screenshots for evidence

If login status cannot be obtained, handle according to the URL downgrade rules of

ux-walkthrough

Pre-Fix Baseline Screenshot

Before entering UX acceptance or repair, must retain the viewable original image of the current page as

before-fix

baseline evidence:

Save at least desktop viewport screenshots; add mobile viewport screenshots if the page involves mobile adaptation
Prioritize saving clear original PNGs, not just compressed thumbnails
Screenshot filenames or registration information must indicate
```
before-fix
```
, viewport, and page status
If the page has key states such as filtering, pagination, pop-ups, drawers, error states, only capture the minimum necessary states related to the current issue
If screenshots cannot be taken, must explain the reason in
```
knownRisks
```
, and cannot disguise the final screenshot as the pre-fix screenshot

Organize the information handed over from the engineering phase to the UX phase into the structure in

references/handoff-contract.md

UX Grading

workflow level	UX Mode	Name	Requirements
`quick-preview`	`ux-smoke`	Lightweight usability self-check	Page is visible, main entry is visible, no blank/wrong route, final screenshot for evidence
`standard-e2e`	`ux-standard`	Structured UX acceptance	Evidence gate, P0 scenario coverage, P0/P1/P2 grading, P0/P1 repair closure
`formal-e2e`	`ux-formal`	Full `ux-walkthrough`	Complete SOP, report.json, and completion gates required by the current `ux-walkthrough` version (starting from 1.0.2, includes checklist coverage verification, annotation verification, and docx)

standard-e2e

must not claim to have completed a full

ux-walkthrough

; it is a structured UX acceptance that references

ux-walkthrough

standards. Only

formal-e2e

executes a full

ux-walkthrough

UX Gate

Establish

uxGate

before entering UX judgment:

```
ux-smoke
```
: Confirm that the target page is not a blank page, error page, login page, or wrong route, and retain the final screenshot path.
```
ux-standard
```
: Must have available evidence, read the checklist, severity, ignore-list, and issue examples of
```
ux-walkthrough
```
; must cover P0 scenarios.
```
ux-formal
```
: Execute the complete SOP according to the main process in
```
SKILL.md
```
of
```
ux-walkthrough
```
and
```
docs/onboarding/gates.md
```
, including precheck, evidence gate, report.json, and completion gates required by the current
```
ux-walkthrough
```
version (starting from 1.0.2, includes checklist coverage verification, annotation verification, and docx delivery).

When evidence is insufficient, do not output deterministic UX issues; only output "to be supplemented with evidence / to be verified interactively / cannot judge".

P0 Scenario Coverage

ux-standard

and

ux-formal

must first read P0 scenarios from the S0 handoff package and output coverage conclusions:

Whether the entry is visible
Whether the main path can be completed
Whether key data is understandable
Whether permission/disabled states have explanations
Whether loading, empty, error, and success states are covered
Whether dangerous operations have error prevention
Whether feedback and failure recovery are clear

The UX report must first answer "Can P0 users complete core tasks", then check visual, copy, spacing, consistency, and professionalism.

P2 visual, copy, and consistency issues cannot be the only output of

standard-e2e

formal-e2e

; unless the report also explains the evidence basis that P0/P1 core paths have been covered and no issues were found.

All issues must use the format:

text

1. [P1] Issue Title

Each issue only includes the minimum necessary information:

Location
Issue description
Improvement suggestions
Screenshot evidence, if applicable

Screenshot evidence preferentially references the

before-fix

baseline image; display compressed thumbnails in the report, but must also retain the path to the viewable original image.

formal-e2e

must generate a local

.docx

report;

standard-e2e

generates it only when the user requests a complete UX review, shareable report, or archived report.

S5: Fix and Final Delivery

UX issue handling strategy:

P0: Must be fixed, re-conduct engineering acceptance and UX review after repair
P1: Fixed by default, unless the user explicitly accepts the risk
P2: Can be recorded as a suggestion; can be fixed if the change is small and does not break HiUI structure
Pending confirmation items: Do not modify forcibly, explain what evidence is missing

When fixing experience issues, must still comply with the page shell, region, ownership, source marker, and contract constraints of

hiui-design

After fixing P0 / P1, or actually modifying P2, must retake

after-fix

screenshots using the same route, same viewport, and as much the same data state as possible, and form a before/after comparison in the report. If the same state cannot be maintained, must explain the source of the difference.

After repair, return to:

text

HiUI modification -> Engineering gate -> Page screenshot -> UX review

Final Delivery

The final reply is concluded according to

references/final-report-template.md

, and at least includes:

```
requirementGate
```
and
```
generationInputGate
```
statuses
Requirement refinement summary, if S0 was executed
Page generation / modification summary
Page type and workflow level
Engineering acceptance results
```
uxGate
```
, UX acceptance mode, and P0 scenario coverage results
Paths and brief descriptions of pre-fix / post-fix comparison screenshots
Fixed P0 / P1 issues
Remaining risks or pending confirmation items
Local docx report path, if generated
Unimplemented verification items, if any

Common Mistakes and Correct Practices

Mistake: When the user says "Help me generate a supplier management page", directly create page files. Correct: First output option-based confirmation of MVP, roles, and page scope.
Mistake: After the user replies
```
1A, 2B
```
, directly enter
```
hiui-design
```
. Correct: First display the generation input confirmation block, and let the user confirm the page list and page prompts.
Mistake: The UX report only lists "uneven spacing, unprominent buttons". Correct: First give the P0 scenario coverage conclusion, then list P0/P1/P2 issues.

Statistical Conclusion

Only process usage stats for the

hiui-design

page delivery link:

After standard/strict HiUI page generation is completed and renderable, conclude according to the usage stats rules of
```
hiui-design
```
The completion definition of
```
ux-walkthrough
```
is up to the complete report,
```
report.json
```
, and completion gates required by the current version; starting from 1.0.2, it at least includes checklist coverage verification, annotation verification, and docx; no additional usage stats or telemetry closeout is required

hiui-design

stats return

requires_network_authorization

or exit code

, apply for authorization once according to its rules. Stats failure does not block main task delivery, but cannot silently swallow the enqueue or authorization status.

Runtime Dependency Boundary

hiui-page-workflow

is a runtime orchestration layer, and relies on the following skills being available in the environment:

```
hiui-refine
```
```
hiui-design
```
```
ux-walkthrough
```

This skill is only responsible for orchestrating and consuming the stable output of these skills, and is not responsible for providing public installation entries or undertaking bundle distribution control.

Boundary requirements:

Only rely on capability identifiers

requirements-refinement

page-planning-and-delivery

ux-walkthrough-review

during scheduling

The current canonical mapping from capability to skill is

requirements-refinement -> hiui-refine

page-planning-and-delivery -> hiui-design

ux-walkthrough-review -> ux-walkthrough

```
sourceSkill
```
,
```
dependencies
```
, and downstream names in documents only record public dispatch identities; do not write internal script names, directory names, or references filenames
The execution surface of
```
hiui-design
```
only consumes machine-public planner output and its
```
requiredActions
```
/
```
formalAcceptanceActions
```
; do not write internal script paths into the workflow contract
If the user needs to install, upgrade, verify, rollback, or release combined distribution of the 4 skills, guide them to use
```
hiui-workflow
```
In ordinary page delivery tasks, do not treat installation, rollback, or release smoke scripts as default workflow steps
Do not externally represent
```
hiui-page-workflow
```
as an installation entry, bundle entry, or combined distribution entry
```
dependencies
```
only express runtime dependencies, and should not be interpreted as
```
skills add
```
will automatically install these skills
If the runtime environment lacks the above dependent skills, first explain the gap, then prompt to complete installation using public entries

Installation Guidance

When users ask how to install this workflow or its dependent skills, uniformly guide them to the public installation entry:

bash

npx skills add XiaoMi/hiui/skills/hiui-workflow --skill '*'

Description requirements:

The installation entry is
```
hiui-workflow
```
The 4 independent skills included in it are installed
The above command is the default installation method for Codex currently; non-Codex hosts need to explicitly specify the target skill root directory
No longer externally state "installing
```
hiui-page-workflow
```
alone will install other skills by default"

Validation Boundary

The completion judgment of this skill itself still follows the page delivery workflow:

Whether requirement confirmation is completed
Whether page generation input is confirmed
Whether page planning and implementation are completed
Whether engineering acceptance results are recorded
Whether UX evidence is ready
Whether repair closure and final delivery are completed

Installation, verification, rollback, and release smoke testing belong to the distribution control plane of

hiui-workflow

, and are not part of the default completion path of this skill.

Only when the user explicitly requests to handle the distribution control plane should they be directed to the corresponding scripts and documents in the entry directory, instead of triggering them by default in ordinary page tasks.

Maintainer Notes

When maintaining this skill, always maintain the following statements:

```
hiui-page-workflow
```
= Runtime workflow orchestration skill
```
hiui-workflow
```
= Public installation entry
```
hiui-refine
```
,
```
hiui-design
```
,
```
ux-walkthrough
```
= Independent downstream skills

hiui-page-workflow

is described as an installation entry again in documents, script descriptions, or external replies, it is considered a regression of responsibility boundaries and should be corrected.

hiui-page-workflow

NPX Install

Tags

SKILL.md Content (Chinese)