HiUI Typical Page Skill

Positioning

This skill is the standard generation protocol and delivery governance control plane for HiUI React page engineering.

page-task-plan.v1

remains the only top-level execution entry;

generationRecipe

is its internal forward generation sub-protocol; the final delivery state is still determined by

preflight-report.v1

hiui-page-governance-report.v1

acceptanceProfile

and

finalReportContract

. The core narrative is "Generate correctly according to the recipe first, then confirm via acceptance" rather than "Generate a version first, then correct via acceptance".

When standard typical pages hit

page-component + slot-fill

, they default to the

minimal-doc fast path

: prioritize consuming planner, scaffold and slot contract, instead of manually expanding lengthy governance documents; only complex pages, drifted pages and formal acceptance scenarios upgrade to the complete rule chain.

The main path for

legacy-host-compatible

is unified as

project-certified carrier first -> page-component semantics -> explicit fallback

. When the host undertaking fact is established, priority should be given to consuming project-certified carriers or certified page components, and

managed-translation

is only retained as an explicit fallback.

runtime-bridged-page-component

is just a bridged semantic naming of

page-component

in legacy, and does not introduce a parallel generation family; when hitting

header

, only carrier certification, page contract and preflight can jointly prove that the owner of

PageHeader

stretch,

extra

right-docked and

60px

rhythm does not drift, then the main chain is valid.

When communicating externally, two things should be explained separately: the legacy host main tree cannot be directly mounted as a generic

@hiui-design/typical-page-shells

at runtime, which does not mean that legacy projects cannot follow the normal typical page component main chain. As long as the planner has given

page-component + runtime bridge + slot fill

, it must be executed along this main chain, and the "cannot ad hoc direct shell import" should not be misread as "only reference/fallback".

Core Object Model

```
page-task-plan.v1
```
is the only execution plan and fact export; AI does not manually assemble
```
mode
```
,
```
pageType
```
,
```
pageUnits
```
,
```
startFrom
```
,
```
requiredDocs
```
,
```
requiredActions
```
or key command chains.
```
generationRecipe
```
is introduced as an incremental sub-object of
```
page-task-plan.v1
```
, and no parallel top-level contract is created separately.
```
generationRecipe
```
only describes assembly order, asset mapping, slot boundaries, forbidden actions and lightweight consistency checks; it does not repeatedly store facts that can be derived from
```
pageComponent
```
,
```
baseMoldId
```
, registry or existing contracts.
```
targetDeliverySemantics
```
and
```
currentExecutionState
```
must be output in layers: the former answers "Which managed delivery main chain should be followed after the plan is established", and the latter answers "What actions are allowed in this current step". When legacy is blocked, the former can still retain the target semantics of
```
page-component + runtime bridge + slot fill
```
, but the latter must only expose
```
ResolveBlockingFacts
```
.
```
editableSlots
```
,
```
lockedRegions
```
,
```
pageComponent
```
,
```
baseMoldId
```
prefer to remain "reference or derived", and are not copied into the planner.
```
runtimeBridgeProfile
```
only exists as an additional parsing object for the legacy
```
page-component
```
path; it describes the runtime bridging strategy through
```
rules/runtime-bridged-component-matrix.json
```
, and does not redefine
```
pageComponent
```
,
```
baseMoldId
```
,
```
lockedRegions
```
or business slot facts.
Project-level
```
host pack
```
, project-scoped
```
page carrier
```
and their certification results belong to runtime/asset facts, which are referenced by the plan through fields such as
```
facts
```
,
```
assetResolution
```
,
```
pageComponent
```
by default; do not flatten and copy these facts into each page contract again.
Carrier-critical layout facts, especially the stretch owner, actions docking and vertical rhythm owner of
```
header
```
, are machine facts jointly consumed by contract + certification + preflight; they must not degenerate into soft suggestions that only exist in documentation.

acceptanceProfile

preflight-report.v1

hiui-page-governance-report.v1

finalReportContract

are retained without degradation or removal.

```
requiredDocs
```
is the default only supplementary reading source; its minimum structure is fixed as
```
path
```
,
```
readMode
```
,
```
reason
```
. Read
```
readMode=required
```
first, and
```
reference
```
/
```
conditional
```
are only supplemented when the corresponding scenario is hit.
```
requiredActions
```
is the default only execution source; when there are no structured actions, priority is given to using compatible command fields instead of expanding gates by yourself.

Object model and field classification:

docs/generation/explainers/core-object-model.md

Standard Generation Protocol

Standard Generation Protocol

only answers 4 questions:

What skeleton to start from.
What is the assembly order of key regions.
Which regions allow business filling.
What
```
inlineChecks
```
to perform after completing each key step.

generationRecipe.required

contains at least by default:

```
startingPoint
```
```
assemblyOrder
```
```
requiredAssets
```
```
forbiddenMoves
```

generationRecipe.optional

can be supplemented step by step according to page type and complexity:

```
slotFillPolicy
```
```
regionOwnership
```
```
inlineChecks
```

The first batch of recipes only covers high-frequency page types:

```
table-page
```
```
analytics-page
```
```
edit/detail-page
```

Supplementary reading for standard generation protocol:

docs/generation/explainers/standard-generation-protocol.md

Guardrails

This skill only handles HiUI React page engineering tasks; requirement refinement, end-to-end process orchestration, Figma writing/design draft generation, and general React refactoring must be handed over to the corresponding skill or ordinary code process.
Page generation, rewriting, major modification, page type migration and old system/screenshot translation must first obtain
```
page-task-plan.v1
```
; without a machine plan, conclusions, command chains or final states cannot be manually assembled.
When
```
blockingIssues
```
/
```
blockingReasons
```
are not empty, it must fail closed and only supplement facts; page generation, contract writing, preflight running or final state output are not allowed.
Asset addition, supplementation and update can only be done through shipped public contracts;
```
add-asset
```
/
```
update-asset
```
must be dry-run, and unshipped write / force / asset type cannot be executed.
Without explicit authorization from the machine plan or explicit requirements from maintainers, deploy, upload, publish, sync, global sync, Feishu / bitable background writing, release archive generation or historical output coverage cannot be executed.
For actions involving external services, background agents, launch agents, daemons or user configuration writing, the target scope, authorization source and side effect boundary must be verified simultaneously before execution; if any condition is missing, execution must be refused.
When
```
preflight
```
fails, hard profile governance fails, source snapshot is missing/low confidence, or
```
acceptance contract
```
lacks provenance, the final response must be blocked / failed.
The open-source version must not collect usage data, and must present
```
not_applicable
```
,
```
skipped
```
or
```
unavailable
```
in accordance with
```
PRIVACY.md
```
.

Generation Gates

Pre-generation gates: project root, machine plan, capability profile, mode lock, pre-plan facts.
Generation protocol gates: page-component availability, route ownership, slot boundaries, shell / adapter proof, analytics contract, business content boundaries, controlled extension.
The hard gate truths of
```
legacy-host-compatible
```
ordinary typical pages are unified in
```
rules/legacy-host-hard-gates.json
```
: the baseline is fixed as 4 hard gates, and when hitting
```
header
```
, the conditional gate of
```
header-layout-proof
```
is added, so currently common typical pages usually fall into 5 effective hard gates.
```
styleBoundary
```
,
```
portalBoundary
```
,
```
runtimeSmoke
```
are still triggered according to risks; but the stretch / right-dock / rhythm owner of
```
header
```
is no longer just a style suggestion, and the main chain must be blocked when structured proof is missing.
Under
```
legacy-host-compatible
```
, if the planner has proven that
```
page-component
```
is ready and
```
runtimeAdapterProof.status=available
```
, the default execution semantics is
```
page-component + runtime bridge + slot fill
```
. The lack of the premise of legacy main tree direct shell import can only prevent ad hoc standard-shell mount, and cannot be used as a reason to unilaterally degrade to compatible manually assembled pages, reference default translation pages or free fallback.
The first two layers of gates are part of "how to generate correctly", and are no longer mixed with delivery blocking tone.
When
```
required
```
level
```
generationRecipe
```
fields are missing, assumptions or manual supplementation are not allowed; it can only be blocked, or executed according to the fallback explicitly given by the plan.
When
```
startingPoint
```
cannot be parsed,
```
requiredAssets
```
are unavailable, or
```
assemblyOrder
```
is incomplete, free fallback to blank page handwriting is not allowed.
Only when the plan explicitly gives
```
managed-fallback
```
,
```
host-archetype
```
or
```
reference-or-scaffold
```
as legal fallbacks, downgraded generation is allowed.
Missing
```
optional
```
fields do not automatically block, but forgery and filling are not allowed; when missing, execute according to the default strategy of the page type or existing rules.

Details of generation gates:

docs/generation/explainers/generation-gates.md

Delivery Gates

```
preflight-report.v1
```
and
```
hiui-page-governance-report.v1
```
remain the core judgment objects of the delivery confirmation layer.
```
acceptanceProfile
```
determines the acceptance scope;
```
formal acceptance
```
is the acceptance level, not the generation chain.
```
finalReportContract
```
is retained for complete reports and downstream compatibility.
Delivery gates are only responsible for "whether to allow declaring completion", and no longer dominate the generation narrative.
If a certain type of problem is exposed continuously in the
```
DeliveryConfirmation
```
stage, it must be prioritized to be fed back to
```
generationRecipe
```
or generation gates, instead of continuously adding new acceptance descriptions.

Details of delivery gates:

docs/generation/explainers/delivery-gates.md

Runtime Protocol

The only truth of the runtime protocol is
```
rules/runtime-contract.md
```
; the only truth of the managed page governance protocol is
```
rules/page-governance.md
```
.
```
rules/runtime-bridged-component-matrix.json
```
is the only truth of the legacy
```
page-component
```
bridging semantics; it only declares bridge profile, runtime shell source and thin bridge layer responsibilities, and does not copy mold / slot / ownership facts.
```
rules/legacy-host-hard-gates.json
```
is the only machine truth of the hard gate orchestration for legacy ordinary typical pages;
```
SKILL.md
```
, generation gate descriptions and planners only reference it, and no longer write the number of gates separately.
Basic project facts (mode, capabilities, route ownership, i18n, governance availability) and basic asset facts (certified page component, mold, adapter catalog) should be consumed internally by the plan and exposed through fields such as
```
facts
```
,
```
assetResolution
```
,
```
projectMode
```
,
```
targetPage.routeOwnership
```
.
For connected projects,
```
.local-context/hiui-design/outputs/project-integration-state.json
```
written during the connection phase belongs to the project-level runtime input fact.
```
PlanTask
```
should prioritize reusing it and
```
project-mode.json
```
to directly enter page planning; only when this state is missing, damaged or conflicts with current facts, it falls back to host profile / mode detection diagnosis.
```
project-integration-state.json.integrationReady=true
```
is only established when
```
componentSource
```
,
```
componentShell
```
and
```
componentSupportSources
```
of project-certified carriers have been verified to be resolved to real project source code during the connection phase; if any item is missing, the connection must remain
```
integrationReady=false
```
, and only blocking reasons can be exposed during page generation phase, and the missing carrier problem must not be delayed until the business page implementation phase to be discovered.
For
```
legacy-host-compatible
```
, the definition of
```
integrationReady=true
```
itself includes the completion of project-level required rollout: it defaults to covering
```
table-basic
```
,
```
table-stat
```
,
```
tree-table
```
,
```
tree-split
```
,
```
drawer-form
```
,
```
drawer-detail
```
,
```
full-page-edit
```
,
```
full-page-detail
```
these
```
carrier-first-required
```
page types;
```
feedback-status
```
and
```
data-visualization
```
can be supplemented later as deferred batch. When project-certified carriers of required batch are missing, the integration state must explicitly output
```
requiredLegacyPageTypes
```
,
```
deferredLegacyPageTypes
```
,
```
certifiedLegacyPageTypes
```
,
```
missingRequiredLegacyPageTypes
```
and
```
legacyRolloutCoverageStatus=blocked
```
, and regard the current project as incomplete legacy connection, rather than "connected but supplement rollout in page phase".
```
integrationReady
```
only answers "whether the project has completed hiui-design connection" and "whether legacy host bridging has project-level undertaking facts" by default. For legacy, this final state already includes required carrier batch ready; whether standard typical page components are available under
```
rules-only
```
/
```
host-integration
```
belongs to asset facts and page type support facts consumed by the planner, and should not be closed as a general project connection failure.
Project-scoped host pack / carrier facts also belong to runtime input facts. For legacy projects, they should be certified once in the project connection / capabilities phase first, then reused in the page generation phase, instead of repeatedly explaining host boundaries in each page.
Agent only explicitly reads capabilities, mode lock, certification files or catalog when the plan is missing / conflicting / troubleshooting / maintaining.
```
host-qualification-facts.v1
```
is only a runtime input facts contract, not an execution plan; it only carries legacy host boundaries, bridge / adapter facts and provenance.
```
typical-page:runtime-smoke
```
only records "browser-level evidence on the current source code snapshot", and is not responsible for declaring page completion;
```
preflight
```
/
```
doctor
```
only aligns this evidence with the current source code snapshot and identifies whether it has expired; only
```
typical-page:finalize-page
```
can flip the delivery state to
```
finalized
```
.

Task Lifecycle

The document narrative layer is unified as:

LocateProjectRoot -> PlanTask -> ResolveBlockingFacts -> BuildGenerationRecipe -> GenerateByRecipe -> InlineConformanceChecks -> DeliveryConfirmation -> OutputDeliverySummary

```
PlanTask
```
: By default, first consume project-level integration facts, then supplement capabilities / route / asset-resolution; do not treat "confirming warehouse structure / confirming whether hiui-design has been connected" as a visible pre-step for each page task. The planner also defaults to splitting generation and delivery actions into
```
generationInputs
```
,
```
inlineChecks
```
,
```
deliveryChecks
```
to avoid moving heavy acceptance caliber forward as generation guidance.
The output layer of
```
PlanTask
```
must expose both
```
targetDeliverySemantics
```
and
```
currentExecutionState
```
: the former describes the target delivery main chain, and the latter describes currently allowed actions, blocking phase and blocker priority.
```
requiredCommands
```
,
```
requiredActions
```
and
```
canStartImplementation
```
must be consistent with
```
currentExecutionState
```
, and blocked plans must not appear to be directly startable for page generation.
One of the primary responsibilities of
```
PlanTask
```
for legacy ordinary typical pages is to clearly expose both "forbid legacy main tree ad hoc direct mount of standard shell" and "allow page-component + runtime bridge + slot fill main chain"; the failure of direct shell import must not be regressively expressed as general page-component unavailable.
If project-level integration facts exist but
```
integrationReady=false
```
,
```
PlanTask
```
must fail closed and directly display the connection blocking reason; do not attempt to use page generation, initial scaffold or page-level preflight as a remedy for connection / legacy bridge integrity. Whether page-type
```
page-component
```
assets are ready is still independently judged by the planner's
```
assetResolution
```
/
```
projectTypicalPageSupport
```
, rather than being rewritten as general integration debt.
When the reason for
```
integrationReady=false
```
comes from incomplete legacy required rollout,
```
PlanTask
```
should default to placing
```
bootstrap-target-project
```
at the top of
```
ResolveBlockingFacts
```
; this indicates that the legacy connection / bootstrap of the current project has not been completed, rather than "adding a rollout step in the page phase for a connected project". If route ownership blocker is hit at the same time, add route repair action after it, and do not skip project-level carrier rollout directly into page implementation.
```
BuildGenerationRecipe
```
: Convert
```
generationStrategy
```
into a standard assembly protocol.
```
GenerateByRecipe
```
: Generation behavior must follow
```
assemblyOrder
```
,
```
requiredAssets
```
,
```
forbiddenMoves
```
; free invention of page shells, region owners, slot orders is not allowed.
```
InlineConformanceChecks
```
: Lightweight consistency checks after key assembly steps, without moving heavy acceptance forward.
```
DeliveryConfirmation
```
: End confirmation layer, which internally continues to undertake
```
WriteContract
```
,
```
Preflight
```
,
```
PreviewReady
```
,
```
FormalAcceptance
```
,
```
RuntimeGovernance
```
. The open-source version does not undertake usage telemetry / stats closeout, and the final response only focuses on page delivery and quality verification status.
This is a narrative rename, not an immediate external interface rename; public scripts, report objects and fields retain at least one migration cycle alias.

Detailed lifecycle still takes

rules/page-task-lifecycle.md

as the only truth.

First Turn Output

The first-round response of page tasks prioritizes displaying generation information by default, rather than laying out acceptance fields first. Default priority fields:

```
generationStrategy
```
```
generationRecipe
```
```
generationInputs
```
```
inlineChecks
```
```
primaryGenerationAsset
```
```
assemblyOrder
```
```
requiredAssets
```
```
extensionPolicy
```
```
requiredActions
```

Expand in complex or strict scenarios:

```
deliveryChecks
```
```
acceptanceLevel
```
```
acceptanceProfile
```
```
finalReportContract
```

non-typical-overlay

single-page-composite

is hit, the first round must also directly expose

layoutStrategy

layoutArchetype

nonTypicalScope

mandatoryComponents

compositionGuardrails

strategyEvidence

and

ownershipPlan

; these belong to generation input facts, not inspection notes supplemented after delivery.

If unstandard prototype screenshots, old system screenshots / URLs / source code are hit, output

kickoffType=pre-plan-facts

in the first round according to

docs/generation/ai-kickoff-template.md

, and only explain the status of

visual-translation-brief.v1

and necessary

host-qualification-facts.v1

Truth Index

Machine plan entry, success signals and failure signals:
```
scripts/README.md
```
Fast path execution entry and supplementary reading order:
```
rules/QUICK-START.md
```
Public CLI contracts:
```
scripts/public-cli-contracts.json
```
Runtime protocol:
```
rules/runtime-contract.md
```
Page task lifecycle:
```
rules/page-task-lifecycle.md
```
Failure recovery matrix:
```
rules/failure-matrix.md
```
Generation constraints:
```
rules/generation-rules.md
```

Machine strategies for data visualization priority/style:

rules/chart-semantic-policy.json

rules/data-visualization-layout-policy.json

Page component and mold registry:

rules/page-component-registry.json

rules/page-mold-registry.json

Runtime bridge profiles:

rules/runtime-bridged-component-matrix.json

Legacy hard gates:
```
rules/legacy-host-hard-gates.json
```
Runtime delivery strategy:
```
rules/runtime-delivery-policy.json
```
Adapter registry:
```
rules/adapter-registry.json
```
Contract constraints and summary:
```
rules/contract-regions.md
```
Page governance and source snapshot / acceptance contract:
```
rules/page-governance.md
```
Acceptance checklist:
```
rules/validation-checklist.md
```

Forward validation and success metrics:

docs/validation/generation-recipe-forward-tests.md

Page component strategy and certification:

docs/generation/page-level-components.md

docs/generation/component-certification.md

Explainers (explanation layer, not source of truth):
```
docs/generation/explainers/README.md
```
Header geometry and host baseline:
```
docs/generation/figma-reference.md
```

Old host translation:

docs/generation/legacy-host-compatibility.md

Visual / old system pre-plan facts:

docs/generation/visual-to-hiui-translation.md

Atypical pages:
```
docs/generation/non-typical-pages.md
```

Charts and data visualization:

docs/generation/figma-page-rules.md

docs/generation/figma-pages/data-visualization.md

Usage stats:
```
PRIVACY.md
```

By default, only read

requiredDocs

in the plan; consume

readMode=required

first, then supplement

reference

conditional

items according to the hit situation of

reason

. Do not traverse

docs/

rules/

templates/

manifests/

as a whole to select molds or explain page types.

Final Report

The final response outputs a lightweight delivery summary based on
```
deliverySummaryProfile
```
by default.
Enter
```
finalReportContract
```
/
```
final-page-report.v1
```
only in complex / high-risk scenarios, strict acceptance, legacy migration, true atypical, complex data visualization,
```
preflight
```
/ smoke failure situations.
```
final-page-report.v1
```
should prioritize reusing existing facts of managed page contract / workflow to judge whether the page has been generated, whether it is stale, and whether it has completed formal finalize; do not require the upper layer to repeatedly fill in the same set of states manually.
The default reading order of the final report is: How the page is generated -> Which main assets and slots are used -> Which regions are inherited / which regions are filled by business -> Current delivery confirmation status.
Status fields must be completely retained, but no longer occupy the main reading center.
If
```
typical-page:render-final-report
```
cannot be run, the page status, preflight status, formal acceptance status, usage stats status, executed actions, changed files, verification commands and remaining risks must still be presented.

hiui-design

NPX Install

Tags

SKILL.md Content (Chinese)