Turn content, visuals, and interactions into a usable interface. The target audience should be able to understand it, operate it, and complete tasks, while gaining an aesthetic experience commensurate with the content. Directly implement modification requests; remain read-only when the user explicitly requests a review.
This is the general frontend design method maintained by Shougongchuan Studio. The maintainer's identity does not determine the work's branding: prioritize compliance with the current request and the project design system; independent features may adopt a visual direction suited to the content, without writing the studio's color scheme, logo, fonts, or personal paths as defaults for all users.
Triggers
Activate when
- "Design this frontend using the Shougongchuan Studio version, and implement it directly."
- "This toolbar works, but the buttons, icons, and states don't look like a professional product."
- "Turn real cases into an interactive display supporting images, audio, and video, using GSAP."
- "Add a resources entry to the existing official website, and verify the access paths on desktop and mobile."
- “Design or refine this frontend UI with the existing product conventions.”
- “Audit this interactive case collection without changing the site.”
Do not activate when
- Only creating or installing a Skill, or only publishing a completed page: use the corresponding creation or publishing capability.
- The core task is brand positioning, business narrative, and marketing conversion: prioritize the existing Landing Page capability.
- Only tuning backend concurrency, startup architecture, request encapsulation, CSS cleanup, or standalone media editing: hand it to the corresponding capability.
Runtime context
Each time, read skill.yaml and Profile contract. Resolve context from the current request,
project status, Skill records, shared preferences, brand/user Profile, and secure defaults.
Environment variables may specify the Profile source; explicit requests always take precedence. Consume only the fields declared by the Manifest.
python3 scripts/profile_store.py read --skill-id lov-frontend-design --pretty
Only when the user explicitly expresses a cross-task preference, use profile_store.py record --confirm to save it, then report
the save path. A one-time "no need to follow brand restrictions" stays in the current context and is not inferred as a permanent brand preference.
Secrets, original assets, and personal absolute paths must not be written into a distributable Skill.
References by need
- All tasks:Interaction contract。
- New visual direction or full redesign:Art direction。
- Dynamic charts, GSAP, images, audio, video, or presentation mode:Motion and media。
- Before delivery:Acceptance。
- When choosing an adjacent capability:Skill composition。
- Sources and historical cases:Provenance。
Workflow
1. Find the real interface and acceptance path
Read the project rules, Git status, target routes, adjacent pages, shared components, and existing data sources, and preserve other work. Distinguish between a small product change, a complete interface design, and an independent display. Adding navigation does not require redoing brand strategy; a brand-new display requires first understanding the audience and content structure. The workload varies with scope.
Internally clarify the audience, what is known when it opens, the main task, core content, inputs and outputs, technical constraints, style constraints, asset authenticity, and the final access path. Decide directly what can be confirmed from context, and ask only about gaps that would change the outcome. Use the host's real tools, and do not assume possession of browser, media generation, or deployment capabilities.
2. Design the comprehension order and operational semantics
Determine what the first screen makes people understand, how the body unfolds the evidence, and finally how to continue the action. For long content, use progressive expansion, search, filtering, indexing, or specific cases, rather than mechanically arranging sections into same-sized cards.
According to Interaction contract Distinguish navigation, actions, states, and toggles.
Main controls have clear inputs, states, results, and next steps after failure, reusing existing components and state models.
Call lov-branding-consistency Review titles, buttons, descriptions, and captions, preserving source text and data.
When long-form body text is needed, accept confirmed manuscripts; do not automatically expand front-end design into research or article creation.
3. Determine the visual direction by context
Existing products follow existing tokens, components, typography, and layout conventions, placing novelty in content organization and details. For new work, use one sentence to explain why this direction suits the content and audience, then determine typography, density, color, asset treatment, and one memorable visual feature. Decoration must not compete for attention with charts, evidence, and primary actions.
Titles, body text, data, and annotations serve different typographic roles; check Chinese line breaking, numbers, long English strings, and real widths. Font choices are subject to readability, licensing, loading, and the project's current state; do not globally replace fonts just to be anti-template.
4. Implement the complete user path
Use the existing tech stack and dependencies. Standalone static displays may use HTML/CSS/JS; do not add an application framework for styling. When the same action group appears repeatedly, reuse a shared implementation. Data sources are real; snapshots note scope and date; do not pass off historical sample counts as the full current capability.
When media is involved, fully read Motion and media. GSAP serves relationship changes, narrative progression, and demonstrations; it is not the sole switch for basic content visibility. Primary operations all have real results.
For integrated sites, also check desktop navigation, mobile, identity branches, language, and target routes. Standalone HTML, downloads, and browser destinations use appropriate native links, avoiding accidental takeover by client-side routing. Deploy only within the current authorization scope; accept design completion and online release separately.
5. Check and fix in the real interface
Per Acceptance , cover the states and operations involved this time, and walk through the main paths with real inputs. Resolve content, interaction, and accessibility first, then adjust motion and details; check the narrowest supported width and common desktop. When a browser is unavailable, report static results and runtime items pending verification; do not claim that clicks, playback, or assistive technology have passed.
Save necessary screenshots, measurements, inspection commands, or re-readable artifacts. Read-only reviews list verified issues and their impact; modification requests implement fixes and re-verify. When evidence is incomplete, mark the specific gaps; do not write fabricated scores.
6. Deliver concisely
Provide the actual page or files, main changes, verified paths, and remaining limitations. Pages do not display internal briefs, design self-assessments, Agent operation logs, or self-descriptions such as "professional production." Update the narrowest references and real cases with reusable experience; do not elevate a single work's style into a universal rule.
Output contract
- The page or component's project-native code, plus necessary references to real assets.
- A clear content hierarchy, control copy, and consistent operation states.
- Media files or verified addresses, usage, and source records.
- Proportionate build checks, browser verification, and unverified items.
- Accurately distinguish local and online states; public Skill distribution is left to release capabilities.