boardgame-ui-imagegen

name	boardgame-ui-imagegen
description	BoardGame 桌游 UI 概念图/imagegen prompt 前置流程。用于新游戏 UI、生图返工、规则书/主棋盘素材设计；先拆真实 UI 元素。

Boardgame UI Imagegen

这个 skill 用来把“规则 + 素材”转成可靠的 UI 生图 brief。目标不是让图更花，而是少做少错：先证明理解了游戏和素材，再调用 imagegen。默认不是“一次出完所有图”，而是先过结构，再过布局收敛，再过分界面；风格默认只收成一版，且必须和素材统一，除非用户明确要求才额外做风格分叉。

使用顺序

1. 先读当前项目规范：AGENTS.md、docs/ai-rules/ui-ux.md、docs/ai-rules/asset-pipeline.md。
2. 若是新增游戏，先读 .codex/skill/create-new-game/SKILL.md。新增游戏默认必须继承上游 workflow：feat/game-<gameId> + 独立 worktree；当任务已进入具体布局、单一风格收敛、玩家关注点排序、proposal/spec/design/tasks 拆分时，必须同步进入 OpenSpec，而不是只把这里当作一份孤立的生图 prompt skill。
3. 读取规则真相源：优先 src/games/<gameId>/rule/*.md，没有 Markdown 才回到 PDF/OCR 流程。
4. 打开主地图、主棋盘或玩家面板素材；如果用户给的是本地图片路径，必须看图。大图先降采样或裁局部，再用 view_image 看，避免直接打开超大原图。
5. 先输出 UI 元素拆解，再生成 prompt；没有拆解，不要直接生图。
6. 如果用户明确要“生成图 / image2 / UI 指导图”，交付物仍然是 imagegen 概念图；真实素材 mockup/screenshot 只能作为辅助校验和 prompt 参考，不能替代生成图。
7. 如果用户要求保留/使用真实地图或棋盘素材，prompt 必须把“完整地图素材作为结构参考”写清楚；必要时先做 HTML/CSS/React 静态 mockup 辅助定位，但最终仍按用户要求输出生成图。

生图交付物类型门禁（强制）

• 这个 skill 的正式交付物默认必须是生图生成的位图设计稿，不是手工拼贴稿、不是线框稿、不是资产切片排版图、也不是“看起来像 UI 排版图”的半成品。
• 允许存在内部辅助 mockup，但它只能服务：
  • 校准 prompt；
  • 核对空间比例；
  • 审查素材是否缺失。
• 内部辅助 mockup 不得直接交付给用户充当 Step 1 / Step 2 / Step 3 / Step 4 设计稿。
• 如果你准备交付的图明显具有以下任一特征，默认判为跑偏，必须停下并改回 imagegen 生图路线：
  • 大量重复的圆角大面板、外框、内框、细线框；
  • 明显的素材切片拼盘、卡面拼贴、占位框、标签块；
  • 过强的“仪表盘 / 后台面板 / 线框图 / 拼贴稿”观感；
  • 画面主要质感来自框体，而不是来自桌面材质、卡牌层次、房间图面、光影与氛围。
• 自检口径：
  • 用户要的是“生图设计稿”时，必须反问自己这张图是不是像真实游戏设计稿/概念图，而不是像“给前端看的手工布局草图”；
  • 如果更像后者，就算结构没错，也不得交付。

桌游牌桌生图的少框体门禁（强制）

• 默认视觉方向是 2D 印刷桌游设计稿，不是 3D 实体渲染图。
• 这里说的“更像桌游”默认指：
  • 更像印刷版面、卡面、板块、牌背、标记与平面插画系统的统一；
  • 更少软件后台面板感；
  • 允许少量体积感，但不能靠 3D 建模、真实摄影光影、重材质渲染来成立。
• 对桌游运行时主界面的生图稿，默认优先级必须是：
  1. 印刷棋盘 / 房间板块 / 卡牌 / 角色板等平面桌游对象
  2. 少量必要的层级与投影
  3. 少量必要数字增强与状态高亮
  4. 最后才是容器、边框、按钮底板
• 默认不允许把每一组信息都装进独立大面板。像：
  • 当前玩家区
  • 队友区
  • 牌堆区
  • 帮助区
  • 动作区 这些信息默认应先尝试作为“同一张印刷桌游画面里的对象组合”存在，而不是各自再套一层厚容器。
• 允许存在边框，但边框优先来自卡框、印刷描边、板块边线和素材自带装饰；不要默认升级成厚木边、金属雕花、机械机关件。
• 如果看图后一眼感受更像“深色后台面板 + 多个功能框”，而不是“鬼屋桌游牌桌”，默认判失败。
• 如果看图后一眼更像“3D 渲染宣传图 / 实物拍摄风概念图”，而不是“可前端复刻的 2D 运行时设计稿”，也默认判失败。

默认四步走（强制）

• 没有明显说明时，默认按四步走，且通过前一步才进入下一步：
  1. 规则提炼 UI：先从规则和素材里提炼必要元素、主次关系和基础布局；默认优先生成运行时主界面的结构稿。
  2. 布局收敛 UI：当 Step 1 的必要元素和大致布局已成立后，默认直接收敛到 1 张 可继续执行的布局定稿；只有用户明确要求对比时，才额外做多版布局。
  3. 风格统一 UI：在已选定的布局上收成唯一风格，默认只检查是否和素材统一，不再默认做风格裂变。
  4. 分界面 UI：在已选风格下，再生成角色选择、运行时、结算等不同界面。
• 如果用户没有特别指定“先看哪一屏”，第一步默认先做运行时主界面，因为它最容易暴露必要元素和空间关系是否正确。
• design-system/games/<gameId>.md 是复刻约束，不是这四步的替代品；单张“壳层图”“资料页图”“资源目录图”不算完成其中任一步。
• 用户若明确要求只做某一步，才允许跳过其余步骤；否则一律按完整四步交付。

Step 2 布局收敛的额外硬约束

• 默认只产出 1 张 布局定稿，不再强制做 3 张裂变。
• 如果用户明确要求“比较布局”“给我几版布局看看”“同题多解”，才允许临时切回多张布局对比；否则直接沿当前已选方向继续。
• 布局必须优先照顾实际可玩性：
  • 先估算这张图里最多要容纳多少物品、手牌、状态 chip、目标卡和动作入口；
  • 如果规则没有写明固定上限，不得按“通常只会有 2-3 张”偷懒布局；必须先根据规则动作、牌池规模、补充来源、可持有机制与回合节奏，写出一个可辩护的峰值估算，再决定是否需要溢出机制；
  • 如果这些对象会把主视区挤爆，先重排布局，不要先生成再补救；
  • 如果规则动作没有对应入口，先补入口再出图。
• 布局定稿至少要明确这 3 件事：
  • 玩家先看哪里；
  • 当前可点击的对象集中在哪；
  • 结束当前动作或回合的入口放在哪里。
• 如果用户已经点名某个继续母版，后续默认先把它当成视觉基线，不是规则真相源：
  • 默认优先保留它的主构图、主次关系与大区块关系；
  • 但只要规则审计证明这版母版本身缺少必要入口、必要承载量或必要对象关系，必须先指出母版失效点，再允许改它；
  • 不得把“继续沿用某版”理解成“规则可以让位给母版”。
• 布局仍然必须优先复用素材语法：
  • 尽量复用原本素材中的图形、槽位、牌框、印刷行动指示器、徽记、角标、属性标识、几何轮廓；
  • 即使你已经知道某个原素材不完全适合表达动态等级、技能层级或数值状态，布局阶段仍然优先保留它的形状语言，再考虑后续如何数字增强；
  • 例如素材里属性更像五角星/徽章，就先按五角星/徽章的视觉语言做，而不是擅自替换成一套更“通用”的圆点、进度条或仪表盘。
• 如果用户已经点名某个版本名，例如 betrayal-runtime-prehaunt-board-v4，后续默认沿用该版继续收敛，不再默认重开布局裂变。

设计批准前的实现禁令（强制）

• 只要当前仍处于 Step 1 / Step 2 / Step 3 任一步的位图设计阶段，默认不得：
  • 启动 dev server、联机房间、本地运行页去做“真页验真”；
  • 编写或继续扩展 Board.tsx、运行时 HUD、动作条、PromptOverlay、页面骨架等前端实现；
  • 用 HTML/React 静态页、真实运行页截图或可玩页面，冒充“设计稿已经出了”。
• 正确顺序必须是：
  1. 先出位图设计稿；
  2. 用户明确同意该步设计稿；
  3. 再进入下一步设计，或回到 create-new-game 继续骨架/实现前门禁；
  4. 只有在设计稿与骨架都过门禁后，才允许进入前端实现与真页验证。
• 批准语义：
  • 用户说“继续”不等于批准当前设计步；
  • 只有用户明确认可该步布局/风格/分界面稿，才可进入下一步；
  • 未获批时，只能继续改 prompt、重生图片、补拆解与审计，不能切去实现线。

实现导向生图的可复刻门禁（强制）

• 当这张生图的后续目标是“据此做前端实现”时，必须先把画面元素分成三类，再允许继续：
  • 前端刚性结构：前端需要高保真复刻的位置、主次、尺寸关系、交互入口和对象分组。
  • 可替换氛围材质：允许在实现时降级或替换的木纹、铜锈、纸张颗粒、蜡烛、景深、照片级纹理、桌面小道具。
  • 纯概念点缀：只服务气质，不应承担信息表达职责的装饰物。
• 默认必须能明确说出这张图里哪些属于前端刚性结构。对桌游运行时主界面，通常至少包括：
  • 房间板块主视区的构图和连接关系；
  • 当前探索者板、队友摘要、牌堆组、持有区、动作条的相对位置；
  • 焦点房间、当前动作、可交互入口的高亮方式；
  • 主要对象的轻重层级。
• 出图前必须先过“友好性自审”：
  • 我最多会有几个物品 / 手牌 / 目标 / 状态同时存在，画面是否还能正常落位；
  • 玩家这一轮能做的事情是否都有明确入口，不能只靠看说明猜；
  • 如果队友、同房间对象、可交易对象会影响这一轮决策，是否有最小可读入口，而不是只剩几个没语义的头像；
  • 常驻文字是否只在承担对象名、数值、短状态和按钮标签，没把规则说明塞进主界面；
  • 这个布局是不是能让第一次接触的人先找到可点对象，再理解规则，而不是先看懂术语。
• 主 UI 的描述性正文默认禁止：
  • 主界面里只允许 对象名、数值、短状态、按钮标签 这四类常驻文字；
  • 不允许把“按钮是干什么的”“现在为什么该点它”“点击后会发生什么”写成常驻说明句；
  • 如果确实需要解释按钮功能，只能做成 tooltip / 小问号 tip / 帮助入口展开层 / 临时说明浮层，不能直接写在按钮下方或主界面正文里。
• 对“以既有稿继续收敛”的任务，还要额外过一条 母版对比门禁：
  • 新稿的主棋盘权重不能低于母版；
  • 新稿的常驻区块数量不能多于母版；
  • 新稿若需要用户先适应一套新分区关系，默认判失败；
  • 如果它不比母版更克制、更稳定或更可实施，就不应继续保留。
• 默认不得把以下内容当成“前端必须按图复刻”的正式合同：
  • 蜡烛火焰、体积光、景深、摄影级阴影；
  • 雕花浮雕、木雕裂纹、金属旧化细节、随机污渍；
  • 依赖生成纹理才成立的房间内部细节、墙纸花纹或桌面噪点；
  • 仅靠细腻材质差异才看得出的状态变化。
• 对当前默认路线，还应额外避免把这些当成主视觉支撑：
  • 厚木边、古铜机关、立体铭牌、桌边机械件；
  • 强烈俯拍摄影感、实物模型感、3D 板块厚度表演；
  • 靠真实烛光与实体道具撑起来的“高端概念图”气质。
• 如果某个关键信息只有在高阶材质或复杂光效存在时才看得清，默认判为不可直接实施的设计稿；必须把该信息改成前端可稳定复刻的表达，例如明确边框、徽记、色块、令牌、卡槽、按钮态或固定高亮。
• 默认承诺口径：
  • “可复刻”指前端能高保真复刻构图、层级、尺寸关系、交互入口和对象语法；
  • 不承诺逐像素复刻 AI 生成的随机纹理、雕花、摄影光影或不可控笔触。
• 默认 prompt 口径：
  • 优先写 2D printed board game UI concept、flat illustrated board tiles、printed card language、implementable runtime layout；
  • 避免默认写 realistic tabletop materials、carved wood、antique brass、candlelight cinematic、premium 3D render 这类会把结果推向实体渲染的词。
• 如果任务是“在某张图上继续优化”，prompt 必须直接写明：
  • preserve the approved macro layout unless rule audit proves it insufficient；
  • do not add new permanent regions unless rules require them；
  • prefer solving within existing slots or by lightweight regrouping；
  • fail if the result feels busier or more segmented without rule justification。
• 向用户汇报实现导向设计稿时，默认要同时说两句话：
  • 哪些部分是后续前端必须守住的结构合同；
  • 哪些部分只是概念气质参考，实现时允许降级。

新游戏分支与工作树口径

• 新增/添加游戏时，分支与工作树要求以 .codex/skill/create-new-game/SKILL.md 为准：默认应在 feat/game-<gameId> 分支 + 独立 worktree 上推进。
• 对“新增游戏”任务，创建 worktree 不是可选优化，而是默认执行现场；只有用户明确说“不要新开工作树”时才允许留在当前工作区。
• 本 skill 只负责 UI 生图 brief；如果它在新游戏 workflow 中被触发，应继承上游 create-new-game 的 worktree 口径，而不是退回根 AGENTS.md 的通用默认值。
• 一旦上游已经为该新游戏选定 worktree，本 skill 后续的读图、写 prompt、写 evidence、落静态稿、截图与验证，都必须继续使用同一个 worktree；不得因为这里只做 UI 草稿，就回到主工作区继续推进。

新游戏 UI 生图与 OpenSpec 收口门禁

• 本 skill 不替代 OpenSpec：当用户只是要看一个方向稿，这里可以先做规则理解、UI 拆解和 prompt；但只要用户开始要求“按这个方向做新游戏”“收敛成单一风格”“确定布局不变量”“拆 implementation task”，就必须把结论写入该游戏的 OpenSpec change。
• 流程完整度口径继承上游 create-new-game：
  • 用户说“走流程”时，这里默认要做的是把 UI 方向对应的主文档补齐，不是退回“先最小提案”；
  • 如果当前 UI 方向已经实质影响 foundation 之外的边界，必须同步审计并补对应 change，不能只把图继续挂在最早那条 change 下面；
  • “最小”只可用于局部 prompt 收紧、局部控件删减，不可用于弱化 proposal / design / spec / tasks 的完整度。
• 默认动作：
  1. 先按本 skill 完成规则理解、素材拆解、玩家关注点排序与禁止项清单；
  2. 若新游戏已进入具体方案阶段，把这些结论写进 proposal/design/spec/evidence，并先核对当前 UI 结论属于哪条或哪几条 change；
  3. 再继续 imagegen / SVG / 静态稿迭代。
• 禁止行为：
  • 禁止把“生了一张图”当成方案已经走完流程；
  • 禁止在没有 proposal/design 边界的情况下，反复生成多个方向并把它们都算当前有效方案；
  • 禁止继续使用“最小提案”这类表述弱化当前具体方案应有的流程完整度。
  • 禁止用“先出一张图再补流程”当默认顺序；若当前图已经承载正式布局不变量，就要先补回 OpenSpec 主文档。
  • 禁止只更新 design-system 或 evidence，却不把已经确定的布局不变量、禁止项和主次关系同步写回 proposal / design / spec / tasks。
  • 禁止把“方向稿已经收敛”为由，继续沿用旧 change 的边界不升级；如果 UI 方向已经推动到 gameplay、scoring 或 runtime-entry 边界变化，必须回到上游 create-new-game workflow 补下一条 change。

生成方式裁决

• UI 指导图：用户要生成图时，目标是指导后续 UI 实现，不是最终可运行截图。可以视觉概念化，但必须守规则结构、素材构图和去重约束。
• 辅助保真 mockup：当需要核对空间关系时，可以先用真实素材做 HTML/CSS/React 静态 mockup 或截图；它只用于校准 prompt，不作为生成图交付替代品。
• 禁止把 mockup 做成正式稿：即使 mockup 已经能表达布局，也不得把它继续美化成“多层边框 + 深色面板 + 素材拼贴”的伪正式稿直接交付；这类图要么留在内部，要么废弃，不能顶替 imagegen 设计稿。
• 失败处理：如果 imagegen 连续生成重复 HUD、拆图、重绘流程轨或遮挡素材，应先收紧 prompt 和规范；不要直接把截图当成“已完成生图”。

看图与降采样规则

• 必须看主素材和生成图；不能只凭 prompt 自评。
• 不要直接打开超大图片。满足任一条件时先降采样或裁图：最长边超过 1800px、文件超过 2MB、或包含大量细字/密集 UI。
• 原图必须保留。降采样、裁图、标注图只放 temp/<gameId>-ui-imagegen-review/，不得覆盖 $CODEX_HOME/generated_images/** 或正式素材。
• 优先产出两类核对图：
  • 总览图：最长边约 1400-1600px，用于判断整体构图、轻重、遮挡。
  • 局部图：按关键区域裁切，例如手牌/焦点卡、底部轨、右侧牌槽、主行动指示器、当前目标浮层。
• 只要总览看不清某个判断点，就必须补局部图；不能用“看不清”当作通过。
• 可以用标准工具生成核对图，例如 PowerShell + Python/Pillow；若 Pillow 不可用，用系统现有图片工具或浏览器截图降采样。不要为了看图引入新运行时依赖到项目。

示例原则：

source image -> temp/<gameId>-ui-imagegen-review/overview-1600.png
source image -> temp/<gameId>-ui-imagegen-review/crop-hand.png
source image -> temp/<gameId>-ui-imagegen-review/crop-bottom-tracks.png
source image -> temp/<gameId>-ui-imagegen-review/crop-action-indicator.png

UI 元素拆解门禁

生图前必须给出这四类清单：

• 素材已有 UI：主图上已经印出来的行动指示器、牌库槽、弃牌槽、流程轨道、计分轨、卡位、提示框、区域名、边界、图例等。已有 UI 只能数字化增强，不能复制一套。素材本身就是 UI 元素的一部分，不得当纯背景。
• 规则必须常驻：玩家每回合必须反复查看或操作的对象，例如手牌、当前选中卡牌、当前可执行动作、当前选中目标。
• 参考卡必须转成交互：像 Player reference、Traitor reference、Monster reference、回合顺序卡、步骤卡这类“告诉你怎么做”的卡，默认只作为规则来源，不应在运行界面中整张展开；它们必须优先被提炼成按钮、短状态、动作条、步骤 chip 或可折叠帮助入口。
• 按需展开：日志、详情、帮助、完整手牌、规则摘要、弃牌堆查看、战斗结算详情。默认不占整列。
• 禁止出现：规则没有的系统、解释性 UI、工具/编辑器入口、重复控件、独立拆出来的地图区域。

拆解必须直接引用规则原文中的结构，不要用泛化策略游戏经验补空白。

补充约束：

• Step 1 的目标是确认“必要元素和基础布局”，不是提前做风格炫技；这一步如果已经把元素放错、主次做反，后续全部作废。
• Step 2 的目标是把当前游戏收成一个真正能用的布局，不是默认做裂变；只有用户明确要求时才进入多版布局对比。
• Step 2 默认要先回答“最大承载量放不放得下”“玩家可做动作有没有入口”“玩家先看哪里”这三个问题，再去生成。
• Step 3 必须复用 Step 2 已选中的布局，并收成与素材统一的唯一风格；不得借“换风格”偷偷改主结构。
• Step 4 必须继承 Step 3 选定风格，不得每个界面各换一套视觉语言。
• 对卡牌驱动游戏，Step 1 默认必须包含“当前持有区 / 当前决策入口 / 回合推进入口”这类运行时交互骨架；具体是不是按钮、牌位、行动指示器入口、棋盘直点，以规则和素材为准；如果把参考卡画出来却没有可执行入口，那不是 Step 1 合格稿。

生成图元素审计门禁

看图后必须列出生成图里每一个主要数字 UI 元素，并给出来源归属：

• 规则动作：规则明确要求玩家选择/执行/确认的对象，例如 手牌行动、势力行动、选择目标、打出卡牌。
• 当前决策：玩家当前必须看懂才能行动的对象，例如手牌、焦点卡、可选区域、当前目标、可用命令。
• 素材已有职责：地图/棋盘已经印出的行动指示器、牌库槽、弃牌槽、流程轨、计分轨、卡位、提示框等。
• 实现必要状态：年份、当前玩家/势力、阶段、选择模式等运行时必要但不应变重的状态。

判定规则：

• 找不到上述任一归属的 UI 元素，默认判为不应存在，下一轮 prompt 必须删除。
• 属于“素材已有职责”的元素，不应另做同名独立 HUD；最多做轻量状态增强。
• 属于“当前决策”的元素不能过小，尤其卡牌驱动游戏的手牌/焦点卡必须可读。
• 卡牌驱动游戏里，如果规则来源卡明确描述了可执行动作，必须把这些动作转成界面上的明确按钮或动作条；不能把规则卡替代成大图说明。
• 卡牌驱动的桌面对局默认不需要“游戏标题大栏”。如果壳层已有游戏名、连接态或房间状态，生成图与静态稿里不得再复制一整条 标题 + 已连接 + 当前玩家 板头。
• 计分若主要服务终局或复盘，默认只保留紧凑摘要，不得在常规对局态生成巨型记分纸、整列总结卡或中央成绩单。
• 若规则里存在固定上限的公共牌列，例如幻想国度公共区最多 7 张，图上必须按完整上限一次性展开，不得用“部分露出 + 还有更多”的泛化牌桌模板。
• 生成图里如果出现流程提示、日志、规则摘要、第二套主行动指示器/牌库/战斗轨、编辑器工具栏，即使画面好看也判失败。
• 审计结论要写“保留 / 删除 / 降级 / 放大 / 移位”，不能只写“好看/正常”。

素材优先规则

• 主地图/主棋盘是构图真相源。若它是一张完整桌面版图，prompt 必须说“整图作为一个画布使用”，不得拆成多个独立面板。
• 如果素材上已有某个控件，就不要在别处再做一个同类控件。例如素材上已有主行动指示器，就不要再在底部做第二个同名解释器。
• 如果素材上已有某个区域的牌库/弃牌槽，就只在原槽位贴短标签或状态，不把它们移到右侧栏。
• 如果素材上已有战斗流程轨、计分轨、年份/回合卡位、检查流程框，默认保留原位置，不用新 HUD 重做。
• 地图上的区域、点线、城池、山河、边界、锚点是地图内容，不应被 HUD 盖掉。
• 素材里已经存在且不会变化的固定内容，不需要在 UI 指导图里再强调、标注或解释。真正需要设计的是玩家要操作、选择、检查、确认的动态部分。

控件所有权规则

• 同一信息只能有一个主出处。地图上已经印出来的，就不要再做一份独立数字版。
• 如果素材上的主行动指示器已经表达当前行动，就不要在底部再做第二个同义控制器或解释器。
• 如果规则要求的是“一个主动作槽 + 一个当前状态”，不要把状态另做一个同名面板。
• 只有当素材本体没有表达该信息时，数字覆盖层才可以补它。
• 如果素材已有清晰文字标签，数字覆盖层不要再贴同名标签；避免“为了确认而重复 UI”。
• 默认优先级：board printed control > one action slot > small state badge > optional detail。

轻重判定规则

• UI 轻重按“玩家是否需要用它做决策”排序，不按视觉面积平均分配。
• 卡牌驱动游戏里，手牌、当前选中卡牌、卡牌代价/类型/效果摘要通常比年份、阶段、流程提示更重要。
• 固定不变的版图文字、流程轨、牌库槽、地图区域属于背景信息；即使它们规则重要，也不应抢当前操作 UI 的层级。
• 当前可行动作和当前选中目标次于卡牌，但高于年份/玩家名/流程状态。
• 年份、当前势力、阶段状态只做轻量状态 chip，不做大标题或流程条。
• 布局里的“左区 / 右区 / 底区 / 摘要区”默认只是阅读责任区，不自动等于独立面板。除非素材本身就有明确框体或目标就是仪表盘，否则不要把每个区都做成一块带边框底板。

空间占用规则

• 地图/棋盘类主图优先保留可读面积。覆盖层宁可少，不可压住素材已有流程轨、牌槽、计分轨和关键区域名。
• 行动记录、规则摘要、完整日志默认禁止出现在主界面；只有用户明确要求常驻日志时，才允许做极小入口或临时浮层。
• 手牌区必须足够清楚。不要铺满整屏，但不能把卡牌缩成无意义小点；至少要让玩家能区分当前持有的对象，以及当前决策真正依赖的是哪几张/哪几个对象。
• 交互区应优先借现有空白区、贴边区或素材语法自然落位，不默认横跨全宽；若底部存在关键流程轨或印刷信息，必须先让位给原图可读性。
• 结束回合是普通命令，不应做成比地图对象更重的巨型面板。
• 如果一个覆盖层会让地图已有 UI 不可读，删除覆盖层，而不是移动地图。
• 首版 UI 草稿默认不展示完整卡面墙；除非用户明确要求检查手牌布局，否则手牌只显示折叠入口、数量、少量小缩略 chip。
• 若游戏核心是卡牌驱动，应在不遮挡主图关键轨道的前提下保证手牌或持有物可读；展示数量、排列方式与是否需要焦点预览，必须由规则上限、当前决策密度和素材空间共同决定，不得按固定张数模板套用。
• 素材上已有战斗流程轨时，禁止把它重绘成数字面板；只能保留原图或加极小阶段标记。
• 底部操作区不得为了“看起来完整”而吃掉原图下沿关键轨道；具体宽度、排布和是否需要滚动，必须由规则动作数量、素材空白区和当前决策密度共同决定。
• 若同一张图主要靠“整张牌桌 / 整张地图 / 整张书页”成立，辅助信息默认做成贴边、贴角、贴对象的轻量区，而不是左一盒、右一盒、下一盒的分舱式布局。

规则理解规则

• 先找“回合主动作模型”。不要把子选项误升为主按钮。
• 如果规则写“执行 A 及 B，顺序自定”，UI 应表达两个动作槽，而不是把 A 的子项和 B 并列。
• 卡牌子类型、势力行动、战斗步骤、维护步骤等，只有在当前动作展开时显示。
• 不确定某 UI 是否常驻时，默认降级为按需展开。
• 不要在 UI 里解释规则。按钮叫“结束回合”即可，不写“结束当前玩家回合并进入下一玩家”。
• 如果某元素已经在素材里承担“状态显示”，覆盖层不要再重复显示同一状态。
• 不要在 UI 指导图里显示流程说明或流程箭头。素材中的流程轨保留即可，动态 UI 只显示当前状态或当前操作。
• 如果要解释按钮功能，默认只留 hover tip 或帮助入口，不在主 UI 常驻解释句。

Prompt 结构

生成 prompt 时按以下顺序写：

1. 当前步骤：先写明这是 Step 1 结构稿、Step 2 布局定稿、Step 3 风格统一稿，还是 Step 4 分界面稿。
2. 画布原则：主素材是否完整使用、是否允许裁剪、是否允许拆分。
3. 必须保留的素材 UI 位置：逐条列出已有控件的位置和处理方式。
4. 友好性前提：先写清最大承载量、关键动作入口、玩家视线顺序是否已经成立；没成立就不要进入生图。
5. 最小数字覆盖层：只写新增覆盖层，不写大段功能说明。
6. 主动作模型：用规则术语描述，不发明 AP、任务、建造队列等系统。
7. 风格口径：默认只允许与素材统一的单一风格；除非用户明确要求，否则不写多种风格方向。
8. 禁止项：把本轮踩过的坑明确写进 negative constraints。
9. 可见文字限制：只允许短标签、动作名、数字和状态；禁止解释句。
10. 复刻边界：点明本轮图里的前端刚性结构与可降级氛围材质，避免 prompt 把不可控细节写成正式合同。

生成后自检

每次生成后必须看图并逐项核对，不能只交付生成结果。

• 看 $CODEX_HOME/generated_images/** 下的生成图时，先按“看图与降采样规则”生成总览/局部核对图；不要直接打开超大原图。
• 可以用 view_image 查看降采样图和局部裁图。
• 不要用 HTML/CSS mockup 截图替代用户要的 UI 指导生成图。
• 不合格时必须更新 prompt 或规范后重生；继续迭代直到达到本轮验收标准，或明确记录阻塞原因。

自检清单：

• 是否出现重复控件：第二个主行动指示器、第二个牌库/弃牌、第二个年份或回合卡位、第二个当前行动。
• 是否所有主要数字 UI 元素都能对应规则动作、当前决策、素材已有职责或实现必要状态；没有对应就删除。
• 如果去掉蜡烛、雕花、旧化纹理、景深和摄影级阴影，这张图的主结构是否仍然成立；如果不成立，说明它还不是可实施设计稿。
• 若当前是 Step 1：是否已经能看出必要元素和基础布局是否成立；如果还在靠“风格挺像”掩盖布局问题，判失败。
• 若当前是 Step 2：是否真的给出了当前能直接执行的唯一布局定稿；如果还在为了“多一版更好看”反复裂变，判失败。
• 若当前是 Step 2：这版布局是否能回答“最多几个物品也放得下”“动作入口在哪”“玩家先看哪”；答不上来，判失败。
• 若当前是“基于已选母版继续”，新稿是否仍然保持相同主构图与区块数量；如果靠新增面板/新增分栏/新增焦点区来解决问题，判失败。
• 若当前主 UI 出现“Move to... / Draw a... / Trade with...”这类按钮功能说明句，默认判失败；按钮只保留标签，解释退到 tooltip、帮助入口或临时说明层。
• 若当前是 Step 3：是否严格复用 Step 2 已选布局，只收成与素材统一的单一风格；若结构也跟着变，判失败。
• 若当前是 Step 4：是否严格继承 Step 3 已选风格；若角色选择、运行时、结算像三套产品，判失败。
• 是否轻重失衡：HUD 是否比地图更抢眼，底部/右侧是否变成仪表盘。
• 是否遮挡素材：流程轨、牌槽、区域名、特殊区域、年份/回合卡位是否还可见。
• 是否出现“大块底部 HUD”：完整手牌墙、巨大动作菜单、巨大结束按钮、重绘战斗流程面板。
• 是否出现解释性 UI 文案。
• 是否出现流程提示/流程说明条，尤其是素材中已经有流程轨时。
• 卡牌是否过小，是否无法看出这是卡牌驱动游戏的主要决策区。
• 是否出现用户已要求移除的元素，例如整列日志或行动记录大面板。
• 若任一项不合格，必须更新 prompt 或规范后重生，不得把图当成合格草稿。

文案限制

UI 里允许：

• 对象名：手牌、牌库、弃牌、回合标记
• 动作名：打出卡牌、选择当前行动、结束回合
• 状态：已执行、未执行、当前
• 数字和短字段：年份、VP、人口、部队、顺位

UI 里禁止：

• 规则说明句
• 教程句
• “点击这里...”类指令
• 解释按钮含义的文字
• 不属于规则的资源栏和系统名

单游戏私有规则下沉（强制）

• 通用 skill 不得直接写某个游戏的专有机制名、专有地名、专有势力名或专有控件名。
• 即使只是举例，也不得拿单游戏机制名充当通用示例；示例必须抽象成职责，例如“共享行动指示器”“年份或回合卡位”“特殊区域”。
• 像“某个游戏独有的主交互构件”“某个游戏专属势力”“某个游戏专属地区/关隘”这类只属于单游戏的约束，只能写进 docs/games/<gameId>/workflows/、该游戏自己的 skill，或该游戏的 design-system 文档。
• 如果当前任务明显依赖某个游戏的主板结构特例，先保留这份通用 skill 的共性约束，再去读取该游戏的专项文档；不要把专项提醒反写回通用 skill。