/frontend

Adapted and rewritten by Sico Studio (2026) from Anthropic's frontend-design workflow. See NOTICE.md and the license. The user's references and project system govern the result.

When the owner has not specified a visual direction, use the brief-first principles from Anthropic frontend-design and, when installed and applicable, the taste-skill approach to examine real reference details and choose subject-specific layouts. These are default methods, not automatic installation, a fixed style, or permission to copy third-party assets. Existing brand, explicit references, accessible behavior and the owner's direction take precedence. Check the installed version, host compatibility and licence before adapting third-party material.

These defaults remain usable offline: identify the audience, inspect the existing interface and available references, choose a subject-specific hierarchy and compact tokens, then compare the rendered result with the brief. If a suggested reference or tool is unavailable, state that and use evidence available locally rather than claiming it was inspected.

1. Read the brief before choosing a visual language. Identify page/product type, audience, content, primary action, emotional/utility register and practical constraints. Inspect the current rendered UI, components/tokens and supplied references on an existing site. Preserve unrelated user work.
2. State a compact design read and select one coherent direction. An explicit reference, monochrome request or existing brand overrides generic aesthetics. Use the private profile only for relevant approved taste; do not make a personal preference a universal public default. If a consequential visual choice remains unresolved, use prototype rather than pretending one direction was selected.
3. Define a small token set for type hierarchy, spacing, color, borders, radii and motion consistent with the project. Keep composition grounded in real content. Avoid generic card mosaics, tiny low-contrast labels, decorative dashboard effects, fabricated metrics/testimonials/logos and fake product screenshots. Use real assets or explicitly labelled prototypes.
4. Build the working interface, not just its screenshot: responsive layout, interactions, keyboard/focus semantics, loading/empty/error/disconnected states, light/dark behavior and reduced motion as applicable. Use an existing accessible primitive where it fits; keep animated/browser code in a client boundary and server content stable during hydration.
5. For requested raster edits/generation use the available image capability and save actual outputs, prompts and provenance. Preserve originals and identity constraints; inspect alpha/crop and optimization. A generated person's likeness is not guaranteed. Keep assets in the project rather than referencing an ephemeral tool path. Respect third-party attribution and distribution scope.
6. Verify the affected rendered UI and behavior in proportion to the change and project gates, including relevant viewport and accessibility states. When design references are selected, find 2–3 comparable real interfaces and explain the ideas adapted. Exercise the installed/native boundary for integration claims; a polished mock remains a mock.
7. Critique the result against the brief, make targeted corrections and rerun affected checks. Submit the actual diff, relevant visual evidence, commands/results, deviations and remaining uncertainty for Review using the design/review packet. Capture relevant FDK without overgeneralizing one crop/spacing correction.

Use actual record operations or standalone capture for ART, DOC, TSK and LOG relationships. If no writer exists, return a labelled draft report. No automatic Git delivery, external publishing or claim of completion from source inspection alone.

Skill settings

The owner's settings for this skill arrive in a "Skill settings" block. Honour them.

• designReferences (default on): when on, find two or three existing designs that fit the goal, cite them with links, and explain what you will adapt before you build. When off, build from the project's existing visual style and say in the report that no external references were used.