eliteforge-poseidon-ui-design

EliteForge Poseidon UI Design

Use the Poseidon design specification to accomplish three types of goals: develop or refactor production interfaces, create previewable prototypes from requirements or design assets, and conduct UI reviews of code or visual artifacts. First identify the goal and inputs, then choose the delivery form.

Execution Principles

First determine whether the task is frontend development, prototyping, UI review, or review and fix, then confirm the available inputs and expected deliverables.
When a target project exists, first read all AGENTS.mdapplicable to the target files, then inspect the tech stack, directory structure, and existing implementation.
Frontend development reuses the project's existing layout, component library, design tokens, icons, routing, state management, and testing infrastructure, and does not arbitrarily switch frameworks, introduce another UI library, add heavy dependencies, or rewrite unrelated pages.
Prototyping does not require an existing production project; follow the tools and formats specified by the user, and produce a prototype with controlled scope, previewable, and sufficient to validate the core flow.
When creating a product prototype in a frontend project, the development branch must append to the end of the feature branch name that conforms to the project's Git conventions: /prototype; standalone prototypes or non-frontend projects are not subject to this rule.
UI review remains read-only by default; unless the user explicitly requests fixes, do not modify the code or design artifacts under review.
When conflicts occur within the project scope, follow, in order, the user's explicit requirements, the applicable AGENTS.md, current project conventions, the Poseidon text specification, and visual samples.
Only read the reference materials and split images needed for the current task; do not load an entire component category at once.

Establish Task Context

Confirm the task mode, business goals, page types, target users, platform, and expected deliverables.
Inventory the repositories, source files, running addresses, requirements, data structures, screenshots, design mockups, or existing prototypes provided by the user.
When a target project exists, read level by level from the project root directory to the target file directory: AGENTS.md; rules from deeper files override same-category rules from higher levels.
For frontend projects, inspect the package manifest, lock files, build configuration, scripts, entry points, routing, state management, styling system, UI component library, and adjacent pages.
Look for reusable color tokens, spacing, fonts, layout shells, forms, tables, modals, and drawer implementations; when these foundations do not exist in a standalone prototype, establish local design tokens according to the Poseidon specification.
Clarify the target viewport, content hierarchy, key flows, data and permissions, normal and exceptional states, and the fidelity and interaction depth required for the prototype.
Determine the formatting, static checking, testing, building, preview, and review methods from project conventions or the delivery form; do not repeatedly ask when the information is sufficient to proceed.

Output Path

Determine the primary delivery path according to the task mode:

Always prioritize the files or directories explicitly specified by the user for the current task.
Frontend development uses the existing routes, pages, or components in the current project that carry the target functionality; new features use the uniquely determinable adjacent module in the project structure.
For prototyping, prioritize using the project's existing prototype, design, or demo directory; if it does not exist, write to <workspace>/prototypes/<feature-slug>/. For a single-file web prototype, the main file is the one under that directory named index.html。
UI reviews are output in the conversation by default, without writing workspace files; when the user requests a review document but does not specify a path, write to <workspace>/reviews/<feature-slug>.md。

Frontend code or prototype source files are the source of truth; screenshots and exported previews are derived artifacts and should be placed at the same level as the source of truth or in its subdirectories. Do not let any deliverable depend on the absolute path of the skill directory.

Read reference materials as needed

First read Design Fundamentals, then read page materials according to the task type, and supplement the corresponding split diagrams for the components actually used. The Markdown for first-level pages, second-level pages, modals, and drawers is the page-level business specification source; Design Fundamentals only provides cross-page supplements and must not replace or trim the page body with a summary. Use available image viewing tools to inspect PNG/SVG, and do not infer content from file names alone.

Page and container materials

Scenario	Required reading
Top navigation menu or application menu	`references/顶部导航菜单.md`、`references/顶部导航菜单.png`
First-level list or management page	`references/一级页面.md`、`references/一级页面示例图.png`
Second-level detail or configuration page	`references/二级页面.md`、`references/二级页面示例图.png`
Modal	`references/弹窗.md`、`references/弹窗示例图.png`
Drawer	`references/抽屉.md`、`references/抽屉示例图.png`
Color or theme	`references/浅色色板.png`
Icons, charts, illustrations, or cursors	`references/icon.png`、`references/图表.svg`、`references/插图.png`、`references/光标.png` in files related to the task

Component visual samples

Component specifications have been split into independent PNGs by theme. In the table below, * only indicates a file name prefix, not a batch loading instruction; first list the candidate files under that prefix, then, based on the component keywords in the file names, view only the images directly related to the current task. When the same task involves multiple components, supplement them one by one.

Component scenario	Candidate resources
Button, border, divider, or scrollbar	`references/组件-全局通用-*.png`
Input, search, switch, radio, checkbox, selector, upload, date time, rate, or slider	`references/组件-数据录入-*.png`
Tabs, Dropdown, Pagination, Breadcrumb, or Step	`references/组件-数据导航-*.png`
Table, tag, card, tree, badge, avatar, collapse list, timeline, calendar, data status, or display drawer	`references/组件-数据展示-*.png`
Alert, Toast, Popconfirm, notification, result prompt, loading, or modal dialog	`references/组件-数据反馈-*.png`
Framework, menu, top bar, business title, import process, authorization, or business modal and drawer	`references/业务组件-*.png`

Page and container materials and component visual samples can be combined. For example, when creating a confirmation modal with a form, read the modal page materials, the required data entry images, and the corresponding feedback or business component images at the same time.

Map the official Ant Design Vue code

Each time you view task-related component PNGs or Markdown containing component rules, first identify the component, state, and interaction from the visuals and text, then go to Ant Design Vue component overview to locate the corresponding component, open https://www.antdv.com/components/<component-slug>-cn and read the Vue example source code in "Code Demo". Before implementation or review, record the correspondence of "Poseidon reference → Ant Design Vue component → official Vue Demo name or code". It is prohibited to use ant.design React documentation, JSX, or TSX examples to replace Ant Design Vue code.

When a business component or page-level composition does not have a one-to-one official component, split it into a-menu、a-form、a-table、a-modal、a-drawer and other basic components, and look up the official Vue example code for each.
When the official website cannot extract the example source code, read vueComponent/ant-design-vue in the official repository for the corresponding components/<component-slug>/demo/*.vue, and prioritize using the tag content that matches the target project's ant-design-vue version.
Official Vue code serves only as a reference for component structure, API, state, and interaction implementation; visual specifications are still based on Poseidon materials and project design tokens, and adapted to the target project's actually installed ant-design-vue version and Vue coding conventions.
When the target project does not use Ant Design Vue, do not add dependencies solely to reuse examples; preserve the interaction semantics of the official examples and implement them with the project's existing components.
When no exact official example can be found, clearly record the gap and the closest official base component adopted, and do not describe React, third-party examples, or your own inferences as official Ant Design Vue code.

When the page needs the Poseidon Logo, use assets/logo.svg. Import, copy, or inline this file according to the project's asset strategy; do not let deliverables reference absolute paths in the skill directory.

Select task mode

Frontend development

Perform code changes when the user requests implementing, modifying, refactoring, or fixing a production interface:

Clarify the page type, business goals, data structures, permissions, and key states.
Read the corresponding page materials and related component specifications, and verify against visual samples.
Find the closest page or component in the project as the implementation baseline.
Plan for normal, loading, empty, error, disabled, no-permission, and dangerous operation states.
Implement minimal-scope changes according to the project's existing tech stack and component APIs.
Complete interactions, responsiveness, accessibility, and necessary tests.
Complete checks and report results according to "Verification and Delivery".

Prototype design

Produce standalone or in-project prototypes when the user requests creating a prototype from requirements, sketches, screenshots, design files, or existing pages:

Clarify the problem the prototype is meant to validate, target users, page scope, core flows, target viewport, and interaction depth; when the user does not specify fidelity, create a browsable high-fidelity prototype by default and cover key interactions.
Use, in order, the delivery format specified by the user, the project's existing prototype tech stack, and a lightweight runnable web prototype; do not introduce production-grade backends, authentication, or infrastructure for the prototype.
Read the corresponding Poseidon page and component materials, and establish the information architecture, content hierarchy, layout, visual tokens, and interaction states.
When project context exists, reuse its branding, components, and content; for standalone prototypes, use representative content and mock data, and do not fabricate capabilities that would mislead business judgment.
Cover the core main flows, as well as loading, empty, error, disabled, success, or dangerous operation states directly relevant to the prototype's goals.
Keep the prototype scoped and isolated, clearly structured, and directly previewable; clearly state which behaviors are simulated, and do not describe the prototype as a production-ready implementation.
Check visuals and interactions according to "Verification and Delivery", and provide source-of-truth paths and startup or preview instructions.

UI review

Remain read-only when the user requests reviewing page code, a running interface, prototype, screenshot, or design file:

Read the applicable project rules, input materials, and corresponding Poseidon materials; when only screenshots or design files are available, clearly state which runtime behaviors cannot be verified.
Use browser inspection for runnable interfaces, run non-modifying checks on source code, and directly check static visual artifacts against design specifications.
Check business information hierarchy, visual consistency, component selection, key states, responsiveness, interaction, accessibility, project consistency, and regression risk.
Output issues by severity level; each item includes locatable evidence, impact, and actionable fix recommendations. For code issues, provide file and line number; for visual issues, indicate the page area or component.
When there are no issues, state this explicitly, and list unverified scope or remaining risks.
Unless the user explicitly requests a fix, do not modify code or design artifacts, and do not output replacement pages.

Review and Fix

When the user requests both review and fix, first locate and explain the issues, then implement fixes according to frontend development or prototype design mode; after completion, re-run the relevant checks.

Poseidon Core Constraints

For frontend development, prioritize using the project's existing design tokens; for standalone prototypes, follow Design Foundations to establish local semantic tokens, and do not scatter repeated color values across components.
Use a 4px spacing grid; only clear exceptions such as icon optical alignment and 1px borders may deviate.
Input fields and buttons use 4px corner radius by default; cards and menu selected backgrounds use 8px corner radius by default.
The left global menu uses a 220px expanded state by default, and this state is the standard mode; the menu can collapse to 58px. Secondary pages have a separate independent 140px secondary navigation; the 58px in the example only indicates the global menu collapsed state. Specific rules are subject to the corresponding page documentation.
Let the current route determine the selected menu item; only static examples without routes default to selecting the first item.
Implement default, hover, pressed, focus, loading, and disabled states for buttons.
Provide clear secondary confirmation and result feedback for deletion, publishing, and other irreversible operations.
Make fixed areas, scroll containers, and sticky headers not compete for scrolling, avoiding double scrollbars and content occlusion.

Accessibility and Interaction

Use semantic elements and associable form labels; do not express status using color alone.
Preserve clear keyboard focus styles, and ensure operable elements can be reached and triggered via keyboard.
Provide accessible names for icon buttons; provide appropriate accessible prompts for errors, loading, and dynamic feedback.
Make modals and drawers lock background scrolling, manage focus, support Escape, and return focus to the trigger element after closing.
When there is unsaved content or a dangerous operation, do not discard data directly by clicking the overlay.
Respect the project's animation specifications and prefers-reduced-motion; avoid adding distracting animations purely for decoration.

Verification and Delivery

For frontend development, run the formatting, lint, type checking, test, and build commands required by the project and relevant to the changes.
For prototype design, at minimum verify that the source of truth can be previewed normally, the core flow is operable, simulated behavior has clear boundaries, and there are no console errors that block use; do not enforce production project checks unrelated to the prototype.
Use a real browser to verify runnable frontend pages and web prototypes; at minimum check 1440×900 and 1920×1080, and check other breakpoints declared by the user or project.
Check core interactions, keyboard paths, loading/empty/error states, scrolling and overflow, and applicable console errors and network failure behavior.
Check the information hierarchy, alignment, spacing, typography, color, corner radius, and states against the relevant example images, without mechanically pursuing screenshot pixel accuracy in a way that breaks project consistency.
UI review retains evidence and explains input limitations, unverified behavior, and remaining risks; do not describe static visual judgments as runtime verification results.
Do not conceal failed checks. On delivery, list the source of truth or the reviewed object, user-visible results, verification methods, and results.

Complete the check

Confirmed frontend development, prototype design, UI review, or review-and-fix mode.
When a target project exists, the applicable AGENTS.md has been read and the actual tech stack identified.
Frontend development reuses existing components and design tokens, with no dependencies added without reason.
Prototype design has clarified fidelity, interaction scope, simulation boundaries, source of truth, and preview method.
UI review remains read-only and provides locatable evidence, impact, and remediation suggestions for issues.
Task-relevant page and component reference materials have been read.
A mapping has been established from reviewed component PNGs and Markdown to Poseidon references and Ant Design Vue official Vue example code.
Key states, dangerous operations, and accessible interactions are covered.
Checks and browser verification matching the task mode have been completed.
Production code, prototypes, or review conclusions have been provided as required by the objective.