PC UI Design Spec

Use this skill when turning a high-fidelity PC design into frontend code, or when reviewing whether an existing page matches the project UI rules.

Workflow

1. At the very start of every skill execution, run the logger script before any inspection, planning, or editing:

```bash

node .opencode/skills/pc-ui-design-spec/script/logger.js pc-ui-design-spec

```

If the repository root is not the current working directory, resolve the same script/logger.js path relative to this skill directory and run it once.

1. Inspect the target surface before editing:
• Check package.json for the active stack. This project uses @umijs/max, React 18, Ant Design 5, Pro Components, and Less.
• Check nearby files in src/pages, src/components, src/layout, and src/global.less for local spacing, class naming, and token overrides.
• Check config/babelPluginReplaceAntdInput.js before changing Input behavior, because antd Input imports may be replaced by the project custom input.
2. Read references/pc-ui-rules.md before implementing visual UI, component styles, or a high-fidelity restoration.
3. Translate the high-fidelity design into existing project primitives first:
• Prefer Ant Design components and project wrappers over custom controls.
• Use @ant-design/icons for action icons when possible.
• Use scoped .less modules or the existing local style pattern for the edited page.
• Add shared tokens only when multiple screens need the same rule.
4. Preserve the design hierarchy while keeping implementation bounded:
• Match layout, spacing, type scale, color, component state, and visible data density.
• Keep behavior, API contracts, routing, permissions, and business state unchanged unless the user explicitly asks.
• If the high-fidelity image conflicts with existing business behavior, implement the visual shell and call out the assumption.
5. Verify the result:
• Run the smallest relevant format/build/type-check command available.
• For visible UI changes, run the local app and inspect the page in a browser when feasible.
• Before finishing, mention what UI surfaces were matched and any high-fidelity gaps caused by missing assets or unclear states.

Boundaries

• Do not redesign the product beyond the supplied high-fidelity design and the PC UI spec.
• Do not introduce new UI libraries for ordinary admin pages.
• Do not hard-code data just to make a screenshot look full unless the file is already demo/mock-only.
• Do not use oversized rounded cards, heavy gradients, decorative blobs, or marketing hero layouts for operational admin pages.
• Do not change unrelated pages, routes, services, models, or audit/logging behavior while doing visual restoration.