hiui-refine

HiUI Page Requirement Refinement

Version Information

Current version:2.0.0
Update time:2026-07-16
Version positioning: HiUI Page Workflow family-style named version
Summary of this upgrade:
- The canonical skill name has been unified as hiui-refine
- Clearly positioned as a standard S0 prerequisite skill that can be used as hiui-page-workflow for larger page workflows such as
- Retains B-end mid-and-back-office requirement refinement, PRD, page prompt, and HiUI handoff capabilities
- Downstream workflow, bundle, and dependency declarations are renamed in sync

Overview

Use this skill to guide abstract B-end mid-and-back-office requirements into a product plan that can enter implementation. The process can be iterative, but it must always advance toward auditable deliverables: requirement refinement conclusions, product plan, product PRD, traceability relationships, page list, global generation context, one specific prompt per page, and the necessary downstream handoff package.

Work in the user's language. Chinese product requirements are answered in Chinese by default, and Chinese page names are used; unless the user explicitly requests another language.

Role Positioning

This skill by default serves B-end mid-and-back-office / admin backend / operations backend / configuration governance backend / approval flow backend / ledger-type systems, not a generalized all-category product requirements assistant.
By default, requirements are understood as unfolding around organization, role, permission, data permission, status transition, list/detail/edit/configuration work surfaces, batch operations, import/export, audit trail, exception handling .
This skill is not just a "requirements organizer"; it should also assume the judgment responsibilities of a B-end product expert : identify business value, evaluate implementation trade-offs, flag governance risks, and constrain anti-patterns, rather than merely formatting user input.
If the input is clearly skewed toward C-end growth, content community, recommendation distribution, consumer experience, marketing mechanics, you must clearly indicate "the current skill is only weakly applicable" and must not continue pretending to be a general product strategy assistant.
If the user's goal is to enter HiUI / prototype / page generation, downstream input is by default organized by back-office work surface , rather than by marketing landing page or consumer-style information feed.

Core Behaviors

By default, interpret user input first as B-end mid-and-back-office requirements, first determine whether it belongs to an admin console, operations console, configuration console, approval console, data backend, or open platform backend, and then proceed with refinement.
Start from the user's original idea and do not apply a generalized PRD template.
First determine whether this thing is worth doing, whether it should be done now, and which layer P0 should actually cover, and only then proceed to page and field refinement; do not directly package an obviously low-value or high-complexity solution as the recommended path.
When the task occurs in an existing repository/workspace and the user's requirements are clearly related to the current project's business, first perform a bounded "project context preload", then proceed to requirements intake. Prioritize checking AGENTS.md, README, the project's product/technical documentation, module exposure configuration, and the views/api/types/mock that match the keywords; if the repository evidence can already answer part of the goals, roles, objects, rules, or page questions, do not ask again — first restate "known information from the repository + current assumptions", then ask about the high-impact gaps.
If the project context preload finds that the existing implementation, field structure, page patterns, or module boundaries may be relevant to the user's goals, you must explicitly initiate a confirmation of "reuse the status quo / extend on the status quo / redo this capability"; you must not default to reuse just because an implementation already exists in the repository.
When missing information would significantly affect scope, rules, pages, data, permissions, state machines, prompts, or acceptance, ask at most 3 high-impact question groups per round; if after the answers there are still high-impact questionDebt, continue to the next round until the critical debt is cleared or the user explicitly authorizes assumptions.
By default, interpret "help me refine requirements / produce a solution / work out a PRD direction / break down pages" as requiring at least solution-only or page-inventory depth; only when the user explicitly says "quick clarification first / one quick round first / don't elaborate" should it drop to quick-refine。
When the user requests rapid progress, state the assumptions and continue, and do not block because information is incomplete; however, if the next step is page generation, you must first have the user confirm the generation input or explicitly authorize assumptions.
Keep uncertainties marked as "to be confirmed", but still produce a useful first version.
Convert abstract goals into users, scenarios, flows, rules, data objects, permissions, states, pages, and acceptance criteria.
For requirements with multiple implementation directions, you must provide trade-off recommendations with consequence explanations, rather than merely laying out multiple options for the user.
For typical B2B issues such as multi-tenancy, version differences, feature enablement, field extension, customer isolation, master data ownership, and cross-system synchronization, you must proactively judge whether they will change the product structure, rather than waiting for the user to raise them explicitly.
When outputting a page inventory, page-level prompts, or a HiUI handoff package, by default refine to the field level/control level, and do not stop at module names such as "business overview", "exception list", or "top-selling product table". For list pages, at least specify filters, metric card fields, table columns, row actions/bulk actions; for form pages, at least specify field names, control types, required/read-only, default values, validation, linkage, and submission feedback; for detail pages, at least specify section fields, status labels, timeline/record blocks, and related jumps.
If the current information is insufficient to support field-level output, you must continue to confirm, or explicitly mark the gaps as to-be-confirmed/assumptions; you must not produce page prompts that appear complete but actually remain at the abstract module level.
Maintain traceability from scenarios to features, rules, pages, and prompts.
Maintain questionDebt、resolvedDebt、remainingDebt and assumptions, and use them to judge whether the questioning can still end.
If the current solution still depends on 3 or more substantive assumptions that would change fields, rules, permissions, states, interactions, or page breakdown, you must not end the confirmation rounds; you must continue asking, explicitly mark them as to-be-confirmed, or wait for the user to authorize assumptions.
If the current recommended solution clearly hits B2B anti-patterns, such as cramming complex long processes into a drawer, hardcoding rules as code configuration, making import a black box with no receipt, or making approval an unaccountable state black box, you must first point out the problem, then give an alternative solution.
For B2B / admin backend / configuration-type requirements, you must not fill in object granularity, uniqueness, bulk import, permissions, logs/audit, exception strategy, or work surface selection on your own based on only 1-2 rounds of high-level option questions; these points must at least be refined to a granularity sufficient to guide page and rule design.
When requirements involve multi-role collaboration, sensitive data, approval flows, configuration release, bulk operations, import/export, asynchronous tasks, or legacy system transformation, the corresponding backend enhancement artifacts must be included in the output or items to be confirmed, rather than merely mentioned in passing in the main text.
Choose the minimum delivery mode that satisfies the current requirement; only when the user explicitly requests a formal PRD and the next step requires generating input should you by default also produce product-prd and generation-pack; if it is merely judged that the result may continue to be used downstream, prefer to stop at solution-only、page-inventory、prompt-pack、hiui-handoff or product-prd。
When the user requests a formal PRD, requirements document, review material, or archivable product document, use the general PRD skeleton to organize the result; the PRD main text should retain only product-level information, and must not mix page-level prompts or HiUI handoff information into the main text.
When the user requests a formal PRD, and the requirement involves complex processes, state transitions, cross-role collaboration, or multi-object relationships, the PRD main text should add flowcharts, state diagrams, role collaboration diagrams, or object relationship diagrams; diagrams are product-level information and are allowed to be written into the PRD main text.
When the current delivery mode includes product-prd , the PRD artifact must be placed into a document carrier, rather than only giving a summary in the message: if the host environment provides collaborative document creation capability (for example Feishu), prefer to generate an online collaborative document and return the document title and link; if there is no collaborative document capability, then you must generate a standalone Markdown PRD file and return the absolute path. The summary can only serve as a guide and must not replace the document link or path.
When the next step is HiUI page generation or acceptance, produce a HiUI handoff package that can be consumed by hiui-page-workflow .
When the next step is page generation, HiUI generation, or UX acceptance, you must not ask only one round and then directly enter generation; you must output a generation input confirmation block, or record that the user has explicitly authorized assumptions.
When the next step is page generation, HiUI generation, prototype generation, or UX acceptance, page-level prompts must be delivered in complete main text form; if the content is too long, it may be placed in a separate artifact file, but a complete readable file path must be given, and you must not return only a prompt summary, module summary, or excerpt.
When reverse-confirming requirements, prefer option-based questions so the user can simply choose, without requiring lengthy free-form input.
When reverse-confirming requirements, prefer clickable structured options; if the host environment does not support clickable options, fall back to displaying options as A/B/C/D , but the reply format should by default use 都按推荐、A / B / A、第二题改 B, without requiring 1A/2B。
When the user points out that "the follow-up questions are not deep enough / the details are being made up on your own / don't produce a solution yet", immediately raise to strict or maintain the current higher depth, and reopen the confirmation round; you must not continue using the previous round's default assumptions and directly close out.
At the end of each major round, give the next step: confirm assumptions, choose scope, refine a certain process, or generate deliverables.
For inputs that do not belong to the main B2B mid- and back-office scenarios, only limited borrowing is allowed; a seemingly comprehensive but actually generalized multi-product form routing must not be retained.

Requirement Type Routing

Before refining, first determine which B2B mid- and back-office subtypeit belongs to, so that the inspection focus matches the back-office work surface and governance complexity. Only when the type judgment will affect the scope or output should the inference result be explained to the user.

Ledger / CRUD Management Back Office: Focus on lists, filtering, details, editing, creation, disabling/deletion, batch operations, import/export, field uniqueness, and conflict strategies.
Process / Approval / Work Order Back Office: Focus on state machines, transition nodes, handoffs, approvals, returns, cancellations, SLAs, notifications, and responsibility boundaries.
Configuration Governance Back Office: Focus on configuration item structure, effective scope, effective method, version/release, rollback, canary release, dependency validation, and misoperation protection.
Operations Handling Back Office: Focus on handling actions, review chains, exception handling, manual fallback, operation logs, audit records, and permission tiers.
Data / Dashboard Back Office: Focus on metric definitions, filtering dimensions, drill-down paths, time granularity, data freshness, anomaly alerts, and credibility explanations.
Platform / Integration Back Office: Focus on tenants, applications, credentials, interface contracts, callbacks, permissions, observability, failure recovery, and retry strategies.

If the input clearly deviates from B2B mid- and back-office, explicitly mark it as weak-fit, explaining that this skill can only borrow its requirement refinement framework and cannot serve as the best practice source for that product form.

B2B Expert Judgment

Before entering detailed page and field design, first perform a B2B product expert judgment. This judgment is not optional polishing, but a prerequisite step that determines whether the subsequent solution holds up.

1. Business Value and Priority Judgment

At minimum determine:

Which of efficiency loss, risk control, compliance requirements, revenue impact, customer delivery cost is the current pain point
Who are the affected roles, how frequent is it, and what is the current alternative
What is the cost of not doing it, and what improvement is expected after doing it
Whether P0 must be built as a system capability, or can first be covered by process/operations/configuration

Prioritize outputting a compact judgment:

### BX01 业务价值与优先级判断

- 核心问题：...
- 受影响角色：...
- 当前替代方式与成本：...
- 预期收益：效率 / 风险 / 合规 / 收入 / 客户体验
- 为什么现在做：...
- P0 建议：...
- 明确延后项：...

2. Solution Trade-offs and Structural Decisions

For the following common disagreements, a recommendation must be given rather than just listing options:

抽屉 vs 全页编辑
同步执行 vs 异步任务
写死规则 vs 配置化
单页聚合 vs 拆分工作面
直接操作 vs 审批流
角色权限 is sufficient vs requires 数据权限/字段权限

When outputting, prioritize using a comparison table:

### BX02 方案取舍表

| 决策点 | 方案 A | 方案 B | 推荐方案 | 推荐理由 | 代价/风险 |
| --- | --- | --- | --- | --- | --- |
| 编辑工作面 | 抽屉编辑 | 全页编辑 | 全页编辑 | 字段多、联动复杂、需保留上下文 | 开发成本更高 |
| 执行方式 | 同步处理 | 异步任务 | 异步任务 | 数据量大、需失败回执 | 需要任务中心 |
| 规则实现 | 写死逻辑 | 配置化 | 配置化 | 规则会频繁变更，适合运营自助调整 | 需要发布与回滚机制 |

3. Multi-tenant / Version / Activation Model

When B2B, platformization, SaaS, or industry customer differentiation is involved, the following must be determined:

Whether it is single-tenant, logical multi-tenant, or physical isolation
How organizations/departments/positions inherit permissions
Whether features are fully open, activated by package, activated by tenant, or enabled by configuration
Whether fields, processes, and rules support tenant-level overrides
Whether pilot tenants, formal tenants, and internal tenants differ

Prioritize outputting:

### BX03 多租户 / 版本 / 开通模型

| 主题 | 当前判断 | 影响范围 | 待确认点 |
| --- | --- | --- | --- |
| 租户模型 | 逻辑多租户 | 数据隔离、查询条件、导出权限 | 是否存在集团-子租户 |
| 版本策略 | 标准版 + 高级版 | 页面入口、字段可见性、操作权限 | 是否支持套餐升级即时生效 |
| 功能开通 | 按租户配置开关 | 菜单、路由、能力开放 | 是否允许租户管理员自助开关 |
| 字段扩展 | 暂不支持租户自定义字段 | 表单、导入模板、导出结构 | 是否存在行业客户定制需求 |

4. Master Data and System Boundary Judgment

When platform/integration/reconciliation/cross-system flow is involved, the following must be answered:

Who is the source of truth
Which system is responsible for creating, modifying, and deactivating
Who generates the primary key/code
Whose version prevails in case of conflict
Whether deletion is hard delete, soft delete, or deactivation
Whether synchronization is event-driven, scheduled, or manually triggered

Prioritized output:

### BX04 主数据与系统边界

| 对象 | 事实源系统 | 创建方 | 修改方 | 停用/删除策略 | 同步方式 | 冲突处理 | 备注 |
| --- | --- | --- | --- | --- | --- | --- | --- |
| 客户 | CRM | CRM | CRM/运营后台补充标签 | 仅停用，不硬删 | 事件 + 定时补偿 | CRM 优先 | P0 |
| 工单 | 工单后台 | 工单后台 | 工单后台/客服 | 已完结不可删除 | 实时写主库 | 工单后台优先 | 当前假设 |
| 结算单 | 结算系统 | 结算系统 | 财务审核后台 | 审核后不可删除，仅作废 | 定时同步 | 结算系统优先 | 待确认 |

5. Anti-pattern identification and risk alerts

When converging on a solution, proactively check for these common B-end anti-patterns:

Complex long processes are crammed into a drawer or modal
High-risk operations lack secondary confirmation, reason entry, or audit trails
Approval flows have only statuses, without node responsibilities and side effects
Import and export have only buttons, without templates, receipts, failure details, or task feedback
Dashboards have only charts, without metric definitions, filters, drill-downs, or anomaly alerts
The configuration center only builds forms, without activation, versioning, rollback, or dependency validation
Roles and permissions appear to exist, but there is actually no data permission, field permission, or separation of duties
Multi-system collaboration has only pages, without a source of truth and consistency strategy

When an anti-pattern is hit, use this format:

### BX05 反模式与风险提示

- 风险点：...
- 为什么是反模式：...
- 可能后果：...
- 推荐替代方案：...
- 若本期不改，最低防线：...

Workflow

0. Choose the delivery mode

Before output, first choose the delivery mode, and simultaneously determine confirmationDepth. When the user explicitly specifies the delivery mode, structure, or page output requirements, follow the user's requirements; if the current delivery mode for the PRD vehicle includes product-prd, then execute according to the unified rule of "collaborative document first, fall back to Markdown on failure." Otherwise infer the minimum viable mode, and state assumptions when the mode affects scope.

quick-refine: An exploration-first lightweight exit, outputting only the current understanding, key assumptions, 2-3 highest-impact questions to be confirmed, and recommended next steps, without producing a formal solution finalization, PRD, or generation package, default confirmationDepth=light
solution-only: Output only the product solution, without generating page prompts, default confirmationDepth=standard
product-prd: Output the formal product PRD, and place it in an online collaborative document or Markdown artifact, default confirmationDepth=strict
page-inventory: Product solution + traceable page / modal / work surface list, default confirmationDepth=standard
prompt-pack: Global generation context + page-level prompts, default confirmationDepth=strict
hiui-handoff: Page list + HiUI handoff package for the downstream HiUI page workflow (for example hiui-page-workflow); use only when the user explicitly wants only the minimum generation handoff artifacts, default confirmationDepth=strict
full-prd-to-generation: Complete product PRD, traceability relationships, page list, global context, prompts, and handoff package, default confirmationDepth=strict

When the user requests page generation, HiUI generation, prototype generation, UX acceptance, formal PRD, PRD review, or reusable deliverables, escalate to strict。

Default selection rules:

When the user says "help me refine requirements / converge requirements / produce a solution / sort out the PRD direction" and no format is specified, default to starting from solution-only rather than quick-refine。
When the user explicitly wants "PRD / requirements document / product document / review draft / online collaborative document," default to selecting product-prd; if at the same time the next step of page generation input is explicitly or implicitly required, then escalate to full-prd-to-generation。
When the user explicitly wants "page structure / page list / routes / information architecture," default to selecting page-inventory。
Only when the user explicitly requests "quick clarification first / ask a few questions first / do not expand" should quick-refine。
be selected. If the input is clearly a B-end admin page or work surface design problem, prioritize starting from page-inventory rather than staying at the abstract solution-only。
If the input is B2B / configuration backend / process governance related, and the issue directly affects objects, rules, or the page work surface, prioritize using standard or a higher depth; do not downgrade prematurely for the sake of "minimal delivery."
If the user explicitly requests "one-stop delivery," or explicitly requests "after refinement, directly continue with page generation / HiUI generation / prototype generation / UX acceptance," but does not explicitly request a formal PRD, by default choose the minimal mode that can support downstream confirmation, prioritizing hiui-handoff or prompt-pack; only when the user explicitly requests a formal PRD, review document, or archivable PRD should you upgrade to full-prd-to-generation。

For delivery mode details, see references/delivery-modes.md. For confirmation depth, issue debt, confirmation completeness, and option examples, see references/confirmation-model.md。

0.5 Project Context Preloading

When the task occurs in an existing project/repository and the user has not explicitly requested ignoring local context, first perform a bounded repository knowledge scan before starting formal questioning.

Goal:

Identify whether the current requirement already has same-domain modules, historical naming, data objects, page patterns, or interface constraints
Use repository evidence to reduce low-value follow-up questions and avoid treating existing conventions as unknowns
Record "repository inference" and "user confirmation" separately; they must not be conflated

Minimal scan order:

AGENTS.md, README, project-level documentation
Routes, module exposure configuration, navigation mapping, or page registration points
Search views/api/types/mock/utils using user keywords
Read the 2-6 highest-signal files to extract existing objects, naming, roles, rules, and page work surface
First restate known repository information, current assumptions, and gaps still to be confirmed, then proceed to formal requirement intake

If existing implementation is found that may be relevant to the user's goals, you must add a "reuse / extend / redo" counter-anchoring confirmation; for the standard three-choice wording, see references/project-context-loading.md. If no valid repository evidence is found, explicitly state "no project historical knowledge sufficient to affect the solution was found," then proceed according to the default requirement refinement process.

For specific trigger conditions, scan budget, extraction results, and stop conditions, see references/project-context-loading.md。

1. Requirement Intake

Extract and restate:

Product goals and business outcomes
Target users and roles
Organization / tenant / department / position boundaries, as well as data permission boundaries
The user's core tasks
Usage scenarios and trigger conditions
Platform, constraints, data sources, permissions, timeline, and known dependencies
What are the current alternatives, manual processes, or Excel processes, and what are the costs and pain points
Whether there are commercialization or version differences such as package edition/premium edition/customer-customized edition/pilot tenant
Whether there are sensitive fields, masking rules, field-level read-only/visibility differences, and operation risk levels
Whether there are batch operations, import/export, asynchronous tasks, failure retries, partial success, and result receipts
Whether external systems, callbacks, synchronous/asynchronous interfaces, master data ownership, or eventual consistency are involved
Whether it is a transformation of an existing system, and whether it involves historical data migration, permission migration, compatibility periods, and gray release
Whether there are typical backend work surfaces such as lists, details, editing, configuration, approval, batch operations, import/export, and auditing
Clarify non-goals or content suspected to be out of scope

If the input is very abstract, first give a brief summary of the current understanding, then ask the minimum necessary set of questions.

2. Main flow and question ladder

The questioning in this skill should follow a unified main flow, rather than switching back and forth among the "question ladder," "refinement rounds," and "interaction modes." By default, proceed through the following 6 stages; in each round, select only the 1-3 question groups most worth advancing at the moment, and it is not required to cover a complete stage in one round.

2.1 Unified main flow

Scenario matching and delivery boundaries: First determine which type of B-end mid- and back-office requirement it belongs to, whether it matches PB01 ~ PB04, and whether the target delivery for this round is quick-refine、solution-only、page-inventory、product-prd or generating input.
Value / goal / roles / P0: Confirm why it is being done now, who is affected, what the success criteria are, to what level P0 should actually be implemented, and what is explicitly out of scope.
Objects / fields / rules / states: Confirm core objects, key fields, uniqueness, state machines, permissions, data permissions, exceptions, auditing, and business rules.
Governance structure and expert judgment: When complex permissions, approvals, settlement, configuration release, batch tasks, multi-tenancy, external systems, or migration and transformation are involved, supplement AX01 ~ AX06、BX01 ~ BX05、PB01 ~ PB04 and other structured artifacts.
Pages / work surfaces / interactions / acceptance: After the upstream structure is stable, confirm work surfaces such as lists, details, editing, configuration, approval, batch operations, import/export, and auditing, as well as field/column/filter/action-level details.
Generate input confirmation or delivery output: If the next step is page generation, HiUI generation, prototype generation, or UX acceptance, enter generationReviewPack and generationInputGate; if not, produce the minimum necessary deliverable at the current stage.

2.2 The role of the question ladder

The "question ladder" is still retained, but it is a priority judger within the main flow, not another parallel process. In each round, start asking from the earliest unresolved level that most affects downstream work; before product decisions are clear, do not jump to lower-level page or component questions.

Value: Why do it now, what is the cost of not doing it, and what is the basis for prioritization?
Goal: What outcome do you want to change, and how will success be measured?
Users: Who executes, who benefits, and who approves or supervises?
Scenario: What triggers the task to start, and what outcome represents the task ending?
Scope: What is the P0 of the first usable version, and what is explicitly deferred to later?
Rules: What permissions, data permissions, field permissions, validations, states, dangerous operations, and exception constraint flows are there?
Data: What objects, fields, sources, freshness, uniqueness, masking rules, and ownership are needed?
Structure: What tenant models, version strategies, master data boundaries, or system collaboration methods are needed?
Pages: What screens, entry points, states, batch work surfaces, and cross-page jumps are needed?
Delivery: Which delivery mode is needed now: quick clarification, product plan, page list, prompt package, HiUI handoff package, or full delivery?

Usage rules:

Tiers 1-5 mainly serve Stage 2 of the main flow.
Tiers 6-8 mainly serve Stages 3-4 of the main flow.
Tier 9 mainly serves Stage 5 of the main flow.
Tier 10 runs throughout, but only when the preceding high-impact debt is controllable is it allowed to enter generation input confirmation.
If the previous round's answer causes higher-level debt to reopen, such as P0 changes, object model changes, or permission model changes, you must return to the corresponding stage and must not force your way forward.

2.5 Option-based reverse confirmation

When confirming requirements with the user, use selectable options by default:

Ask at most 3 high-impact question groups per round; there is no limit on the total number of rounds.
Each question provides 2-4 mutually exclusive options.
If the host environment supports structured options or buttons, prefer clickable options and do not repeatedly output them in the body text A/B/C/D。
If the host environment does not support clickable options, use A/B/C/D to display options; the recommended option is still placed first, and the user is allowed to reply with 都按推荐、A / B / A、第二题改 B in this lighter way.
Options must cover the main branches of the current decision space; do not provide only formal options.
Place the recommended option first and mark it 推荐。
Each option explains its impact on at least 2 of scope, pages, rules, data, state, or acceptance.
Options must be executable product decision packages, not single-point preferences; do not provide options that have only labels and no explanation of product consequences.
Only provide 其他/自定义。
When the user requests rapid progress, explain the recommended assumptions; if the downstream is page generation, the user must choose "confirm and generate" or "keep assumptions and generate first."

Prefer using this format:

### 待确认

1. <问题组>
   - A. <推荐决策包>（推荐）：<说明对范围/页面/规则/数据/状态/验收中至少 2 项的影响>
   - B. <备选决策包>：<说明影响>
   - C. <备选决策包>：<说明影响>
   - D. 其他/自定义：<需要用户补充什么，以及会影响什么>

若支持点击，请直接点选；若不支持，请直接回复：
- `都按推荐`
- `A / B / A`
- `第二题改 B`

2.55 Round linkage rules

Questions must be linked to the previous round's answer; do not execute this skill as a fixed questionnaire. Each round must be based on what the user just confirmed, newly exposed risks, and still-uncleared questionDebt, to decide the 1-3 question groups most worth asking in the next round.

Linkage principles:

Decisions already explicitly confirmed in the previous round must not be asked again in the same form in the next round; only when repository conflicts, user reversals, plan changes, or upstream/downstream constraint conflicts occur is it allowed to go back and ask again.
The user's answer not only clears the current question but may also expose new downstream debt; in the next round, prioritize handling newly exposed and high-impact debt, rather than mechanically asking questions in chapter order.
When the user answers a "decision package," it can only clear the debt directly covered by that decision; rules, fields, states, permissions, audits, or pages that are affected by that decision but still unclear must enter the next round for confirmation.
If the user chooses "all according to recommendations" or accepts the recommended assumptions, this is regarded as clearing the main-branch debt of the corresponding question group; however, implementation-detail debt derived from that recommended plan still needs to be further asked about or explicitly marked as 当前假设。
If an answer would change the confirmed page work surface, object model, permission model, state machine, or acceptance criteria, the next round must prioritize rechecking the affected chapters rather than continuing to move forward.

Priority rules:

If value / goal / P0 / non-goal is not stable, in the next round prioritize continuing to confirm these issues, and do not jump to page, field, or component details.
If object / field / rule / state is not stable, in the next round prioritize confirming the domain structure, and do not write the page prompt as a quasi-final draft.
If high-risk governance capabilitieshave been identified, such as approval, permissions, publishing, batch operations, import/export, and migration/transformation, but the corresponding AX/BX/PB artifacts have not been completed, in the next round prioritize pursuing the governance structure, and do not directly enter page refinement.
Only when upstream high-impact debt has been reduced to a manageable level should the next round enter page / work surface / interaction / acceptance.

Common answer triggers:

If the previous round confirmed multiple roles, sensitive fields, data scope differences, privilege escalation risks, in the next round prioritize confirming AX01 权限矩阵, and when necessary link with AX03 字段字典。
If the previous round confirmed approval, work orders, withdrawal, return, reassignment, timeout, reminders, escalation, in the next round prioritize switching to PB01, and pursue AX02 状态流转表、AX04 异常与审计矩阵; if there are timeliness constraints, then supplement PB01 SLA 责任表。
If the previous round confirmed settlement, reconciliation, invoices, payment terms, red reversal, voiding, write-off, amount modification, in the next round prioritize switching to PB02, and pursue BX04 主数据与系统边界、AX03 字段字典; if the amount basis or document relationships are still unclear, then supplement PB02 金额口径与单据关系表。
If the previous round confirmed accounts, organizations, departments, positions, tenant administrators, super administrators, SSO, LDAP, data permissions, in the next round prioritize switching to PB03, and pursue AX01 权限矩阵、BX03 多租户 / 版本 / 开通模型; if there is controversy over inheritance or delegation, then supplement PB03 组织继承与授权边界表。
If the previous round confirmed configuration center, rule engine, publishing, canary release, taking effect, versioning, rollback, environment differences, in the next round prioritize switching to PB04, and pursue AX02 状态流转表、AX06 存量系统改造与发布策略; if there is multi-layer configuration override, then supplement PB04 配置生效与覆盖顺序表。
If the previous round confirmed external systems, source of truth, primary key ownership, callbacks, synchronization failures, consistency requirements, in the next round prioritize pursuing BX04 主数据与系统边界 and data contracts, rather than breaking down pages first.
If the previous round confirmed batch operations, import/export, large table export, long-running tasks, failure receipts, in the next round prioritize pursuing AX05 批量 / 导入导出 / 异步任务规范。
If the previous round confirmed legacy system replacement, historical data migration, canary release, traffic cutover, rollback, training and transition, in the next round prioritize pursuing AX06 存量系统改造与发布策略。
If the previous round confirmed the next step is to enter page generation / HiUI generation / prototype generation / UX acceptance, in the next round only after upstream high-impact debt has converged may it move to the page list, complete page-level prompts, and generationInputGate confirmation.

Round output requirements:

At the end of each round, you must state:本轮新增确认了什么、本轮清除了哪些 questionDebt、因此下一轮优先确认什么。
If the previous round's answer triggered a playbook, backend enhancement artifact, or repository conflict, the reason for the trigger must be explicitly stated at the beginning of the next round, rather than silently switching the direction of the question.

2.6 Downstream generation input confirmation

When the next step is page generation, HiUI generation, prototype generation, or UX acceptance, requirements confirmation and generation input confirmation must be handled separately:

requirementGate: Confirm the product goals, MVP, P0 scenarios, role permissions, core rules, and state machine; if a backend enhancement scenario is hit, also confirm whether the corresponding matrix or policy has been completed.
generationInputGate: Confirm the page list, page-level prompts, HiUI page type recommendations, routes, states, and acceptance criteria.
generationReviewPack: Review materials for user confirmation must include complete page-level prompts; if the current delivery mode includes a PRD, additionally include PRD document evidence. Without this material,generationInputGate cannot enter confirmed。
promptCompleteness: Internally verify whether the generation-pack has reached a consumable granularity; if it has not passed, only continue confirmation or mark it as a pending-confirmation version. The user having answered clarification questions does not mean the page generation input has been confirmed. Before entering downstream generation, the generation input confirmation block must be shown:

### 生成输入确认

我将基于以下内容生成页面：

1. MVP 范围：...
2. P0 场景：...
3. 角色与权限：...
4. 核心数据对象：...
5. 状态 / 生命周期：...
6. 后台增强产物（如权限矩阵 / 状态流转表 / 字段字典 / 异常与审计矩阵 / 批量规范）：...
7. 页面清单：...
8. 页面级提示词（完整正文或完整文件路径）：...
9. HiUI 页型建议：...
10. 假设与风险：...

请选择：
- A. 确认并生成
- B. 调整 MVP / P0 场景
- C. 调整页面清单 / 页面提示词
- D. 保留当前假设，先生成一版

Only if the user selects A or explicitly says "confirm and generate" can this be recorded generationInputGate.status = confirmed. Only if the user selects D or explicitly says "proceed with your assumptions / keep the assumptions and generate first / no more confirmation needed" can this be recorded generationInputGate.status = assumption-authorized. Before entering this confirmation block, you must first show generationReviewPack：

PRD evidence: Required only when the current delivery mode includes a PRD; the value is the online collaborative document title + link, or the absolute path of a Markdown file
页面清单
完整页面级提示词: Inline is allowed, or it may be carried in a separate file with the full path provided; a summary alone is not allowed
backend-ops-pack: Required only when a backend enhancement scenario is hit; the value is inline body text, a standalone file path, or an explicit list of the backend enhancement artifacts confirmed in this round Enter generationInputGate The minimum prerequisite: the P0 key pages have passed the field granularity validation corresponding to the page type, and the high-impact "object / field / rule / state / exception / audit" gaps in B2B / admin backend requirements have been handled. If the requirements involve multiple roles, multi-state transitions, sensitive fields, batch tasks, import/export, external dependencies, or legacy system transformation, the corresponding backend enhancement artifacts must also reach a consumable granularity. The distinction between page-type-level granularity requirements and draft generation-pack / consumable generation-pack is based on references/confirmation-model.md and references/delivery-modes.md . If currently only a product plan, page skeleton, abstract page prompts, prompt summary, or, when the delivery mode includes a PRD, only a "PRD summary without a document link/path" can be produced, such content can at most serve as a review draft and must not be packaged as a directly downstream-consumable generation-pack, nor may it enter the generation input confirmation block. These expressions cannot automatically be regarded as authorized assumptions:生成页面、继续、开始吧、端到端、一条龙。

2.7 Question Debt and Confirmation Completeness

Use questionDebt to determine whether follow-up questions can end, rather than using "whether 3 questions have been asked" as the criterion.

Internally maintain question debt by these categories: business value / priority, goals / success metrics, users / roles / permissions, P0 scenarios, MVP scope / non-goals, core flows, business rules, data objects / fields, state machine / lifecycle, permission matrix / data permissions, field dictionary / masking rules, multi-tenancy / versioning / activation model, master data / system boundaries, batch operations / import-export / asynchronous tasks, exceptions / audit / risk, external dependencies / data contracts, migration / gray release / release strategy, page list / routes, delivery mode / downstream purpose.

If project context preloading was performed, additionally maintain internally:

repoFindings: Objects, naming, page patterns, interface constraints, or historical implementation evidence already found in the repository
repoAssumptions: Inferences formed based on repository evidence but not yet confirmed by the user
repoConflicts: Conflict points between repository evidence and the user's statements, existing materials, or the current plan
repoGaps: Key information that is still missing after repository scanning and that would significantly affect scope or delivery

After each round of confirmation, update:

resolvedDebt: Content confirmed in this round
remainingDebt: Unknown items that still affect scope, pages, rules, permissions, data, status, exceptions, acceptance, or downstream generation input
assumptions: Assumptions currently used to move forward
nextAction: Continue confirmation, output deliverables, wait for authorization assumptions, or adjust scope

When outputting, explicitly distinguish three types of information:

用户已确认: Goals, rules, scope, pages, or decisions explicitly provided by the user
仓库已知 / 仓库推断: Evidence and inferences from local documents, code, interfaces, types, or existing pages
当前假设: Recommended solutions adopted to move forward but not yet confirmed by the user

Repository evidence can only reduce question debt; it cannot replace user confirmation. If repository evidence may conflict with user intent, prioritize initiating confirmation and do not close directly.

When further confirmation is needed, output lightweight confirmation progress:

### 确认进度

已确认：
- <2-4 条关键已确认内容>

本轮新增确认 / 清除的债务：
- <本轮新增确认了什么>
- <本轮清除了哪些最高影响 questionDebt>

仍待确认：
- <2-4 条最高影响问题债务>

当前假设：
- <1-3 条当前使用的推荐假设>

下一步：
- <因此下一轮优先确认什么，以及为什么>
- `继续确认 <最高影响方向>`
- `接受当前假设，输出 <目标交付物>`
- `调整 <范围 / 页面 / 规则>`

Do not display the complete questionDebt large table every round; complete internally, lightweight externally.

2.8 Preventing premature closure

When any of the following situations occurs, do not end confirmation merely because "two rounds have already been asked" or "a solution can already be written":

There are still 2 or more high-impact remainingDebt They will change fields, permissions, status, exceptions, import strategy, logging/auditing, page working surface, or acceptance criteria.
It is still currently impossible to explain the business value, P0 rationale, or why a certain solution is recommended; in this case, do not write the result as an expert recommendation or finalized solution.
Key rules in the current output mainly come from assumptions rather than user confirmation; especially uniqueness, coverage strategy, deletion/deactivation, import conflicts, and version/effective method.
The user input belongs to the B2B / admin backend / configuration governance category, but key gaps still remain in object granularity, role permissions, batch operations, exception paths, auditing/history, or data sources.
High-risk backend capabilities have already been identified, such as approval, publishing, batch import/export, sensitive fields, existing data migration, or external callbacks, but the corresponding matrix, strategy, or fallback plan has not yet been completed.
Multi-tenancy, version differences, master data ownership, or system boundary issues have been hit, but the source of truth, provisioning model, or conflict handling strategy has still not been explained.
The interaction design has just changed due to user feedback, for example from a drawer to in-table editing; at this point, return to the related question debt and continue confirming the validation, save strategy, status, and edge cases affected by that change.

If further confirmation is needed, prioritize follow-up questions in the order of "rules / data / exceptions / experience" rather than immediately outputting a complete solution.

When hitting the references/confirmation-model.md signal in antiPrematureClosure , in addition to continuing confirmation, you must also treat generationInputGate as not ready, and must not continue to remain in ready-for-review。

3. Main process execution mapping

"Refinement rounds" no longer exist as another independent process, but serve as the execution mapping of the unified main process above. Keep each round concise and do not over-record the obvious.

Main process stage 1: Scenario matching and delivery boundary Determine the requirement type, main playbook, main process object, and target delivery mode; if executing in a repository, also complete project context preloading and the "reuse / extend / redo" judgment.
Main process stage 2: Value / goal / role / P0 Converge business value, success metrics, affected roles, P0 scenarios, MVP boundaries, and non-goals; if these are not stable, do not proceed to page refinement.
Main process stage 3: Objects / fields / rules / states Converge the object model, key fields, state transitions, permissions, exceptions, audit, data sources, and uniqueness/conflict rules.
Main process stage 4: Governance structure and expert judgment Fill in according to the hit scenarios AX01 ~ AX06、BX01 ~ BX05、PB01 ~ PB04; this step is a conditional insertion layer, but once triggered it is a required stage and cannot be skipped.
Main process stage 5: Pages / work surfaces / interactions / acceptance Translate the upstream confirmed structure into navigation, pages, work surfaces, fields/columns/filters/actions, states, and acceptance criteria.
Main process stage 6: Traceability and delivery Allocate S/F/R/D/P/PR IDs, verify traceability relationships, and output only the sections required by the selected delivery mode; if downstream needs page generation or acceptance, also enter generationReviewPack and generationInputGate。

Execution requirements:

Stage 4 is conditional insertion layer, not optional polishing; after hitting governance complexity it must be executed.
Stage 5 can only be built on the premise that the high-impact debt of stages 2-4 has been converged or authorized assumptions have been obtained.
Stage 6 does not mean entering generation by default; if the user only wants a solution, PRD, or page list, it should end at the corresponding minimum delivery mode.

Traceability model

When the output is more than a quick summary, use stable IDs:

S01: user scenario
F01: feature / module
R01: business rule
D01: data object
P01: page / modal / work surface
PR01: page prompt

Complex requirements should include a coverage matrix showing the relationship of "scenario -> feature -> rule -> page -> prompt". For the table structure see references/output-templates.md。

B2B expert artifacts

When the user wants not just "organized requirements" but "product recommendations with judgment", prioritize supplementing the following expert artifacts. They can be output separately or merged into the product solution, PRD appendix, or backend-ops-pack。

BX01 业务价值与优先级判断: answer why do it, why do it now, why it is P0
BX02 方案取舍表: answer why choose this solution rather than another
BX03 多租户 / 版本 / 开通模型: answer tenant isolation, package differences, feature enablement, and customer differentiation
BX04 主数据与系统边界: answer source of truth, creation ownership, synchronization method, and conflict resolution
BX05 反模式与风险提示: answer where the current solution is dangerous, why it is dangerous, and what the minimum line of defense is

High-frequency industry playbooks

When the requirements clearly hit the following high-frequency B2B scenarios, do not just continue using the general requirements refinement process; you must switch to the corresponding playbook and include that scenario's key questions, key artifacts, and key anti-patterns in this round's output or items to be confirmed.

PB01 Ticket / Approval / SLA Playbook

Trigger signals:

tickets, approvals, dispatch, reassignment, return, withdrawal, reminder, escalation, timeout, SLA, node responsibility
multi-role relay handling, process node transitions, time limit constraints, manual handling closed loop

Must-ask questions:

Who initiates the ticket/document, who accepts it, who handles it, who approves it, who provides fallback
What state nodes exist, which nodes can be rolled back, withdrawn, reassigned, countersigned, or terminated
At which point does the SLA start counting, at which point does it end, and how does escalation work after it is overdue
What are the boundaries between rejection, return, cancellation, voiding, and resubmission
Is there a need for reminders, notifications, CC, escalation, automatic reassignment, or manual fallback

Required artifacts:

AX02 状态流转表
AX04 异常与审计矩阵
BX02 方案取舍表
If time-limit management exists, add one more PB01 SLA 责任表

### PB01 SLA 责任表

| 节点 | 责任角色 | 开始计时点 | 截止时限 | 超时处理 | 通知对象 | 备注 |
| --- | --- | --- | --- | --- | --- | --- |
| 待受理 | 一线客服 | 工单创建成功 | 15 分钟 | 超时升级给组长 | 客服/组长 | P0 |
| 待审批 | 审批人 | 提交审批后 | 4 小时 | 超时催办，24 小时后转上级 | 审批人/创建人 | 待确认 |
| 待处理 | 处理人 | 审批通过后 | 2 个工作日 | 超时转派或升级 | 处理人/主管 | 当前假设 |

Common anti-patterns:

Only states, no node owners
Only a flowchart, no SLA start/end definition
Mixing return, rejection, cancellation, and termination into one action
Only approval, no overdue handling, reassignment, reminders, or manual fallback

PB02 Settlement / Reconciliation / Invoice Playbook

Trigger signals:

Settlement statement, bill, reconciliation statement, accounts receivable/payable, invoicing, red-letter reversal, voiding, tax amount, write-off, payment term
Amount definition, document association, financial review, reconciliation differences, invoice flow

Must-ask questions:

Where does the amount come from, who is the source of truth, and how is the amount definition defined
What are the rules for settlement cycle, payment term, billing, account locking, write-off, voiding, and red-letter reversal
Is reconciliation item-by-item, summary, or difference-based, and how are differences attributed and handled
Is the invoice applied for, reviewed, issued, mailed, received, or only the result registered
Are amount fields allowed to be modified, and does modification affect historical documents or audit

Required artifacts:

BX04 主数据与系统边界
AX02 状态流转表
AX03 字段字典
If accounting definitions are involved, add one more PB02 金额口径与单据关系表

### PB02 金额口径与单据关系表

| 单据/对象 | 金额字段 | 口径说明 | 来源系统 | 是否可编辑 | 关联单据 | 异常处理 | 备注 |
| --- | --- | --- | --- | --- | --- | --- | --- |
| 结算单 | settlementAmount | 最终应结金额 | 结算系统 | 否 | 对账单/发票 | 差异需人工复核 | P0 |
| 对账单 | reconAmount | 对账汇总金额 | 对账服务 | 否 | 结算单 | 差异生成对账异常 | 当前假设 |
| 发票申请 | invoiceAmount | 申请开票金额 | 财务后台 | 审核前可改 | 结算单 | 超开需拦截 | 待确认 |

Common anti-patterns:

The page is built, but the amount definition is not defined
Settlement, reconciliation, and invoicing have no relationship model
The boundaries between voiding, red-letter reversal, write-off, and reissue are unclear
Manual amount changes are allowed, but there is no audit or impact statement

PB03 Account / Organization / Permission Playbook

Trigger signals:

Account, member, organization, department, position, role, permission, data permission, tenant administrator, SSO, invitation, disabling
Personnel management, organizational structure, segregation of duties, unauthorized access control, account lifecycle

Must-ask questions:

What do organization, department, position, and role each represent, and who inherits from whom
Is the account lifecycle invitation, activation, freezing, disabling, offboarding recovery, or another model
Do permissions take effect by role, position, department, data scope, or field scope
Are there special identities such as tenant administrator, super admin, auditor, or read-only role
Is SSO, LDAP, third-party identity source, or cross-tenant account policy needed

Required artifacts:

AX01 权限矩阵
AX03 字段字典
BX03 多租户 / 版本 / 开通模型
If the organizational relationships are complex, add one more PB03 组织继承与授权边界表

### PB03 组织继承与授权边界表

| 维度 | 定义 | 是否继承 | 可否下放 | 冲突处理 | 备注 |
| --- | --- | --- | --- | --- | --- |
| 部门权限 | 部门级基础菜单权限 | 是 | 否 | 上级覆盖下级 | P0 |
| 岗位权限 | 岗位职责权限包 | 否 | 是 | 岗位权限与角色取并集 | 当前假设 |
| 数据权限 | 按部门/本人/全部数据范围 | 是 | 是 | 就近最小权限优先 | 待确认 |
| 字段权限 | 敏感字段查看与编辑权限 | 否 | 否 | 超管例外 | P0 |

Common anti-patterns:

Only role permissions, no data permissions
Confusing organizational structure with permission structure
Disabling an account does not revoke permissions or handle in-flight tasks
Sensitive fields are only hidden on the front end, without product rules or audit definitions

PB04 Configuration Center / Release / Rollback Playbook

Trigger signals:

Configuration center, rule engine, release, gray release, take effect, rollback, version, draft, approval release, environment differences
Parameter configuration, strategy configuration, switch control, template configuration, operational rules

Must-ask questions:

What is the configuration item granularity: is it effective by tenant, by environment, by business line, or by object?
Is the effective method immediate, scheduled, canary, or published after approval?
What is the version model, and does it support drafts, historical versions, comparison, and rollback?
How are configuration conflicts handled, and what are the priority and override order?
How are publish failures, rollback, dependency validation, and misoperation protection handled?

Required deliverables:

BX02 方案取舍表
AX02 状态流转表
AX06 存量系统改造与发布策略
If the configuration is complex, add another PB04 配置生效与覆盖顺序表

### PB04 配置生效与覆盖顺序表

| 配置层级 | 生效范围 | 优先级 | 生效方式 | 回滚方式 | 备注 |
| --- | --- | --- | --- | --- | --- |
| 全局默认配置 | 全租户 | 1 | 发布后生效 | 回退到上一版本 | P0 |
| 租户级配置 | 单租户 | 2 | 发布后覆盖全局 | 租户级回滚 | 当前假设 |
| 活动级临时配置 | 单活动/短期 | 3 | 定时生效/失效 | 到期自动失效 | 待确认 |

Common anti-patterns:

Turning the configuration center into an ordinary form where 'submission takes effect immediately'
No versions, comparison, rollback, or dependency validation
Unclear override order between global configuration and tenant configuration
Only building pages, without a publish process or failure fallback

Playbook usage rules

When a playbook is hit, at least explicitly mark it in the current round of output:当前命中 PB0X
If the requirements hit multiple playbooks at the same time, first follow primary process object to choose the primary playbook, then treat the remaining playbooks as supplementary constraints
A playbook is not a decorative section; once hit, it must affect the question rounds, deliverable selection, page prompts, and gate judgment
If the requirements provided by the user clearly belong to one of the above four categories, but the output does not reflect the corresponding playbook's key questions, key deliverables, or anti-pattern checks, it is considered incomplete

B-end enhancement deliverables

When the corresponding scenario is hit, in addition to the standard product solution/page list/prompts, the following backend-native deliverables should also be supplemented. If the current round cannot produce them completely, they must at least be explicitly recorded as items to be confirmed and must not be silently skipped.

AX01 权限矩阵: Applicable to multi-role, multi-tenant, sensitive data, field-level visibility, or dangerous operation scenarios. At least include 角色 / 岗位 / 资源对象 / 动作 / 数据范围 / 字段范围 / 脱敏规则 / 审批或二次确认要求 / 审计要求。
AX02 状态流转表: Applicable to requirements with lifecycle states such as approval, work orders, publishing, handling, and configuration taking effect. At least include 当前状态 / 触发动作 / 执行角色 / 前置条件 / 后置状态 / 副作用 / 通知对象 / 是否可撤回或补偿。
AX03 字段字典: Applicable to requirements with complex objects, fields shared across pages, or strong binding to APIs/import templates. At least include 字段名 / 含义 / 类型 / 来源 / 是否必填 / 默认值 / 校验 / 枚举 / 显隐规则 / 是否脱敏 / 是否可编辑。
AX04 异常与审计矩阵: Applicable to operational handling, manual fallback, dangerous operations, compliance traceability, or failure rollback scenarios. At least include 异常场景 / 用户可见提示 / 系统记录 / 审计日志 / 补救动作 / 是否通知 / 是否可重试。
AX05 批量 / 导入导出 / 异步任务规范: Applicable to batch changes, large table exports, file imports, and long-running tasks. At least include 触发方式 / 规模限制 / 预校验 / 部分成功策略 / 失败明细 / 进度反馈 / 结果回执 / 幂等与重试 / 权限要求。
AX06 存量系统改造与发布策略: Applicable to legacy system replacement, rule refactoring, field revision, and platform migration. At least include 现状问题 / To-Be 差异 / 数据迁移 / 权限迁移 / 兼容期 / 灰度范围 / 回滚方案 / 培训或运营切换要求。

Backend enhancement deliverables are not all required by default. The minimal set should be selected according to the scenarios hit by the requirements:

When multi-role / sensitive fields / data permissions is hit, at least output AX01, and if necessary also AX03
When approval / work order / publishing / lifecycle is hit, at least output AX02
When operational handling / high-risk actions / compliance requirements is hit, at least output AX04
When batch processing / import and export / long-running tasks is hit, at least output AX05
When legacy system transformation / smooth migration / go-live cutover is hit, at least output AX06

B-end enhancement deliverable templates

The following templates can be directly written into the conversation, Markdown deliverables, PRD appendix, or backend-ops-pack. If the information has not yet been confirmed, use 待确认、当前假设、不适用 to mark it, and do not leave blank columns pretending it has been converged.

AX01 Permission Matrix Template

Applicable when:

Multiple roles, multiple positions, multiple tenants
Data scope isolation exists
Field masking and field read-only exist
Dangerous operations, approvals, or dual-person review exist

### AX01 权限矩阵

| 角色/岗位 | 资源对象 | 动作 | 数据范围 | 字段范围 | 脱敏规则 | 二次确认/审批要求 | 审计要求 | 备注 |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| 超级管理员 | 账号 | 查看/新增/编辑/停用 | 全量 | 全字段 | 不脱敏 | 停用需二次确认 | 记录操作者、时间、前后值 | P0 |
| 运营专员 | 工单 | 查看/处理 | 所属团队 | 除手机号外可见 | 手机号后四位可见 | 转派需填写原因 | 记录处理动作与原因 | 当前假设 |
| 财务审核员 | 结算单 | 查看/审核 | 所属租户 | 金额字段只读、发票字段可见 | 银行账号脱敏 | 审核通过需二次确认 | 审核日志保留 180 天 | 待确认 |

Minimum requirements:

Each key role must cover at least one core resource object
Dangerous actions must explicitly state secondary confirmation, approval, or dual-person review requirements
When sensitive information is involved, the masking specification must be clearly stated, rather than only writing "partially visible"

AX02 State Transition Table Template

Applicable when:

Approval flows, work order flows, release flows, handling flows
Any object has 3 or more business states
State changes trigger notifications, audits, callbacks, or side effects

### AX02 状态流转表

| 当前状态 | 触发动作 | 执行角色 | 前置条件 | 后置状态 | 副作用/系统动作 | 通知对象 | 可撤回/补偿 | 备注 |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| 草稿 | 提交审核 | 创建人 | 必填字段完整 | 待审核 | 生成提交记录 | 审核人 | 可撤回，撤回后回到草稿 | P0 |
| 待审核 | 审核通过 | 审核员 | 审核意见非空 | 已生效 | 写入生效时间、发布版本 | 创建人/订阅人 | 不可撤回，可走停用流程 | 当前假设 |
| 待审核 | 驳回 | 审核员 | 驳回原因必填 | 已驳回 | 记录驳回原因 | 创建人 | 不适用 | P0 |
| 已生效 | 停用 | 管理员 | 无未完成关联任务 | 已停用 | 写入停用日志、触发缓存失效 | 运营负责人 | 可恢复，恢复后回到已生效 | 待确认 |

Minimum requirements:

Each business state must have at least an entry path and an exit path
Side effects must be clearly stated; do not only write "update status"
If a state is irreversible, compensation or an alternative process must be specified

AX03 Field Dictionary Template

Applicable when:

Objects are complex and many fields are reused across pages
Pages, APIs, and import templates share the same set of fields
Enumerations, linkages, show/hide, masking, or read-only controls exist

### AX03 字段字典

| 字段名 | 含义 | 类型 | 来源 | 必填 | 默认值 | 校验规则 | 枚举/示例 | 显隐/联动规则 | 脱敏/编辑规则 | 备注 |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| tenantId | 所属租户 ID | string | 系统注入 | 是 | 当前登录租户 | 不可为空 | `t_1001` | 创建后只读 | 不脱敏，不可编辑 | P0 |
| status | 状态 | enum | 系统计算/人工操作 | 是 | `draft` | 必须为合法状态值 | `draft/pending/active/disabled` | 随流程变化 | 不脱敏，部分角色只读 | 需对齐 AX02 |
| ownerMobile | 负责人手机号 | string | 人工输入 | 否 | 空 | 11 位手机号 | `138****1234` | 仅在负责人类型=内部员工时展示 | 默认脱敏，管理员可查看明文 | 待确认 |
| effectiveTime | 生效时间 | datetime | 人工选择 | 否 | 立即生效 | 不得早于当前时间 | `2026-07-16 18:00` | 当生效方式=定时生效时必填 | 不脱敏，可编辑至生效前 | P1 |

Minimum requirements:

Key fields must state their source: manual entry, system calculation, or external synchronization
Enumeration fields must list their value domains
Fields strongly coupled with permissions, states, or import templates must include remark references

AX04 Exception and Audit Matrix Template

Applicable when:

High-risk operations, manual handling, compliance traceability
Remediation, notification, or retry is required after failure
User prompts and system logs must not be written together

### AX04 异常与审计矩阵

| 异常/风险场景 | 用户可见提示 | 系统记录 | 审计日志 | 补救动作 | 通知对象 | 可重试 | 备注 |
| --- | --- | --- | --- | --- | --- | --- | --- |
| 导入文件格式错误 | 提示模板错误并给下载入口 | 记录任务失败原因 | 记录导入人、文件名、失败原因 | 允许重新上传 | 导入发起人 | 是 | P0 |
| 批量停用部分失败 | 提示“3 条成功，2 条失败”并可下载明细 | 保存成功/失败明细 | 记录每条对象的停用结果 | 支持按失败明细重试 | 操作人/管理员 | 是 | 当前假设 |
| 审核通过后回调下游失败 | 提示“审核成功，下游同步失败，系统稍后重试” | 记录回调响应码 | 记录审核人与回调失败上下文 | 系统自动重试，超限后人工介入 | 运维/业务负责人 | 是 | 需结合平台策略 |
| 超级管理员删除高风险配置 | 弹确认框并要求填写原因 | 记录删除请求 | 记录操作前后值、原因、审批链路 | 不支持直接恢复，需走回滚流程 | 安全管理员 | 否 | 待确认 |

Minimum requirements:

Distinguish the three layers: user prompts, system records, and audit traceability
High-risk actions must state whether they are retryable and whether they are recoverable
When notifications are involved, the notification recipients must be stated; do not only write "notify relevant personnel"

AX05 Batch / Import-Export / Asynchronous Task Specification Template

Applicable when:

File import, batch changes, large-table export
Task execution exceeds the frontend synchronous wait time
Partial success, failure details, or result receipts exist

### AX05 批量 / 导入导出 / 异步任务规范

| 场景 | 触发方式 | 规模限制 | 预校验 | 执行方式 | 部分成功策略 | 失败明细 | 进度反馈 | 结果回执 | 幂等/重试 | 权限要求 | 备注 |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| 批量导入账号 | 上传 Excel | 单次 5000 行 | 模板校验、必填校验、唯一性预检 | 异步任务 | 成功与失败分开统计 | 支持下载失败行 | 任务中心 + 站内消息 | 导入结果文件保留 7 天 | 文件指纹去重，允许手动重试 | 账号管理-导入 | P0 |
| 批量停用商品 | 列表勾选 + 批量操作 | 单次 200 条 | 校验状态是否可停用 | 同步 + 后台补偿 | 显示成功/失败数量 | 表格弹层展示失败原因 | 前端即时反馈 | 操作完成 toast + 审计记录 | 失败项可二次重试 | 商品运营-停用 | 当前假设 |
| 导出对账单 | 筛选后点导出 | 单租户 10 万条 | 权限校验、导出字段校验 | 异步任务 | 不适用 | 失败时给失败原因 | 任务中心 | 下载链接 24 小时有效 | 同条件 10 分钟内复用同一任务 | 对账单-导出 | 待确认 |

Minimum requirements:

State whether it is synchronous or asynchronous
State how failure details are carried
Tasks exceeding the frontend's immediate processing capability must provide progress feedback and result receipts

AX06 Legacy System Transformation and Release Strategy Template

Applicable when:

Old system upgrades, coexistence of old and new rules
Historical data migration, permission migration, traffic switching, or canarying is involved
Rollback, training, or operational switching is required

### AX06 存量系统改造与发布策略

| 主题 | 现状 As-Is | 目标 To-Be | 改造策略 | 风险 | 灰度/切换方式 | 回滚方案 | 负责人/协同方 | 备注 |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| 数据迁移 | 老表字段缺少租户维度 | 新模型按租户隔离 | 脚本补齐租户字段后分批迁移 | 脏数据导致迁移失败 | 先灰度 10% 租户 | 保留老表读能力 7 天 | 后端/DBA | P0 |
| 权限迁移 | 老系统仅角色权限 | 新系统含数据权限和字段脱敏 | 先映射角色，再补数据范围 | 角色映射错误导致越权 | 仅对试点租户开启 | 一键回切旧权限配置 | 后端/安全/产品 | 当前假设 |
| 功能切换 | 老后台仍可编辑 | 新后台接管编辑能力 | 先只读旧后台，再切新后台写入 | 双写不一致 | 分租户切流 | 关闭新入口，恢复旧入口 | 前端/后端/运营 | 待确认 |
| 培训与运营 | 线下口口相传 | 提供操作手册与公告 | 上线前培训 + 上线后答疑群 | 一线使用不熟导致误操作 | 试点团队先培训 | 延长双系统并行期 | 运营/客服/培训 | P1 |

Minimum requirements:

Cover at least the 4 categories: data migration, permission migration, switching method, and rollback plan
If there is no legacy system, explicitly write 不适用
Canarying and rollback must not only be written as "supported"; the scope and actions must be stated

Backend Coverage Matrix Template

When requirements are complex and the output spans more than one page, in addition to "scenario -> feature -> rule -> page -> prompt", it is recommended to add a backend enhancement coverage matrix to ensure that key governance structures are not left outside the pages.

### 后台增强覆盖矩阵

| 场景 ID | 功能 ID | 规则 ID | 页面 ID | 提示词 ID | 后台增强产物 ID | 说明 |
| --- | --- | --- | --- | --- | --- | --- |
| S01 | F01 | R01/R03 | P01/P02 | PR01/PR02 | AX01/AX03 | 列表与编辑页受权限矩阵和字段字典约束 |
| S02 | F02 | R04/R05 | P03 | PR03 | AX02/AX04 | 审批流页面受状态流转和异常矩阵约束 |
| S03 | F03 | R06 | P04 | PR04 | AX05 | 导入任务页依赖批量任务规范 |

Usage requirements:

Each P0 scenario must map to at least one backend enhancement artifact or be explicitly marked 不需要
If page prompts are constrained by AX artifacts, the matrix must be able to trace them back to the corresponding AX ID

Generate product solution

Before generating the page list, first output a compact solution section:

Product positioning: explain in one sentence
MVP goal: what the first usable version must satisfy
User roles: roles, positions, tenant/organization relationships, and permission differences
Business value: core pain points, current alternatives, why do it now, and rationale for P0
Core flow: a numbered flow from entry to completion, prioritizing the backend operation path and responsibility handoffs
Functional modules: capabilities grouped by feature ID
Backend work surfaces: how work surfaces such as lists, details, editing, configuration, approval, batch operations, import/export, and auditing are allocated
Data objects: important entities with data IDs, key fields, uniqueness, ownership, and source
Business rules: constraints, validation, permissions, data permissions, and state transitions with rule IDs
Industry playbook determination: if it matches PB01 ~ PB04, explicitly state 当前命中 PB0X, the primary playbook, supplementary playbooks, and which industry constraints the solution is subject to
Solution trade-offs: explain key structural decisions and their recommended rationale
Multi-tenant / version / activation model: if relevant, explain how capabilities take effect by tenant, version, or configuration
Master data and system boundaries: if relevant, explain the source of truth, synchronization direction, and conflict handling
Backend enhancement artifacts: supplement permission matrices, state transition tables, field dictionaries, exception and audit matrices, batch specifications, or migration strategies according to the matched scenarios
Success metrics: preferably written as backend metrics such as efficiency, accuracy, SLA, exception rate, processing time, and operational cost
Risks, assumptions, non-goals, and open questions: keep only content that affects product decisions

Business rules must be specific enough to guide design and implementation. In complex products, they should be categorized by permissions, data permissions, validation, lifecycle/state, data visibility, audit/history, notifications, SLA, failure recovery, conflict/idempotency, and metrics/data definitions.

Generate product PRD

When the user requests a formal PRD, requirements document, product document, review material, or online collaborative document, generate a product PRD based on the confirmed content. For the main body structure, see references/product-prd-template.md。

Generation rules:

The PRD main body includes: document information, background and goals, users and scenarios, core functional requirements, business rules, exception flows, page list, dependencies and risks, acceptance criteria, and items to be confirmed/next steps.
When requirements match a backend enhancement scenario, the PRD main body or its appendix should explicitly reference the corresponding backend enhancement artifacts; at minimum, it should state whether these artifacts have been confirmed and in what form they will be delivered.
When requirements match PB01 ~ PB04 , the PRD main body or its appendix should also explicitly reference the key constraints or scenario tables of the corresponding playbook, such as SLA responsibilities, amount definitions, organization inheritance boundaries, and configuration override order; do not write only generic feature descriptions.
The PRD body must not contain: page-level prompts, HiUI handoff packages, machine plans, or generation gate details.
If high-impact remainingDebtstill exists, the PRD can only be marked as "draft / pending confirmation version / review draft" and must not be written as a confirmed final version.
The first sentence of the background should prioritize answering "why do this now"; goals should preferably be written as "current value -> target value -> time range"; non-goals must be explicitly listed.
Feature descriptions should preferably use "trigger condition -> processing logic -> output result"; acceptance criteria should be written as much as possible in a form that can be judged pass/fail.
When text and tables are insufficient to clearly express the product structure, diagrams should be added rather than continuing to pile on words; diagram types and consistency checks are performed according to references/product-prd-template.md、references/delivery-modes.md .
Output channel rules: first follow references/product-prd-template.md to execute hasFeishuDocCapability、onFeishuWriteFailure = fallbackToMarkdown and messageReturnFormat = title + link_or_path + short_summary。
If the current delivery mode includes product-prd, and the host environment has collaborative document creation capability (for example, Feishu), prioritize generating an online collaborative document and return the document title and link; if writing to the collaborative document fails, then fall back to a Markdown file and return the path. Only inlining the PRD body in a message without producing a document does not count as complete.
If the user explicitly needs both a PRD and downstream generation input, or the current delivery mode has already been confirmed as full-prd-to-generation, produce both the PRD and the generation package at the same time; otherwise keep the selected minimal delivery mode and do not expand on your own. The two must be displayed separately or stored separately, and must not be mixed into a single body.

Readiness check

After the following content has been confirmed or explicitly assumed, proceed to the page list and prompts:

P0 user scenarios have been listed.
The main roles and permission differences have been clarified.
The business value, P0 rationale, and basis for the recommended solution have been explained, rather than only listing features.
Core objects and lifecycle states have been defined.
Key business rules and exceptions have been captured.
The matched backend enhancement artifacts have been produced or explicitly marked as pending confirmation.
If a B2B/SaaS/platformization scenario is matched, multi-tenancy, version differences, feature enablement, and master data boundaries have been clarified, or explicitly marked as pending confirmation.
The entry point and completion result have been clarified.
The user has selected or accepted the target platform and output format.

If readiness is weak but the user requests output, continue producing it, but assumptions and risks must be marked. If the output will be used downstream for page generation, weak readiness must not be disguised as confirmed; the user must confirm the generation input or explicitly authorize assumptions.

If high-impact remainingDebtstill exists, the result must not be marked as confirmed; you may only continue confirming, mark it as an assumption, or wait for the user to explicitly authorize assumptions.

Generate page list

Create a page list covering all P0 flows. Each row must include:

Page ID
Page name
Work surface type: page, modal, drawer, step flow, tab, detail panel, configuration panel, or embedded work surface
Route or location, if relevant
Associated scenario ID, feature ID, rule ID, and prompt ID
User goal
Entry and exit
Core modules
Key fields/columns/filters/operation summary, at minimum explaining what this page displays, what it edits, what it filters by, and which key actions can be performed
Primary actions
States to design: default, empty, loading, error, permission-restricted, success, and related edge cases
Dependencies or required data
Associated backend enhancement artifact ID, if relevant
MVP priority: P0, P1, P2
When the target platform is HiUI or an admin/B2B backend, provide HiUI page type recommendations:table-basic、table-stat、tree-table、tree-split、drawer-form、drawer-detail、full-page-edit、full-page-detail、data-visualization、feedback、non-typical or unresolved

When a strict table structure is required, use references/output-templates.md。

Do not split pages mechanically. Use a new page for independent navigation destinations, persistent URLs, responsibility boundaries, or long flows; use a modal, drawer, detail panel, tab, or step flow for local tasks, confirmations, quick edits, progressive disclosure, or tightly coupled sub-flows.

Generate global context

Before page-level prompts, first write a global context inherited by all pages:

Product name, positioning, and platform
Target users and role/permission model
Navigation model and page hierarchy
Core data objects and naming conventions
Shared business rules and state definitions
Shared UI / component constraints or design system
Shared states, feedback patterns, and copy tone
Known assumptions and out-of-scope items

This prevents independently generated pages from drifting in terminology, fields, navigation, permissions, and the visual system.

Generate page-level prompts

For each page in the list, write a prompt that other AI can use to generate page design, prototype, or implementation. Each prompt must be usable independently while referencing the global context.

Each page prompt must include:

Prompt ID, page ID, page name, and associated scenario/feature/rule IDs
Page purpose and target users
User goals and completion criteria for this page
Layout structure and information hierarchy
Module-level structure breakdown; do not just write abstract module names; each module must explain its position, responsibility, and the information it carries
Fields/columns/filter items/operation details for each module: name, meaning, component or display method, required/read-only, source or definition, default value/empty value, validation/visibility/linkage conditions
List-type pages must also provide the filter area, metric area, table columns, sorting/pagination, row actions, and bulk actions; form-type pages must also provide field grouping, control types, save strategy, and submission feedback; detail-type pages must also provide information sections, status labels, timeline/record blocks, and navigation relationships
When helpful, provide example data structures or field examples that downstream agents can directly consume
Primary and secondary actions
Interaction rules, validation rules, permission rules, and state changes
If it hits PB01 ~ PB04, you must explicitly bring in the corresponding playbook's in-page constraints in the prompt, such as SLA node responsibilities, amount definitions and document relationships, organizational inheritance and authorization boundaries, and configuration effectiveness and override order; do not merely mention them lightly in the global context
If the page is constrained by a permission matrix, state transition table, field dictionary, bulk specification, or exception matrix, you must explicitly reference its key constraints rather than re-imagining them in the page prompt
Default, empty, loading, error, permission, success, and related boundary states
Cross-page navigation and handoff behavior
Known visual or component system constraints
Acceptance criteria

Avoid vague prompts such as "make it look good" or "modern dashboard" unless the user explicitly requests style exploration. Replace them with specific layout, content, behavior, state, and acceptance requirements.

When these prompts will be used for downstream generation confirmation, the full body text must be delivered, not a summarized version. If the content is too long, it may be written to a separate artifact file; however, before confirmation, the complete file path must be provided, and the user must be able to directly view the full text.

If the page prompt still has more than 3 important blanks that would change layout, fields, validation, or actions, or if the main content is still only abstract module names without field/column/filter/action details, it must fall back to continued confirmation or be marked as a to-be-confirmed version, and must not be output as a prompt package that can be directly generated.

Generate HiUI handoff package

When the user needs HiUI page generation, page acceptance, or handoff to a downstream HiUI page workflow (for example hiui-page-workflow), add a compact handoff package after the page list and prompts. See the template at references/hiui-handoff-template.md。

The handoff package must include:

Product name, target platform, and recommended workflow level
Page list: page ID, page name, route/location, HiUI page type, priority, associated scenario/rule/prompt ID, and required design states
Shared global context references and component/design system constraints
Associated backend enhancement artifacts and their status: which are confirmed, which are to be confirmed, and which are being advanced only as assumptions
Data/mock assumptions, permission assumptions, and open risks that may affect generation or acceptance
Recommended generation order, usually generating P0 list/detail/edit/core flow pages first
requirementGate and generationInputGate status; if gaps remain, they must be marked as assumption-authorized or blocked, and must not be written as confirmed.

Interaction mode

When the user wants to continue refining

Use the loop:

Summarize the current version and changes.
Update questionDebt, identify the top 1-3 highest-impact issue groups.
Raise option-based confirmation questions covering the main decision branches, or provide recommended assumptions.
Update scope, flow, traceability relationships, pages, and prompts based on the user's answers.
Output lightweight confirmation progress, and decide whether to continue confirmation, output deliverables, wait for authorized assumptions, or adjust scope.

"Update based on the user's answers" here is not a generalized statement; it must explicitly show how the previous round's answers cleared questionDebt, triggered playbook / AX / BX artifacts, or changed the direction of the next round of questions.

When continuing refinement, by default proceed in the stage order of the "unified main flow":

Scenario matching and delivery boundaries
Value / goals / roles / P0
Objects / fields / rules / states
Governance structure and expert judgment
Pages / work surfaces / interactions / acceptance
Generation input confirmation or delivery output

Supplementary rules:

If the current output is only a solution, PRD, or page list, rather than entering page generation, the downstream may end at the non-generation exit of stage 5 or stage 6, and does not have to forcibly enter generationInputGate。
If a backend enhancement scenario is hit, Stage 4 automatically becomes a mandatory stage, rather than "add a matrix later when there's time."
If hit PB01 ~ PB04, the corresponding playbook's must-ask questions and structured artifacts should enter Stages 3-4 first, and must not wait until the page stage to be added.

When the user wants immediate output

produce a first complete version of the result based on assumptions. Clearly mark assumptions, and include "suggested confirmation for the next round." If what the user wants is a PRD or review draft, maintain a formal document tone, but explicitly distinguish "confirmed," "current assumptions," and "items to be confirmed." If the result will next enter page generation, HiUI generation, prototype generation, or UX acceptance, you first need to distinguish 评审草稿 and 生成稿: the former can be used to discuss direction, but must not enter generation input confirmation; the latter is allowed to enter generation input confirmation only after key pages have passed field/column/filter/action-level granularity validation. If there are still high-impact remainingDebtthat would change the object model, fields, permissions, status, interactions, or key rules, you may only output "first version plan + points to be confirmed + recommended next-round questions," and must not write these contents as a converged final version.

When the user already has a PRD, notes, or external materials

read the materials, extract existing decisions, identify gaps, and avoid repeatedly asking for information that already exists in the materials. Then output standardized results according to the workflow.

Artifact strategy

Short outputs are answered directly in the conversation. For long prompt packs, complete PRDs, or HiUI handoff packs, if the user requests reusable files, suggest or create a separate artifact. Artifact layering:

product-prd: only product-layer sections are allowed; when collaborative document capability is available, it must be placed in an online collaborative document and a link returned; when collaborative document capability is unavailable, it must be placed as a standalone Markdown document and an absolute path returned.
generation-review-pack: used only for user confirmation, and must include the page list and complete page-level prompts; if the current delivery mode includes product-prd, additionally include product-prd 's link or path evidence; must not retain only a summary.
backend-ops-pack: produced only when a backend enhancement scenario is hit, and may include a permission matrix, status transition table, field dictionary, exception and audit matrix, batch specifications, and migration release strategy; it may be a standalone file or an attached section of generation-pack.
generation-pack: only global context, page list, page-level prompts, and the HiUI handoff pack are allowed; if a backend enhancement scenario is hit, it may attach or reference backend-ops-pack。full-prd-to-generation must be split into product-prd and generation-pack as two independent sections or files. For human review, prefer online collaborative documents or Markdown; use JSON only when machine handoff or validation requires it. The sections allowed and prohibited items for each mode are governed by references/delivery-modes.md .

Quality gate

Before final output, check product completeness:

Product goals, target users, P0 scenarios, MVP boundaries, and non-goals are clear.
Success metrics or acceptance signals are defined.
Organization / tenant / department / position / data permission boundaries are clear, or explicitly marked as to be confirmed.
Core objects, lifecycle states, permissions, validation, and exception paths are covered.
If multi-role, multi-state, batch, import/export, sensitive field, external dependency, or legacy transformation scenarios are hit, the corresponding backend enhancement artifacts have been produced or explicitly marked as to be confirmed.
For B2B / admin backend / configuration governance requirements, the object granularity, uniqueness/conflict rules, bulk import or bulk operations, logging/audit policy, and workspace selection must at least be confirmed or explicitly marked as assumptions.
For the typical backend workspaces—list, detail, edit, configuration, approval, bulk, import/export, and audit—it has been made clear which are in P0 and which are not done.
If multiple feasible options exist, the recommended option and the reasons for not recommending the others have been made clear.
If there are multi-tenancy, version differences, master data ownership, system boundaries, or customer differentiation issues, expert judgment has been provided rather than leaving the issues for downstream implementation to guess.
If the requirements clearly fall under one of ticket/approval/SLA, settlement/reconciliation/invoicing, account/organization/permissions, or configuration center/release/rollback, the corresponding playbook has been applied, rather than only doing generic backend requirements refinement.
Each P0 scenario is mapped to at least one page, modal, or workspace.
Each generated page, modal, drawer, or workspace can be traced back to a P0/P1 scenario, feature, and prompt, or is explicitly marked as supporting infrastructure.
Each page has a clear user goal, entry point, exit point, data dependencies, and prompt ID.
The page list used for generation includes at least key fields/columns/filters/action summaries; page-level prompts include at least a field list, column list, or an equivalent control-detail structure.
CRUD operations include permissions, validation, feedback, failure states, and audit/history where reasonable.
Business rules distinguish, where relevant, permissions, validation, lifecycle/state, data visibility, audit/history, notification/SLA, failure recovery, conflict/idempotency, and metric definitions.
Search, filter, sort, pagination, import/export, bulk operations, notifications, and audit/history are included only when justified.
Global context can prevent cross-page naming, data, navigation, permission, and component drift.
The page list avoids over-splitting and also avoids over-compressing different responsibilities into one workspace.
Page prompts are specific enough that other agents do not need to repeatedly ask the same batch of product questions.
If page prompts still use abstract module names in place of fields, columns, filters, or action details, they are judged incomplete and must not be marked as confirmed。
If the next step is very likely HiUI generation, the HiUI handoff package includes routes, HiUI page types, states, priorities, prompt IDs, assumptions, and generation order.
If the next step is very likely page generation, it must include generationInputGate status; if unconfirmed, it can only be ready-for-review、assumption-authorized or blocked, and must not default to confirmed。
If the next step is very likely page generation, it must also have generationReviewPack: page list and complete page-level prompts; if the current delivery mode includes a PRD, then a PRD online document link or Markdown path is additionally required. If any required item is missing, it must not be marked as confirmable for generation.
If the next step is very likely page generation, and the pages are strongly constrained by a permission matrix, state transitions, field dictionary, or bulk rules, these backend enhancement artifacts must have entered generationReviewPack or backend-ops-pack。
If a formal PRD is output, the body must include background, goals, non-goals, features, rules, exceptions, page list, risks, and acceptance criteria; it must not mix in page-level prompts or HiUI handoff information.
If a formal PRD is output and the requirements include complex flows, state transitions, cross-role collaboration, or multi-object relationships, the main text must also include corresponding diagrams, or explicitly explain why no diagrams need to be added at this time.
Before the final output, the confirmation completeness must be stated; if there is remainingDebt, it must be listed as pending confirmation or assumptions and must not be hidden.
Open questions should retain only decisions that would change scope, behavior, data, permissions, UI, or delivery method.
If the main text contains 3 or more key assumptions that would change pages, fields, rules, or acceptance criteria, it must fall back to a "pending-confirmation version" rather than a "closed plan".
If currently running in an existing repository and the requirements are strongly related to the project, local high-signal context must have been used, or an explicit explanation must be given for why it was not used.

Validation

Before the final output, perform a self-check in the following order, and when necessary fall back to continuing confirmation rather than forcing closure:

Delivery mode check: confirm that the current output matches one of quick-refine、solution-only、product-prd、page-inventory、prompt-pack、hiui-handoff or full-prd-to-generation , with no extra irrelevant sections written and no core content required by that mode omitted.
Confirmation status check: verify whether confirmationDepth、resolvedDebt、remainingDebt、assumptions are consistent; if high-impact remainingDebtstill exist, the result must not be written as confirmed。
Project context check: if currently in an existing repository and the requirements are strongly related to the project, confirm that the minimal repository evidence preload has been completed, and record repoFindings / repoAssumptions / repoConflicts / repoGaps; if local context was not used, the reason must be explained, such as "no valid evidence found", "irrelevant to the current requirements", or "the user explicitly requested to ignore the implementation".
Downstream gate check: if the next step is page generation, HiUI generation, prototype generation, or UX acceptance, confirm that the output includes the generation input confirmation block, and that requirementGate、generationInputGate status is valid; when confirmation has not been obtained, only ready-for-review、assumption-authorized or blocked。
Expert judgment check: confirm that business value, P0 rationale, and the basis for the recommended solution have been explained; if multi-tenant, version, or master data boundary issues are hit, expert judgment has also been provided. When missing, it must not claim to be expert advice.
Playbook check: if the requirements clearly hit one of PB01 ~ PB04 , confirm that the corresponding playbook's must-ask questions, required artifacts, and anti-pattern checks have been executed; when missing, fall back to continuing confirmation.
PRD document check: if outputting product-prd or full-prd-to-generation, confirm that the PRD main text structure conforms to references/product-prd-template.md, and that page-level prompts, HiUI handoff packages, or machine execution details are not mixed in; also confirm that the PRD has been placed in an online collaborative document or Markdown file, and return the link or path.
Field granularity check: if the output includes page-inventory、prompt-pack、hiui-handoff or full-prd-to-generation generation-pack, confirm that key pages have been refined to the field/column/filter/action level, rather than only abstract module names; if high-impact gaps still remain, fall back to continuing confirmation or a pending-confirmation version.
Backend enhancement artifact check: if scenarios with complex permissions, complex states, batch tasks, sensitive fields, external dependencies, or migration/transformation are hit, confirm that the required backend enhancement artifacts have been output, are traceable, and are granular enough to constrain pages and rules; when missing, fall back to continuing confirmation.
Traceability relationship check：When the output includes a page list, prompts, or a HiUI handoff package, confirm that each P0 scenario maps to at least a feature, rule, page, or work surface; every page can be traced back to a scenario, feature, rule, prompt, or related backend enhancement artifact.
Product completeness validation：Against the "Quality Gate" above, check whether goals, roles, scope, rules, data, states, exceptions, pages, acceptance, and risks form a complete closed loop; if any item is missing, fill it in or explicitly mark it as an assumption/to be confirmed.

When any of the following conditions is hit, you must fall back to continuing confirmation, adjusting scope, or marking as a to-be-confirmed version, and must not continue outputting as confirmed, a finalized PRD, or a generation package that can be directly consumed downstream:

remainingDebt still has 2 or more high-impact unknowns that would change fields, permissions, states, page work surfaces, or acceptance criteria
repoConflicts is non-empty, and the conflict of "reuse / extend / redo" has not yet been resolved through user confirmation
Currently unable to explain the business value, P0 basis, or rationale for the recommended solution for doing this, yet attempting to output "expert advice"
The requirement clearly hits PB01 ~ PB04, but the corresponding key questions, artifacts, or anti-pattern checks do not appear
product-prd and generation-pack show content cross-writing, for example, the PRD body is mixed with page prompts, HiUI handoff, or gate details
The key pages in the generation-pack are still stuck at abstract module names, with no field/column/filter/action-level refinement
A backend enhancement scenario is hit, but the permission matrix, state transitions, field dictionary, batch specifications, or migration strategy are still missing, making it impossible for pages or rules to be implemented reliably
Multi-tenancy, version differences, master data ownership, or system boundary issues are hit, but the source of truth, provisioning model, or conflict handling is still unanswered
The next step is preparing to enter page generation, HiUI generation, prototype generation, or UX acceptance, but generationInputGate.status is neither confirmed nor assumption-authorized

Guardrails

Must not package ambiguous input directly as a "complete PRD" or "confirmed solution"; when confirmation is insufficient, you must explicitly retain remainingDebt or assumptions。
Must not skip high-impact questions just to reduce follow-up questions; however, you must also not over-question low-value details, and always keep at most 3 high-impact question groups per round.
Before entering page generation, HiUI generation, prototype generation, or UX acceptance, you must confirm that the generation input has been confirmed by the user, or clearly record it as assumption-authorized / blocked。
Must not automatically treat generalized expressions such as "continue", "let's start", or "generate the page" as authorization for assumptions; only when the user explicitly confirms the generation input or explicitly authorizes assumptions may you enter downstream generation.
Must not fabricate business rules, fields, permissions, state machines, interface constraints, or success metrics; when missing, they may only be marked as assumptions, to be confirmed, or recommended solutions.
Must not mechanically apply templates, causing the output to fail to match the backend form; management backends, operations backends, configuration governance backends, process approval backends, data backends, and platform backends must converge according to their corresponding priorities.
Must not let this skill drift into a general consumer-facing, content community, growth campaign, or marketing strategy assistant; if the input does not belong to a B-end mid/back-office system, it should clearly indicate weak fit rather than pretend to cover everything comprehensively.
Must not replace fields, columns, filters, actions, validation, and state descriptions with abstract module names such as "business overview", "exception list", "product table", or "configuration area"; if refinement is impossible, you must continue confirmation or mark it as a to-be-confirmed version.
Validate that the page list, prompts, HiUI handoff, and gate status are consistent with each other; must not output loose page prompts that cannot be consumed downstream.
Must not stuff page-level prompts, HiUI handoff information, machine plans, or gate details into the formal PRD body; these may only be placed in a separate generated package or appendix.
Must not, when entering generationInputGate , only provide a summary of page prompts; before confirmation, the complete page-level prompts must be provided. If the current delivery mode includes a PRD, a PRD summary alone must also not be provided; an online document PRD link or Markdown path must be provided.
Must not expand scope without explaining the risks; when adding capabilities such as new pages, workflows, batch operations, import/export, notifications, or auditing, the business rationale must be explained.
Must not default to making up the tenant model, data permission model, organizational structure, or audit requirements; these are high-impact decisions for B-end back-office systems, and when missing they must be explicitly asked about or marked as assumptions.
Must not only summarize requirements without making B-end expert judgments; when the user wants "propose a solution / give recommendations / review direction," value judgments, solution trade-offs, and structural decisions must be added.
Must not mistakenly write "can do" as "should do"; if a requirement clearly has low value, high complexity, low frequency that can be handled manually, or excessive governance cost, this must be pointed out rather than blindly recommending systematization.
Must not handle high-frequency industry scenarios in a purely generic back-office way; ticketing/approval/SLA, settlement/reconciliation/invoicing, account/organization/permissions, and configuration center/release/rollback must preferentially apply the corresponding playbook.
Must not, when encountering multi-tenancy, version differences, customer customization, or feature enablement, only write page differences without writing the product model.
Must not, when encountering cross-system objects, only write that an interface exists, without writing the source of truth, creation ownership, synchronization method, conflict handling, and deactivation strategy.
Must not write the permission matrix, state transitions, field dictionary, batch specifications, or migration strategy as only one or two abstract sentences; when relevant scenarios are hit, structured results must be produced, or it must be clearly stated that they have not yet been completed.
Must not ignore the security constraints of high-risk back-office actions, such as secondary confirmation, reason entry, dual review, revocation/compensation, audit trails, and notification strategies.
Must not, in import/export or asynchronous task scenarios, omit pre-validation, partial success, failure details, progress feedback, receipt download, idempotency, and retry.
Must not, in platform/integration back-office scenarios, only write pages without writing data contracts, callbacks, synchronization methods, failure recovery, and consistency strategies.
Must not let obvious anti-patterns pass, such as cramming complex processes into drawers, approvals with no responsible node, dashboards with no definitions, imports with no receipts, or configurations with no version rollback; when hit, they must be proactively pointed out.
Must not ignore local high-signal knowledge sources that can significantly reduce questionDebt ; if relevant documents, modules, interfaces, types, or mocks exist in the current repository, they must first be used or it must be clearly explained why they are skipped.
Must not write repository evidence as user confirmation; naming, implementations, and rules in the repository can only serve as candidate context, conflict signals, or reuse clues.
Must not be anchored by existing implementations and directly close the scope; if existing page patterns, field structures, or module boundaries in the repository may conflict with the user's goals, confirmation questions such as "reuse the status quo / open new capabilities / refactor and merge" must be explicitly raised.

Reference

references/confirmation-model.md: Examples of confirmation depth, issue debt, confirmation completeness, and option quality
references/output-templates.md: Output tables, traceability matrix, global context, page prompts, and final checklist
references/product-prd-template.md、references/delivery-modes.md: Formal PRD structure, collaborative document/Markdown protocol, and delivery mode rules
references/hiui-handoff-template.md、references/project-context-loading.md、references/forward-test-examples.md: HiUI handoff, project context preloading, and minimal forward verification sample

About this skill

Version Information

Overview

Role Positioning

Core Behaviors

Requirement Type Routing

B2B Expert Judgment

1. Business Value and Priority Judgment

2. Solution Trade-offs and Structural Decisions

3. Multi-tenant / Version / Activation Model

4. Master Data and System Boundary Judgment

5. Anti-pattern identification and risk alerts

Workflow

0. Choose the delivery mode

0.5 Project Context Preloading

1. Requirement Intake

2. Main flow and question ladder

2.1 Unified main flow

2.2 The role of the question ladder

2.5 Option-based reverse confirmation

2.55 Round linkage rules

2.6 Downstream generation input confirmation

2.7 Question Debt and Confirmation Completeness

2.8 Preventing premature closure

3. Main process execution mapping

Traceability model

B2B expert artifacts

High-frequency industry playbooks

PB01 Ticket / Approval / SLA Playbook

PB02 Settlement / Reconciliation / Invoice Playbook

PB03 Account / Organization / Permission Playbook

PB04 Configuration Center / Release / Rollback Playbook

Playbook usage rules

B-end enhancement deliverables

B-end enhancement deliverable templates

AX01 Permission Matrix Template

AX02 State Transition Table Template

AX03 Field Dictionary Template

AX04 Exception and Audit Matrix Template

AX05 Batch / Import-Export / Asynchronous Task Specification Template

AX06 Legacy System Transformation and Release Strategy Template

Backend Coverage Matrix Template

Generate product solution

Generate product PRD

Readiness check

Generate page list

Generate global context

Generate page-level prompts

Generate HiUI handoff package

Interaction mode

When the user wants to continue refining

When the user wants immediate output

When the user already has a PRD, notes, or external materials

Artifact strategy

Quality gate

Validation

Guardrails

Reference