add-ui

Users start this workflow with . is the canonical skill name in this repository. Some hosts may expose a friendly alias, but docs, wrappers, and source files should continue to refer to the skill as .

Once this skill is active, load $frontend-design — it contains the design principles, anti-patterns, and the Context Gathering Protocol. Follow that protocol before proceeding. If no design context exists yet, you MUST load $setup first.

When the request is for a brand-new landing page, marketing page, or several distinct directions and the aesthetic is still open, use the approved style-selection rules in 's design directions. Choose directions that fit the product idea and brand context instead of inventing vague vibe labels.

When working inside an existing project with an established visual system, preserve that system first and make the options feel distinct without quietly rebranding the product.

Also gather the smallest set of implementation details needed to generate usable code:

If the request is a redesign of an existing artifact, also identify:

Use this precedence order when deciding implementation defaults:

When React-based fallback defaults are relevant, also consult component library integration to decide whether the requested artifact should be led by primitives, reusable patterns, or block accelerators.

Ask only the missing questions. If you can infer the technical stack from the codebase, do so.

Consult these references as needed:

Use these deterministic helper assets when they improve consistency across hosts and agents:

Generate multiple meaningfully different UI directions for a requested artifact, help the user compare them, then guide selection and integration.

This includes both adding new UI and redesigning existing UI.

When the request is to redesign an existing page, section, flow, shell, or component, default to preserving the artifact's recognizable bones unless the user explicitly asks for structural reinvention. In practice that usually means:

If one variant intentionally pushes further on structure, label it clearly as the stretch option instead of quietly bulldozing the existing page.

This skill is for requests like:

The list is illustrative, not exhaustive.

Use the artifact taxonomy to determine whether the user is asking for a section, page, flow, shell, or data/content component.

Also determine whether this is:

Then identify:

Generate 5 candidate directions. Fewer than 3 reduces exploration; more than 5 becomes noise.

Use the variation quality bar to ensure the five directions are meaningfully different rather than cosmetic recolors.

When the request says to preserve the existing structure or essence, treat the current artifact as the baseline skeleton. The directions should primarily vary through visual system and messaging decisions rather than by deleting or reordering the page without permission.

For that kind of redesign, distinct options can differ through combinations of:

Each direction must have:

For redesigns of existing artifacts, also state:

For each direction, generate a real artifact package.

Prefer:

When redesigning an existing artifact, fork from the real current implementation when practical instead of rebuilding the whole thing from scratch. Preserve the requested structure first, then layer the design changes on top.

Use the preview and apply patterns to decide how to structure previews, fallback comparison formats, and final integration.

For every variation, include the same practical checkpoints:

For redesigns, also include:

Do not let one option be a sketch while another is production-grade. Compare like with like.

After generating the options:

Your recommendation should explain why the chosen direction best matches:

Once a direction is selected:

When a reusable pattern emerges, apply the spirit of — but do not build a bloated design system for one request.

Use the request mapping heuristics for artifact-specific priorities such as hero sections, pricing, paywalls, auth, dashboards, commerce flows, and content surfaces.

Whenever possible, present results in this order:

Use the variant naming scheme to keep labels, file names, and selection mapping deterministic. Use the preview page checklist when building a preview surface. Use the apply / cleanup checklist after the user selects a direction.

Remember: this skill is not a slot machine for interchangeable UI. It is a structured exploration workflow that helps the user choose among genuinely different, production-credible directions and end up with maintainable source code.