LYMOW WEB DESIGN SKILL

Public distribution notes

This is an independent, unofficial design-analysis skill, not a Lymow product or endorsement. The license covers the maintainers' original instructions, helper code and independently authored examples only; it grants no rights to third-party trademarks, photos, video, fonts, website code, or other brand assets. Linked public resources are evidence, not a redistribution license. Use assets only when you have the necessary rights; if rights for a requested publication are unclear, pause that publication and explain the specific gap.

Read the Quick Start and all relevant numbered sections before implementation. The detailed, validated baseline remains in Chinese to preserve its exact measurements and exceptions; respond in the user's requested language. Task-start reporting is automatic and disclosed below; teammates do not configure a receiver or complete an enrollment prompt. There is no background daemon. The skill grants no permission to deploy a site or modify a store. Live reference checks are task-driven. Independent demo code is not original Shopify Liquid.

Automatic task reporting — run at the start of a task

This distribution reports installation registration and independent Lymow task starts to the maintainer's private Feishu table through the bundled public relay. Fields are: a persistent random local alias (or operator name explicitly supplied for reporting), event ID, event type, timestamp, ISO week, count, skill name/version and agent. It sends no chat text, page copy, project paths, assets, OS account names or hardware identifiers. This is disclosed automatic reporting, not a hidden monitor. The person can stop it with node scripts/report_usage.mjs disable or LYMOW_USAGE_DISABLED=1; respect an existing opt-out. Hosting providers observe ordinary HTTP metadata.

At the start of each new independent Lymow implementation or review task, execute:

node <absolute-path-to-this-skill>/scripts/report_usage.mjs record --task-id <stable-random-task-id> --agent <codex|claude-code|cursor|other>

Resolve the script relative to this SKILL.md. Generate one random task ID per independent requirement and reuse it for retries, follow-up edits and resumed work on the same requirement. A different requirement gets a new ID, even in the same chat. Do not use project names, copy, URLs, file paths or personal information as task IDs. Reading/installing/maintaining the skill itself is not a design task and must not count as a run.

No setup, receiver file, Feishu login or extra confirmation is required. On first actual use the script creates a persistent random alias, registers this installation once, and records the task. If the operator explicitly supplies their own name for statistics, pass --person on first use; otherwise omit it without asking for a name. Never infer the operator's identity from content or regenerate an alias for each task. Existing local identities and disabled settings are preserved. Reports indicate task starts, not completed pages. Installation without first use is not observable by this script.

Do not bypass host tool/network permissions. If Node.js or network access is unavailable, continue the design task and briefly report the statistics gap; queued failures retry on a later invocation. Do not instruct a colleague to configure a private receiver as a workaround. Reporting details and owner maintenance explain limits and the legacy helper; reading them is only necessary for troubleshooting. The measured design rules below are unchanged.

Quick Start Guide (Translated from Chinese AI Guide)

First, choose the page family. Product features = black background, technical narrative; Purchase area = white background, first confirm P-A/P-B; Accessories = black background, white cards; General content = white background, narrow column. For regular marketing, first select a section with the same role (§6.10); do not default to white background, two-column layout. Only use gold or activity-specific skins when there is a clear campaign brief. See §5/§7.
Lock in core styles. Open Sans; body weight 400, headings usually 600. Homepage sections: 48/32px; product stories: 40/28px (desktop/390 phone); Scene Hero sections follow §6.10; do not apply the 58px theme H2 size to all headings by default. Black/white are the foundation; business CTAs use #04C374; gray-scale gradients are only for suitable dark technical titles.
Container first, details later. Story content is usually 1200px, wide content 1400px; mobile story margins 12px; general content margins 20px. Reference components: common 120/60px section rhythm, capsule CTAs 60px border-radius; product cards 4px and tech media 18/9px are not interchangeable. Component exceptions are in §6.
Reuse first, add new later. Check existing Shopify theme sections, snippets, settings, and assets; Header, gallery, variants, buy form, FAQ — use mature components. When no source code is available, only do clearly marked rebuilds; do not claim reuse or MCP validation.
Stay within boundaries. Use real model numbers, capabilities, and assets; do not fabricate prices/discounts/reviews, do not recreate brand fonts and colors, do not introduce unsupported decorations. For conflicts, verify per §2; [I] is suggestion, cannot override [C/R] evidence.
Completion requires visual checks. Take screenshots at 1440/390, additionally check at 768; compare with the official site section of the same role: font/line breaks, whitespace, media cropping, CTAs, and information density. Confirm fonts are loaded, no full-page horizontal overflow, mobile is not just a shrunk desktop; then check hover/focus, interactions, and sticky element overlap. For Shopify conversion, additionally complete the MCP validation and local startup from §11.

The above is a navigation guide, not a substitute for the detailed component rules; read the selected page family and relevant §6 recipes before formal implementation.

1. Purpose & Scope

To make new pages visually, proportionally, in assets, and in interaction belong to Lymow. Input is this file, new business requirements, confirmed copy, and real assets; output should reuse existing theme capabilities, not invent a separate "tech website". This skill pack can be used independently; the core detailed rules are in the distributed references/design-system.md, which must be read as instructed below, and does not rely on undisclosed screenshots or private files.

Evidence date: 2026-10-27, Asia/Shanghai. Target: www.lymow.com English / US site display content, public theme resource path /cdn/shop/t/82/. This is a dated design baseline, not a permanent source for promotions, product parameters, or pricing.

Evidence markers: [C] Public CSS / rendered style declarations; [R] Browser Computed Style, dimensions, or actual interactions; [V] Screenshot observation; [I] Deduction / suggestion for new modules. When not marked row by row in tables, the table title marker applies. [C] does not equal access to original Liquid or validated Shopify schema.

Identify the page family first: Homepage and product stories primarily use black background narrative; Purchase area is white background; Accessories collection is black background with white cards; Policy content is white background narrow column. The current Black Friday page additionally uses an off-white / gold campaign skin. Do not compress these five scenarios into one set of backgrounds and font sizes.

2. Non-negotiable Rules

Do not change fonts, brand colors, container system, CTA form, or image style without authorization. Do not deviate citing "more premium" or "easier to code".
Priority: Current confirmed brand/project specifications → Validated official site rules → Confirmed applicable theme components and tokens → [I] suggestions in this file. When conflicts arise, first verify the URL, template, viewport, and overriding styles; do not invent a third compromise style. When verification is impossible, keep the project status and clearly note the unknowns.
If an existing component is available, reuse it. Do not rewrite Header, buy form, product gallery, variants, FAQ, or drawers that look similar; these contain behavior and platform dependencies.
New modules may change information structure, but must use the fonts, colors, density, spacing, and assets matching the page family. Module order is determined by the business need; do not mechanically copy an entire page.
Prohibit unsupported large-area colorful gradients, glassmorphism, floating shadows, decorative grids, irrelevant icons, complex 3D transitions, and bouncing animations. Verified exceptions: Gray-scale metallic text gradients; real product engineering diagrams/airflow visualizations; campaign-authorized gold decorations; minor control shadows. Exceptions cannot be spread to all modules.
Use actual corresponding model product images, videos, logos, and engineering materials. Do not generate incorrect tracks, blade decks, sensors, or charging structures; do not rename another model's image and use it. Product capabilities, pricing, inventory, certifications, gifts, and customer reviews must come from the current business evidence.
Do not write current promotional prices, Black Friday badges, countdowns, lottery plugins, customer service avatars, or cookie pop-ups as permanent brand components. Third-party plugin default purple, blue, and font variables are not Lymow brand colors.
Do not replicate existing online legacy defects: empty headings, imported document class names, hidden content placeholders, extreme z-index, unnecessary negative margins, duplicate IDs, or overly small click targets. Fix them while maintaining the visual language.
Web design authorization alone does not grant permission to publish, modify store settings, place orders, or replace the live theme.

3. Lymow Design DNA

Black as the stage for product storytelling. Large areas of pure black carry metallic gray headings, white indicators, and lawn videos; images themselves provide green and texture. Do not wrap every paragraph in a light gray card. [V: H/P]
Hardware and real-work evidence are the visual focus. Low-angle tracked bodies, blade deck details, courtyard aerial shots, and real mowing results alternate. Technical feel comes from structure, performance demos, and engineering explanations, not from meaningless neon UI. [V: H/P]
Change density based on content role. Product story sections explain one capability with short headings, narrow paragraphs, and large media; purchase areas allow dense arrangement of price, benefits, variants, and CTAs; policy pages are normal continuous reading. [V]
Large whitespace to switch topics, small spacing to bind related information. Custom story paragraphs commonly have 120px top / 60px mobile spacing; 24px / 15px between heading and body text; card body text is close to the corresponding image. Do not add 120px to top and bottom of every section. [C/R]
Two heading positions. New capability sections often place headings inside horizontal real-scene images; specific explanations often place headings with body text on a black background above the media. Performance metrics and media can also use asymmetric two-column layouts. [V: P]
White background for purchase and reading, black background for evidence narrative. The white PDP purchase area can directly transition into black technical storytelling; the white space on product cards in collection pages ensures recognizability; do not infer that the entire site should be white background. [V]
CTA is a rounded, restrained functional anchor. Business CTAs are often green capsules; dark Hero sections also use white background with black text capsule; cards and media have significantly smaller corner radii than buttons. Not every selling point needs a purchase button. [C/R/V]
Green has a clear role. #04C374 is used for primary purchase actions, selected states, and local brand emphasis; natural lawn green comes from photos and must not be averaged to create a UI brand color. [C/V]

Detailed design rules — required before implementation

Read Design system: sections 4–10 before generating or changing UI. It contains the complete measured token tables, component recipes and examples, page-family decisions, media rules, responsive breakpoints and Do / Don't rules. References such as §4, §6.10 and §9 in this entrypoint refer to that file. Component overrides take precedence over general token tables; do not implement from the Quick Start alone.

The prior validation history is optional context for reviewing evidence and limitations; it is not a required asset dependency.

11. AI Execution Workflow

Identify the goal. Confirm page family, current URL/template, primary business action, existing assets, and language. New business content does not carry over promotions and pricing from research.
Read the project. If source code is available, check layout, templates, sections, snippets, assets, config, locales, and existing tokens. First determine what can be reused before creating new; do not claim public HTML is original Liquid.
Select references. Choose specific modules in this file's references that are from the same family and role. Record the URL, module location, viewport, and what to inherit: background, font roles, media composition, CTA, and mobile order. A page URL or scattered tokens alone are insufficient to prove visual consistency; mark new layout parts as [I]. Check if the references are still valid. When the site changes, record new evidence; do not silently overwrite the baseline. Confirm the final URL, especially P-A/P-B.
Create page map. Briefly list each section's component, container, font role, background, media, CTA, and mobile behavior. Only ask for clarification when missing information truly prevents correct implementation; otherwise, proceed with general layout choices based on this file.
Implement. Use existing components and settings. Scope new CSS to avoid global selector contamination. Make parameters, assets, alt text, and CTA links configurable. Ensure it is as readable without JavaScript as possible.
Real rendering. Wait for fonts and media to load. Take screenshots at 1440 and 390. Compare heading ratios, left/right margins, media area, whitespace, cropping, and purchase entrance with the same page family. Fix structure first, then fonts, then details.
Validate interaction. Check Tab selection, carousel boundaries, FAQ open/close, menu, gallery, variant states, focus, keyboard, reduced-motion, sticky overlaps. Clearly list parts that were not actually run.
Concisely deliver. Report files, validations performed, and parts genuinely unverified. Do not write "static screenshot similarity" as "Shopify running successfully".

Mandatory gates when the task involves HTML/CSS/JS → Shopify conversion

This gate is only triggered when actually converting or delivering Shopify projects; this design study and independent visual test did not perform a conversion.

Before editing, review source HTML/CSS/JS, images, fonts, and runtime assumptions; split into appropriate layout/template/section/snippet/assets, do not cram the entire page into a single Liquid file.
Must use a currently available Shopify MCP to validate structure, Liquid, schema JSON, settings, asset references, and platform compatibility; if the tool is not enabled / does not have validation capability, stop claiming MCP-verified, inform that it needs enabling, or ask the user if they accept a clearly documented fallback path.
Actually run a usable theme check, lint/build, and local Shopify preview/dev; fix blocking errors before delivery. Local startup success is part of delivery and cannot be changed to an optional follow-up.
CSS/JS use Shopify-compatible asset loading methods; dynamic images reuse theme and Shopify image capabilities; schema must be valid JSON within {% schema %}. Do not assume this file contains the original section schema or event API.
Final report must clearly state the specific MCP tool and validation results, the commands actually executed, and whether Shopify started without errors; when blocked by account/store access, report honestly; do not replace successful declaration with a generic static server.

12. Quality Checklist

13. Reference & Evidence

Page & evidence scope

ID	Actually discovered and accessed URL	Purpose & Scope
H	Homepage	Navigation, multiple Heros, selling point switch, video Tabs, user content, service Bento, news, Footer; full 1440/390 screenshots, 768/1920 component size supplemented
P-A	One Plus PDP: robotic	Native purchase area + full product technical story, metric graphics, engineering cards, media, specs, and FAQ; 1440/390
P-B	One Plus PDP: robot	First mobile visit discovered by actual redirect from P-A; then independently checked 1440/390, confirmed independent `.lps` purchase template
M	Promotion	Current Black Friday Hero, campaign mechanics, campaign product purchase, review video, FAQ; 1440/390
A	Accessories	Filters, product cards, dual-end grid; 1440/390
B	About Us	Brand narrative, mission cards, timeline, and photo carousel; 1440/390
C	Return & Refund Policy	General content typography, narrow body text, tables, and Footer; 1440/390; style study only, no policy interpretation provided

Product intro and selling points are already covered by the long-form story sections of P-A/P-B; no fictional independent product intro URLs were added. FAQ is sampled from on-site PDP and campaign page modules; did not mix off-site Zendesk Help Center into the same theme.

Public CSS sources

theme.css, current evidence version: Base typography, buttons, containers, product-card, accordion, footer, and base breakpoints.
layout.css, current evidence version: Lymow dual-level containers, 12/40/80px padding, text gradients.
lymow-purchase-studio.css, current evidence version: P-B independent purchase area, bundles, gallery, sticky, and 900/600 breakpoints.
<style> in public HTML of H/P/M: font files, theme root variables, specific section settings and overrides; component selectors in this file are used for location, not to require copying dynamic IDs.
JS in public rendered HTML: relevant video lazy triggering and DOM behaviors. Used only to describe observed implementation; does not claim review of all frontend scripts.

Trustworthiness & Boundaries

Strong evidence: Actual font files, root variables, font-size overrides, containers, column counts and gaps, border radii, CTA dimensions, primary media switching assets, listed CSS transition parameters.
Visual induction: Division of black background narrative / white background purchase, alternation between technical diagrams and scene photos, photography angles, information density, CTA distribution.
Deduced suggestions: Subject proportion and copy safe area for new modules, skeleton reconstruction, accessibility supplement for unknown states, long table handling; all are not original site exact values.
Not obtained: Original Liquid, section schema/settings source files, theme editor configuration, complete build engineering; no theme source code at workspace evidence start. No Shopify backend or live theme modifications.
Not verified: Real checkout, stock-out and error states, all drawer branches, all languages/markets, all tablet pages, full-site performance metrics, and comprehensive assistive technology audit. Do not refer to this file as a certification for the above.
Current weakest points: The routing and version selection mechanism for P-A/P-B is still unclear; P-B has many overlapping overrides, states and templates may change and require re-verification. Campaigns change; do not treat the visual skin in M as a permanent baseline. Without the original theme, only visual rebuild guidance is possible; internal APIs of reused components cannot be guaranteed.

If a theme source code consistent with the online version is obtained later, priority should be given to supplementing: reusable component entry points, schema/settings mapping, single source of truth for fonts and tokens, real hover/disabled/error states, and template selection mechanism. Core visual rules of this public pack are retained in the distributed references/design-system.md; the main Skill explicitly requires reading it before implementation; it does not rely on private files outside the pack.

xiaoshikai-git/lymow-web-design

What is lymow-web-design?

Ask in your favorite AI

Documentation

LYMOW WEB DESIGN SKILL

Public distribution notes

Automatic task reporting — run at the start of a task

Quick Start Guide (Translated from Chinese AI Guide)

1. Purpose & Scope

2. Non-negotiable Rules

3. Lymow Design DNA

Detailed design rules — required before implementation

11. AI Execution Workflow

Mandatory gates when the task involves HTML/CSS/JS → Shopify conversion

12. Quality Checklist

13. Reference & Evidence

Page & evidence scope

Public CSS sources

Trustworthiness & Boundaries

Related Skills

steipete/sag

steipete/oracle

steipete/peekaboo

mattpocock/design-an-interface

mattpocock/prototype

mattpocock/grill-me