Lanhu Design Restoration

Problem it addresses

After a Lanhu design handoff, developers often compare layers, colors, spacing, fonts, and assets by hand. It is easy to miss gradients, shadows, non-uniform border radii, opacity, and complex layout behavior, while also creating one-off pages that diverge from the project’s existing design system. This skill turns design-to-component restoration into an inspectable workflow focused on pixel-level styling and production-ready output.

How it works

• Lists the available design screens and lets the user choose a page or index.
• Fetches .schema.json, .tokens.txt, the design screenshot, and sliced image assets; official HTML/CSS is downloaded only when requested and used only as a structural reference.
• Detects the target stack from package.json, pubspec.yaml, Podfile, and similar files, then identifies styling approaches such as Tailwind, SCSS, and CSS Modules.
• Uses .schema.json as the authoritative source for the layer tree and maps design elements to component code. If DESIGN.md exists, it reads the file first and follows its design tokens, naming, directory, and reusable component conventions.
• For mobile designs, checks adaptation setups such as pxtorem, postcss-px-to-viewport, and rem baselines before choosing output units.
• Runs a 13-item verification pass covering dimensions, colors, gradients, shadows, typography, spacing, image assets, overflow, component decomposition, and BEM naming.

Boundaries and notes

It fits frontend or cross-platform component restoration when a valid Lanhu cookie is available and the goal is to reduce missing style details. It does not replace interaction design, API integration, or accessibility testing. If the project lacks a mobile adaptation setup, output may remain in px with a note. When DESIGN.md and the schema conflict, follow the documented rule if present; otherwise prefer schema values for single-screen fidelity.