SuperAPI AI Directory

opendesign-codegen

Frontend & websites

View repository

Updated 10-16 16:58

About this skill

OpenDesign Code Direct Output Guide

When designers work with AI tools,what the AI directly produces is Vue 3 + OpenDesign code that conforms to engineering standards—what is rendered is the design draft, and it can go directly into the production project.

❌ Do not "first generate HTML and then convert it into code". ✅ Do it in one step: directly output a real @opensig/opendesign component + --o- token Vue SFC.

This skill does not repeat the token table and component API; link as needed:


Applicability prerequisite: first confirm the target repo uses OpenDesign

The code produced by this skill is to go into the official website (portal) repos of various open source communities.Not all portals use OpenDesign—do not start before confirming:

  1. Read the target repo root AGENTS.md(follows the agents.md standard, and is the only entry point for all AI tools entering the repo) §1 tech stack table, look at the UI 组件库 row.
  2. Is @opensig/opendesign → continue using this skill.
  3. Is not(e.g. hifloat uses shadcn-vue + Tailwind, some use Element Plus) → stop, switch to the writing style of that repo's UI library; this skill does not apply.

🔴 Hard rule red lines (must-read before generating any code, highest priority)

Violating any one is considered non-compliant and must be rewritten:

  1. Component first: whenever OpenDesign has a corresponding control (button / card / form / table / tag / pagination, etc.), you must use the real component <OButton> / <OCard> / <OTable> …,Do not use native <button>/<select>/handwritten div as a substitute。
  2. Use only token variables: colors / spacing / font size / line height / border radius / shadows must all be var(--o-*) or var(--o-r-*),Do not hardcode hex / rgb / px font size / px spacing.Colors must use semantic tokens (--o-color-*); it is strictly forbidden to directly use palette variables(like blue1/gray1, such as --o-kleinblue-*/--o-grey-*/--o-brand-*)。
  3. <script setup lang="ts"> + TypeScript: props use defineProps<T>() generics, not string array style.
  4. No inline style="..."(except extremely special cases such as dynamic values, with comments);no !important。
  5. BEM naming + <style lang="scss" scoped>, nesting ≤ 3 levels.
  6. Do not penetrate and modify component internals: visual differences are expressed through component props and theme tokens; do not use :deep() to rewrite the internal structure of OpenDesign components.
  7. Copy goes through i18n: do not hardcode user-facing text; use the target project's i18n solution (e.g. t('module.key'))。

Starting approach

Start from a compliant SFC template, do not draft from scratch: copy references/starter-page.vue, it already demonstrates:<script setup> block order,@opensig/opendesign component imports,--o-/--o-r- tokens, scoped SCSS, responsive, i18n placeholders.

Theme mechanism (six communities)

The theme isselected by the consuming project at initializationand set via the root node; components and tokens adapt automatically, and the generated page code does not need to care:

<html data-o-theme="e.light">  <!-- e/a/k/m/g/u . light/dark -->
Community Theme code Community Theme code
openEuler e Mindspore m
Ascend a openGauss g
Kunpeng k openUBMC u

All colors use semantic tokens → they adapt automatically when switching themes / light-dark mode, with no need to write separate styles for dark mode.


Four Major Constraint Principles

① Visual Tokens

  • Colors must use semantic tokens: background --o-color-fill1/2/3, text --o-color-info1~info4, primary color --o-color-primary1, functional colors --o-color-success/warning/danger1, border --o-color-control1, link --o-color-link1. Semantic colors come with rgb wrapping built in, so directly var(--o-color-fill2)。
  • 🚫 Direct use of palette variables is strictly prohibited(i.e., raw color scales like blue1 / gray1):--o-kleinblue-*、--o-blue-*、--o-grey-*、--o-green-*、--o-red-*、--o-orange-*、--o-brand-* etc. allcan only be referenced internally by semantic tokens; business code is prohibited from writing them directly. What is wanted is "what is this color used for" (semantics), not "which number blue is this" (palette).
    • ❌ color: var(--o-grey-14) / background: var(--o-kleinblue-6)
    • ✅ color: var(--o-color-info1) / background: var(--o-color-primary1)
  • Page-levelfont size/line height/spacing prioritize responsive tokens:--o-r-font_size-* + matching --o-r-line_height-*、--o-r-gap-*(automatically scales with the viewport, no need to write media queries).
  • Border radius --o-radius-*, shadow --o-shadow-1/2/3, motion --o-duration-*+--o-easing-*。
  • ❌ Prohibited #fff/rgb()、--o-color-bg1/2/3(does not exist, use fill*for background), hardcoded 22px/32px。

Detailed table → opendesign-tokens。

② Component Usage

Design intent maps directly to OpenDesign components (do not create your own native substitutes):

Design intent Component Design intent Component
Button OButton Table OTable
Link OLink Pagination OPagination
Card OCard Tabs OTab+OTabPane
Tag OTag Dialog ODialog
Input/Select OInput / OSelect+OOption Icon OIcon

Quick reference for selection and key props/slots → references/component-cheatsheet.md; full API → opendesign-components。

③ Layout and Responsiveness

  • Page-level layout uses a 24-column grid (--o-r-grid-N + gutter --o-r-grid-column-gutter), and the sum of columns for side-by-side blocks = the total number of columns at the breakpoint.
  • Breakpoints: Phone ≤840 / Pad 841–1200 / Laptop 1201–1680 / Desktop >1680; responsive tokens adapt automatically; when a breakpoint is truly needed, use @media(or the target project's respond-to mixin)。

④ Project Implementation

Ensure the code can go directly into a production project; see references/engineering-rules.mdfor details; the core is the "hard rule red lines" above.

⚠️ Community differences: path aliases (such as ~@/), i18n syntax, typography mixins (@include h3), whether Vue APIs are auto-imported (VitePress explicit import vs Nuxt auto-import), SSR/SSG-safe syntax, etc.vary by target repository. This skill provides the general OpenDesign compliance skeleton; before implementation, first read the target repository root AGENTS.md + rules/ according to "Workflow · Step 1" to adapt. For how each portal repository exposes these conventions, see portal-workflow's portal-agents-doc skill。


Workflow

  1. Enter the repository to verify the target project(Mandatory, before writing code):
    • Read the target repo root AGENTS.md(the sole entry point for AI tools) → Read the relevant rules/*.md。
    • Confirm the UI library is @opensig/opendesign(see "Applicable Prerequisites" above), otherwise stop.
    • Figure out and adapt accordingly:framework family(VitePress: explicit import of Vue APIs; Nuxt: auto-import,import.meta.client/<ClientOnly>、useSeoMeta)、path aliases(~@//@/ , etc.),i18n(locales location and t() syntax, zh/en in sync),SEO/GEO mechanism(TDK is handled by the portal-workflow geo-fix pipeline,do not inject it again in components)、style rules(token usage,:deep strategy, SCSS nesting limit, whether there is a respond-to mixin)、naming convention。
    • For anything uncertain, use a generic approach + comments; never fabricate directories/mechanisms that do not exist in the repo.
  2. Read the latest sibling skill on demand(these skills are updated irregularly; do not write token values/component APIs from memory) — read only what you use, and only the version you use:
    • When using colors/spacing/font sizes/border radius, etc.specific token values → read ../opendesign-tokens/SKILL.md + the corresponding theme references/tokens-{theme}.md。
    • When usinga component's Props/Events/Slots → read ../opendesign-components/SKILL.md + the corresponding references/{component}.md。
    • When you need icons/build/styles, etc. CLI commands(gen:icon/build-style , etc.) → read ../opendesign-scripts/SKILL.md。
    • When you need to cross-referencedesign spec(grid/breakpoints/component visual specs) → read ../opendesign-design/SKILL.md。
    • The links at the top of this skill and component-cheatsheet.md are only an index;the source of truth is the sibling skill files。
  3. Getting started: copy references/starter-page.vue。
  4. Write code directly: build the structure with real @opensig/opendesign components, use var(--o-*)/var(--o-r-*)for all styles, use i18n for copy, use v-for+ semantic :key。
  5. Self-check: check item by item against references/checklist.md, and fix all violations.
  6. Delivery is production code — what renders is the design spec, with no intermediate conversion.

Reference files