Back to Details

design-system-reconnaissance

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

design-system-reconnaissance

design-system-reconnaissance

Fixes that look bolted on erode the trust they were meant to build: a 404 in a different font, a cookie control in someone else's blue, a privacy page with default browser styles. This skill records what already exists so new UI is built from it.
看起来像是后加的修补会削弱它们本应建立的信任：字体不同的 404 页面、采用别人蓝色系的 cookie 控件、带有浏览器默认样式的隐私页面。这个 skill 会记录项目中已经存在的内容，让新的 UI 基于这些内容构建。

Activate when

何时启用

  • About to add or modify visible UI: 
    error-pages
    , 
    privacy-policy
    /
    terms-of-service
    pages, 
    consent-management
    controls, footer/nav links, empty/error states, forms.
  • Skip it when the change is invisible (metadata, robots, headers) or when a fresh, recent 
    .readyvibe/design.md
    exists.
  • 即将添加或修改可见 UI：
    error-pages
    、
    privacy-policy
    /
    terms-of-service
    页面、
    consent-management
    控件、页脚或导航链接、空状态或错误状态、表单。
  • 如果变更不可见（元数据、robots、响应头），或者已有一份近期新建的 
    .readyvibe/design.md
    ，则跳过。

Inspect

检查

  1. Tokens. CSS variables, Tailwind config (
    theme.extend
    ), theme files, 
    tokens.json
    : colors (brand, neutrals, semantic), type scale and families, spacing, radii, shadows, breakpoints. Note dark-mode handling.
  2. Components. Existing Button, Link, Heading, Container, Card, Dialog, Form field, Footer, Header, Alert. Prefer reuse over new markup. Note variants and how they are composed (Tailwind classes, CSS modules, styled-components, shadcn/ui, MUI).
  3. Layout patterns. Page shell (header/main/footer), max content width, section rhythm, how text pages (about, blog) are laid out; this is the template for legal pages.
  4. Voice. Tone and person in existing copy ("we" vs. "Acme"), casing of headings and buttons, punctuation. Legal or policy copy still needs to be clear; match register without adopting jokes in legal text.
  5. Assets. Logo files, favicon, illustration style, icon set.
  6. Rendered check. Open the running site at desktop and 375px to see it as visitors do; source can mislead (a component may be overridden).
  7. The component ladder (write it into your note, and follow it when building): (1) reuse an existing component as is; (2) compose existing components; (3) extend an existing primitive with a variant or prop; (4) only when nothing fits, create a new component that matches the tokens, spacing, and behavior of its neighbors. Never introduce a "ReadyVibe style", and never casually add another UI library, CSS framework, or icon set; if the project already uses one, use it.
  8. Behavior patterns too, not just looks: how dialogs, menus, forms, validation errors, toasts, loading states, and empty states already behave (focus handling, motion, dark mode, RTL/locale handling); new UI must behave the same way.
  1. Tokens。 CSS 变量、Tailwind 配置（
    theme.extend
    ）、主题文件、
    tokens.json
    ：颜色（品牌色、中性色、语义色）、字号层级和字体家族、间距、圆角、阴影、断点。记录暗黑模式处理方式。
  2. 组件。 现有的 Button、Link、Heading、Container、Card、Dialog、表单字段、Footer、Header、Alert。优先复用，而不是编写新的标记。记录变体及其组合方式（Tailwind classes、CSS modules、styled-components、shadcn/ui、MUI）。
  3. 布局模式。 页面框架（header/main/footer）、最大内容宽度、区块节奏，以及文本页面（about、blog）的布局方式；这是法律页面的模板。
  4. 文案风格。 现有文案的语气和人称（“we”还是“Acme”）、标题和按钮的大小写风格以及标点符号。法律或政策文案仍需保持清晰；应匹配整体表达风格，但不要在法律文本中采用玩笑语气。
  5. 资源。 Logo 文件、favicon、插画风格、图标集。
  6. 渲染结果检查。 在桌面端和 375px 宽度下打开正在运行的网站，像访问者一样查看效果；源代码可能会造成误导，因为组件可能被覆盖。
  7. 组件阶梯（写入记录，并在构建时遵循）：(1) 原样复用现有组件；(2) 组合现有组件；(3) 使用 variant 或 prop 扩展现有基础组件；(4) 仅当没有任何现有方案适用时，才创建与相邻组件的 tokens、间距和行为一致的新组件。绝不引入“ReadyVibe style”，也不随意添加其他 UI 库、CSS 框架或图标集；如果项目已经在使用其中一种，就继续使用。
  8. 不仅要检查外观，也要检查行为模式： 记录 dialog、菜单、表单、验证错误、toast、加载状态和空状态现有的行为方式（焦点处理、动效、暗黑模式、RTL/locale 处理）；新 UI 必须采用相同的行为方式。

Evidence that counts

有效证据

Label each claim OBSERVED, SOURCE-INDICATED, DECLARED, INFERRED, UNKNOWN, or REVIEW REQUIRED. UNKNOWN is never a pass and never a failure.
  • Token in source, but unused or overridden: SOURCE-INDICATED. Confirm in the rendered page.
  • A style guide in the docs is DECLARED. If the site diverges, the site's actual look wins for consistency.
将每项结论标记为 OBSERVED、SOURCE-INDICATED、DECLARED、INFERRED、UNKNOWN 或 REVIEW REQUIRED。UNKNOWN 既不算通过，也不算失败。
  • 源代码中定义、但未使用或已被覆盖的 token：SOURCE-INDICATED。需要在渲染后的页面中确认。
  • 文档中的样式指南属于 DECLARED。如果网站与指南不一致，为保持一致性，应以网站的实际呈现效果为准。

May change

允许变更的内容

Only an optional working note, 
.readyvibe/design.md
: a short list of the tokens, components, behavior patterns, and the component ladder the specialist should use, with file paths. Never product code.
仅允许变更一份可选的工作记录 
.readyvibe/design.md
：简要列出需要使用的 tokens、组件、行为模式和组件阶梯，并附上文件路径。绝不修改产品代码。

Must not claim

不得声称

That the site "has a design system" when it has ad-hoc styles; say "no consistent system found; these are the most-used values". Never invent a new palette, typeface, or component library.
如果网站只是临时拼凑的样式，不要声称它“有一套 design system”；应说明“未发现一致的体系；这些是使用最频繁的值”。绝不臆造新的调色板、字体或组件库。

Verify

验证

A specialist that follows the notes should produce UI that uses existing tokens and components. After the UI is built, compare it with an existing page at desktop and 375px; the difference should be the content, not the styling.
遵循该记录的开发者应能够使用现有的 tokens 和组件构建 UI。UI 构建完成后，将其与现有页面在桌面端和 375px 宽度下进行比较；两者之间的差异应仅体现在内容上，而不是样式上。

Escalate

上报

Contradictory styles across the site (three buttons, four grays): note it and pick the dominant one for new UI; flag the inconsistency for the owner instead of "fixing" the whole site.
如果网站中的样式相互矛盾（例如三种按钮样式、四种灰度），记录该问题，并为新 UI 采用占主导的方案；应向负责人标记这一不一致之处，而不是“修复”整个网站。

No change is valid when

以下情况无需创建记录

The change is not visual, or the project has one page with inline styles you can mirror directly. Then skip the file and match that page.
变更不涉及视觉呈现，或者项目只有一个带内联样式的页面可供直接参照。此时跳过该文件，并匹配该页面的样式。