Frontend UI Change Strategy

Frontend UI Change Strategy

Use this skill for existing ZhiYuan Agent frontend pages and components. Follow the repository's AGENTS.md and DESIGN.md rules, preserve unrelated worktree changes, and keep visual changes narrowly scoped.

Design Skill Routing

Use this skill as the project-specific entry point, then route to the optional visual skills by page type:

• For Work, Chat, Settings, MCP, Skills, local inference, and other product surfaces, follow DESIGN.md, the shared UI components, and rongxinai-ui-adapter. The marketing-page rules in the taste skills are not global defaults.
• For landing pages, marketing pages, portfolios, brand surfaces, or redesigns, read design-taste-frontend before forming the design read and scoped strategy.
• When the brief explicitly requests premium visual treatment or complex motion, also read high-end-visual-design and use it as a reference for direction and choreography.
• Both optional skills are advisory. Resolve conflicts in this order: AGENTS.md / DESIGN.md, project UI skills, design-taste-frontend, then high-end-visual-design.
• Do not install a font, icon library, animation library, or other dependency solely because an optional skill mentions it. Follow the repository's dependency approval rules.

Required Workflow

1. Read Before Editing

Before changing code:

• Read AGENTS.md and DESIGN.md when the task concerns ZhiYuan Agent UI.
• Inspect the page entry point, relevant parent layout, target component, shared UI components, i18n keys, and tests.
• Use rg to locate visible copy, state, event handlers, and style classes.
• Check git status --short and inspect existing diffs for files that may be modified by the user.
• If an image or screenshot is supplied, map the highlighted visual region to the smallest responsible DOM element and class.

Do not edit during this phase.

2. Explain the Current Implementation

Report:

• The exact file and approximate line containing the target UI.
• The relevant DOM hierarchy and layout relationships.
• The state, event, or component behavior that must remain unchanged.
• The class, token, or shared component responsible for the current visual behavior.
• Any responsive or dark-mode implications.

Distinguish confirmed code facts from visual inference.

3. Propose a Scoped Strategy

Give a concrete patch strategy before implementation:

• Name the exact class, prop, wrapper, or component to change.
• Prefer a one-file, minimal-diff adjustment when the target is local.
• Reuse existing shadcn/ui or ai-elements components; do not create replacement buttons, selects, tabs, dialogs, or tooltips.
• Preserve i18n, callbacks, state, IPC, pagination, and data flow unless the request explicitly changes behavior.
• Use semantic theme tokens and existing Tailwind scale values. Avoid hardcoded colors, arbitrary spacing, and unrelated refactors.
• Account for responsive wrapping, focus-visible, disabled, hover, and dark-mode behavior.
• State whether tests or visual verification should be added or run.

For ambiguous visual requests, present the recommended interpretation and briefly name the main alternative. Do not silently change interaction patterns when the request only asks for styling or position.

4. Wait for Explicit Approval

Stop after the strategy and wait for approval. Treat direct confirmations such as 批准, 执行, 实施, 部署该修改, ok, or go ahead as approval.

Do not edit merely because the user described a target. Do not treat a request for analysis or strategy as approval.