eliteforge-poseidon-ui-design

name	eliteforge-poseidon-ui-design
description	基于 Poseidon 设计系统完成企业后台界面的前端开发、原型设计和 UI 评审。用户要求从零设计或实现界面、在现有前端项目中创建或改造页面、制作静态或可交互原型，或评审页面代码、运行界面、原型、截图及设计稿时使用；覆盖顶部导航菜单、一级页面、二级页面、弹窗、抽屉、表单、表格、图表、反馈组件及其他后台 UI。
metadata	{"version":"1.0.1"}

EliteForge Poseidon UI Design

使用 Poseidon 设计规范完成三类目标：开发或改造生产界面、从需求或设计素材创建可预览原型、对代码或视觉产物进行 UI 评审。先识别目标和输入，再选择交付形式。

执行原则

• 先判断任务属于前端开发、原型设计、UI 评审还是评审并修复，再确认可用输入和期望交付物。
• 存在目标项目时，先读取适用于目标文件的所有 AGENTS.md，再检查技术栈、目录结构和既有实现。
• 前端开发复用项目现有布局、组件库、设计令牌、图标、路由、状态管理和测试设施，不擅自切换框架、引入另一套 UI 库、添加重型依赖或改写无关页面。
• 原型设计不要求已有生产工程；遵循用户指定的工具和格式，产出范围受控、可预览且足以验证核心流程的原型。
• UI 评审默认保持只读；除非用户明确要求修复，否则不修改被评审的代码或设计产物。
• 在项目范围内发生冲突时，依次遵循用户明确要求、适用的 AGENTS.md、当前项目约定、Poseidon 文本规范和视觉样例。
• 只读取当前任务需要的参考资料和拆分图，禁止一次加载整个组件分类。

建立任务上下文

1. 确认任务模式、业务目标、页面类型、目标用户、平台和期望交付物。
2. 盘点用户提供的仓库、源文件、运行地址、需求、数据结构、截图、设计稿或现有原型。
3. 存在目标项目时，从项目根目录到目标文件目录逐级读取 AGENTS.md；更深层文件的规则覆盖上层同类规则。
4. 对前端项目检查包清单、锁文件、构建配置、脚本、入口、路由、状态管理、样式体系、UI 组件库和相邻页面。
5. 查找可复用的颜色令牌、间距、字体、布局壳、表单、表格、弹窗和抽屉实现；独立原型不存在这些基础时，再按 Poseidon 规范建立局部设计令牌。
6. 明确目标视口、内容层级、关键流程、数据与权限、正常和异常状态，以及原型所需保真度和交互深度。
7. 从项目约定或交付形式确定格式化、静态检查、测试、构建、预览和评审方法；信息足以推进时不要重复追问。

Output Path

按任务模式确定主要交付路径：

1. 始终优先使用用户为当前任务明确指定的文件或目录。
2. 前端开发使用当前项目中承载目标功能的既有路由、页面或组件；新功能使用项目结构中可唯一确定的相邻模块。
3. 原型设计优先使用项目既有的 prototype、design 或 demo 目录；不存在时写入 <workspace>/prototypes/<feature-slug>/。单文件网页原型的主文件为该目录下的 index.html。
4. UI 评审默认在对话中输出，不写工作区文件；用户要求评审文档但未指定路径时，写入 <workspace>/reviews/<feature-slug>.md。

前端代码或原型源文件是事实源；截图和导出预览是派生产物，应放在事实源同级或其子目录。不要让任何交付物依赖技能目录的绝对路径。

按需读取参考资料

先读取 设计基础，再按任务类型读取页面资料，并为实际使用的组件补充对应拆分图。一级页面、二级页面、弹窗和抽屉的 Markdown 是页面级业务规格源，设计基础只提供跨页面补充，不能用摘要替代或删减页面正文。使用可用的图像查看工具检查 PNG/SVG，不要仅凭文件名推断内容。

页面与容器资料

场景	必读资料
顶部导航菜单或应用菜单	references/顶部导航菜单.md、references/顶部导航菜单.png
一级列表或管理页面	references/一级页面.md、references/一级页面示例图.png
二级详情或配置页面	references/二级页面.md、references/二级页面示例图.png
弹窗	references/弹窗.md、references/弹窗示例图.png
抽屉	references/抽屉.md、references/抽屉示例图.png
颜色或主题	references/浅色色板.png
图标、图表、插图或光标	references/icon.png、references/图表.svg、references/插图.png、references/光标.png 中与任务相关的文件

组件视觉样例

组件规范已按主题拆分为独立 PNG。下表中的 * 只表示文件名前缀，不表示批量加载指令；先列出该前缀下的候选文件，再按文件名中的组件关键词只查看与当前任务直接相关的图片。同一任务涉及多个组件时逐张补充。

组件场景	候选资源
按钮、边框、分割线或滚动条	references/组件-全局通用-*.png
输入框、搜索、开关、单选、勾选、选择器、上传、日期时间、评分或滑动输入	references/组件-数据录入-*.png
Tabs、Dropdown、Pagination、Breadcrumb 或 Step	references/组件-数据导航-*.png
表格、标签、卡片、树、徽标、头像、折叠列表、时间轴、日历、数据状态或展示型抽屉	references/组件-数据展示-*.png
Alert、Toast、Popconfirm、通知、结果提示、加载或模态弹窗	references/组件-数据反馈-*.png
框架、菜单、顶部栏、业务标题、导入流程、授权或业务弹窗与抽屉	references/业务组件-*.png

页面与容器资料、组件视觉样例可以叠加。例如制作带表单的确认弹窗时，同时读取弹窗页面资料、所需数据录入图片，以及对应的反馈或业务组件图片。

页面需要 Poseidon Logo 时，使用 assets/logo.svg。按照项目资源策略导入、复制或内联该文件；不要让交付物引用技能目录中的绝对路径。

选择任务模式

前端开发

在用户要求实现、修改、重构或修复生产界面时执行代码变更：

1. 明确页面类型、业务目标、数据结构、权限和关键状态。
2. 读取对应页面资料与相关组件规范，核对视觉样例。
3. 找到项目中最接近的页面或组件作为实现基线。
4. 规划正常、加载、空、错误、禁用、无权限及危险操作状态。
5. 按项目现有技术栈和组件 API 实现最小范围改动。
6. 补齐交互、响应式、无障碍和必要测试。
7. 按“验证与交付”完成检查并报告结果。

原型设计

在用户要求从需求、草图、截图、设计稿或既有页面创建原型时产出独立或项目内原型：

1. 明确原型要验证的问题、目标用户、页面范围、核心流程、目标视口和交互深度；用户未指定保真度时，默认制作可浏览的高保真原型并覆盖关键交互。
2. 依次采用用户指定的交付形式、项目既有原型技术栈、轻量可运行网页原型；不要为了原型引入生产级后端、认证或基础设施。
3. 读取对应 Poseidon 页面与组件资料，建立信息架构、内容层级、布局、视觉令牌和交互状态。
4. 存在项目上下文时复用其品牌、组件和内容；独立原型使用代表性内容与 mock 数据，不虚构会误导业务判断的能力。
5. 覆盖核心主流程，以及与原型目标直接相关的加载、空、错误、禁用、成功或危险操作状态。
6. 保持原型范围隔离、结构清晰且可直接预览；明确哪些行为是模拟的，不把原型描述为生产就绪实现。
7. 按“验证与交付”检查视觉和交互，并提供事实源路径、启动或预览方式。

UI 评审

在用户要求评审页面代码、运行界面、原型、截图或设计稿时保持只读：

1. 读取适用的项目规则、输入材料和对应 Poseidon 资料；仅有截图或设计稿时明确无法验证的运行行为。
2. 对可运行界面使用浏览器检查，对源代码运行非修改性检查，对静态视觉产物直接核对设计规范。
3. 检查业务信息层级、视觉一致性、组件选型、关键状态、响应式、交互、无障碍、项目一致性和回归风险。
4. 按严重级别输出问题；每项包含可定位证据、影响和可执行修复建议。代码问题提供文件与行号，视觉问题标明页面区域或组件。
5. 没有问题时明确说明，并列出未验证范围或剩余风险。
6. 除非用户明确要求修复，否则不要修改代码或设计产物，也不要输出替代页面。

评审并修复

在用户同时要求评审和修复时，先定位并说明问题，再按前端开发或原型设计模式实施修复；完成后重新执行相关检查。

Poseidon 核心约束

• 前端开发优先使用项目已有设计令牌；独立原型按 设计基础 建立局部语义令牌，不在组件中散落重复色值。
• 以 4px 为间距网格；只有图标光学对齐、1px 边框等明确例外可以偏离。
• 输入框和按钮默认使用 4px 圆角；卡片和菜单选中背景默认使用 8px 圆角。
• 左侧全局菜单默认使用 220px 展开状态，该状态是标准模式；菜单可折叠为 58px。二级页面另有独立的 140px 二级导航，示例中的 58px 只表示全局菜单折叠状态。具体规则以对应页面文档为准。
• 让当前路由决定菜单选中项；只有无路由的静态示例才默认选中第一项。
• 为按钮实现默认、悬停、按下、焦点、加载和禁用状态。
• 为删除、发布及其他不可逆操作提供清晰的二次确认和结果反馈。
• 让固定区域、滚动容器和粘性表头互不争抢滚动，避免双滚动条和内容遮挡。

无障碍与交互

• 使用语义化元素和可关联的表单标签；不要只用颜色表达状态。
• 保留清晰的键盘焦点样式，并保证可操作元素能通过键盘到达和触发。
• 为图标按钮提供可访问名称；为错误、加载和动态反馈提供合适的可访问提示。
• 让弹窗和抽屉锁定背景滚动、管理焦点、支持 Escape，并在关闭后把焦点还给触发元素。
• 在存在未保存内容或危险操作时，不要通过点击遮罩直接丢弃数据。
• 尊重项目的动画规范和 prefers-reduced-motion；避免仅为装饰增加干扰性动画。

验证与交付

1. 前端开发运行项目要求且与改动相关的格式化、lint、类型检查、测试和构建命令。
2. 原型设计至少验证事实源可正常预览、核心流程可操作、模拟行为有明确边界，且不存在阻断使用的控制台错误；不强制执行与原型无关的生产项目检查。
3. 对可运行的前端页面和网页原型使用真实浏览器验证；至少检查 1440×900 和 1920×1080，并检查用户或项目声明的其他断点。
4. 核对核心交互、键盘路径、加载/空/错误状态、滚动与溢出，以及适用的控制台错误和网络失败表现。
5. 对照相关示例图检查信息层级、对齐、间距、字体、颜色、圆角和状态，不机械追求截图像素而破坏项目一致性。
6. UI 评审保留证据并说明输入限制、未验证行为和剩余风险；不要把静态视觉判断描述成运行时验证结果。
7. 不要掩盖失败的检查。交付时列出事实源或被评审对象、用户可见结果、验证方法及结果。

完成检查

• 已确认前端开发、原型设计、UI 评审或评审并修复模式。
• 存在目标项目时，已读取适用的 AGENTS.md 并识别实际技术栈。
• 前端开发已复用现有组件和设计令牌，未无故新增依赖。
• 原型设计已明确保真度、交互范围、模拟边界、事实源和预览方式。
• UI 评审保持只读，并为问题提供可定位证据、影响和修复建议。
• 已读取任务相关的页面与组件参考资料。
• 已覆盖关键状态、危险操作和无障碍交互。
• 已完成与任务模式匹配的检查和浏览器验证。
• 已按目标提供生产代码、原型或评审结论。