openprd-ui-context

name	openprd-ui-context
description	OpenPrd UI Context skill：区分 greenfield、brownfield 与局部修正，基于已确认 PRD、可选 CodeGraph 和本地证据提出专业 UI/UX 方向，并在用户确认后编译 PRODUCT.md、DESIGN.md 和 Impeccable handoff。

OpenPrd UI Context

这份 skill 是项目理解与 Impeccable 之间的专业设计层，不是 CodeGraph 翻译器，也不是固定风格数据库。

触发边界

• 新建界面、核心页面、视觉系统、信息架构或关键用户流程：运行完整流程。
• 存量项目的结构性 UI 改造：运行完整流程，并优先消费代码事实。
• 卡片间距、颜色、字号、局部对齐等低风险修正：使用 local-fix，复用已有冻结上下文。
• 纯后端、纯脚本、纯数据和无用户可见输出：跳过本 skill。

核心原则

1. CodeGraph 只在 brownfield 中作为可选代码事实输入；不可用时回退本地扫描并标记 evidence-gap。
2. greenfield 从已确认 PRD/review 生成 planned UI topology；永远不要称它为 CodeGraph 或现有代码事实。
3. 先做产品设计、UX 架构与审美判断，再请用户确认少量高价值变量。
4. 三个方向必须在生成逻辑、信息组织、密度、素材策略、交互哲学或视觉气质上真正不同。
5. 未记录 user-confirmed 方向前，不冻结 PRODUCT.md/DESIGN.md，也不进入 Impeccable 实现。
6. 不静默覆盖已有合同；发现冲突时保留原文件并请求 preserve / merge / refresh 决策。

工作流

1. 建立证据底座

运行：

openprd ui-context . --mode auto --json

读取 .openprd/design/ui-context/context.json。按模式继续：

• greenfield：读取 greenfield.md，从已冻结 PRD/review 编译计划页面、入口、流程、状态、复用组件和数据角色。
• brownfield：读取 brownfield.md，查询可用 CodeGraph，并补路由、组件、CSS/tokens、状态、资产和 blast radius 扫描。
• local-fix：复用已有 PRODUCT.md、DESIGN.md 和 active design artifacts，不重开完整方向评审。

每条关键结论都保留：source、confidence、conflicts、open questions。事实优先级与冲突处理见 evidence-policy.md。

2. 做专业设计判断

结合 $openprd-frontend-design、项目事实、用户目标、受众、可访问性与技术约束，先形成一条设计 brief：

• 用途与关键任务
• 目标用户与使用环境
• 气质端点与品牌强度
• 信息密度与响应式约束
• 素材策略与真实性要求
• 用户第一眼应记住的东西

再生成三个异源方向。每个方向必须说明：

• 生成逻辑：contrast / reference-transfer / design-lens
• 产品与 UX 主张
• 页面骨架、密度、视觉层级和状态策略
• 色彩、字体、表面、图标、图片与动效角色
• 记忆点、适用场景、主要风险和主动避开的模板味

不要把专业判断全部甩给用户；先给带理由的推荐。

3. 只确认高价值决策

向用户展示三个方向和推荐，按实际缺口确认：

• 方向
• 明暗偏好
• 信息密度
• 品牌表达强度
• 动效强度
• 参考图或参考站点的约束地位

用户确认后运行：

openprd ui-context . --direction <1|2|3> --source user-confirmed --json

如果已有 PRODUCT.md/DESIGN.md 冲突，先完成 preserve/merge/refresh 决策，并在记录方向时显式加 --contract-decision <preserve|merge|refresh>；不得用 --force 绕过。preserve 会保持阻断，merge / refresh 只表示用户批准 Agent 继续编译，不会让 Host API 静默覆盖文件。

4. 编译冻结合同

内容编译属于本 skill 的专业判断职责：Agent 基于证据、三个方向和用户确认写出高质量合同。openprd ui-context Host API 只负责模式证据、确认绑定、lint 和 handoff 生命周期，不生成通用模板冒充设计结果。

读取 contract-templates.md 和 design-md-compatibility.md，生成：

• 项目根 PRODUCT.md
• 项目根 DESIGN.md
• 可选 .impeccable/design.json
• 同步 .openprd/design/active/facts-sheet.md
• 同步 .openprd/design/active/asset-spec.md
• 同步 .openprd/design/active/image-preflight.md
• 同步 .openprd/design/active/direction-plan.md
• 同步 .openprd/design/active/selected-direction.md

根合同必须各自包含唯一的 OPENPRD:UI-CONTEXT 标记，并明确方向、来源、确认状态和 schema target；marker 必须与 confirmation.json 一致。DESIGN.md 兼容目标固定为 Google design.md alpha，commit bde692f2bc92ef7fdd0cf277b2704ab074b70efd。

运行合同校验：

openprd ui-context . --check

校验未通过时不得 handoff。

5. 交给 Impeccable

读取 impeccable-handoff.md。明确要求 Impeccable：

• 先读冻结的 PRODUCT.md 和 DESIGN.md。
• 保持已确认产品边界、关键流程、视觉北极星和 token 角色。
• 用 shape/craft/critique/polish 完成实现与精修，不重新发明方向。
• 发现合同冲突或实现不可行时回报，不静默偏航。

实现完成后回到 OpenPrd 的 visual-compare、verification-board、alignment-board 和 centering-board 验证链路。

停止条件

• greenfield 没有已确认 PRD/review。
• 方向仍未确认。
• 已有合同冲突尚未决策。
• DESIGN.md schema lint 失败。
• CodeGraph、代码、PRD 或用户参考之间有影响产品边界的未决冲突。
• 关键颜色、字体、素材许可、可访问性或交互状态仍是推断，却被写成已确认事实。