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.

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.

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.