Communitygithub.com

LIKELION-CAPSULE/Landing_Page

Builds multiple variants of a component you're working on and helps you iterate and pick one.

Landing_Page 是什麼?

Landing_Page is a Claude Code agent skill that builds multiple variants of a component you're working on and helps you iterate and pick one.

相容平台~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/LIKELION-CAPSULE/Landing_Page/tree/HEAD/.agents/skills/variant

在你喜歡的 AI 中提問

開啟一個已預先載入此 Agent Skill 的新對話。

說明文件

Variants

This skill takes one described piece of UI and builds three versions that differ on purpose. They go behind a picker in the real page, so you can flip between them and choose.

It produces candidates and never ranks them. Reviewing existing UI is interface-review and better-interface, stress testing one component is break and working through a component's states is state-machine.

Different answers, not different tints

Each variant is a different answer to the same brief, on an axis this collection owns:

AxisOwnerWhat varies
Structurebetter-layoutGrouping, order, column count, what collapses
Densitybetter-layoutSpacing scale, how much fits
Emphasisbetter-colorsWhere filled color goes, what recedes
Typebetter-typographyScale steps, weight contrast, measure
Voicebetter-writingLabels, tone, how much copy

Pick one primary axis and give each variant a different position on it. Secondary choices follow from it rather than varying on their own. A dense variant may need a smaller type step, and that is coherence, not a second axis.

The floor every variant clears

Before a variant enters the picker it clears better-interface's escalation triggers, which are:

  • Every control has an accessible name and a visible focus indicator.
  • Keyboard reaches everything a pointer does.
  • Motion and auto-playing content respect prefers-reduced-motion.
  • Nothing clips, overlaps or becomes unreachable at 320px width or 200% zoom.
  • Body and control text pass their required contrast ratio.
  • No state or meaning rides on color alone, and no state change on motion alone.
  • A destructive action has a confirmation, an undo or a distinct treatment.
  • Truncated content has a way to reach the full value.
  • Nothing hides past a scroll edge or behind a disclosure with no visible cue.
  • Every error names a way to recover.
  • No semantic color is used against its meaning, such as the danger hue on a non-destructive action.

That floor is identical across variants. It is not an axis and never trades against one. Where a direction can only work by breaking it, say so and drop the direction.

1. Scope one piece

One piece of UI per run. "The dashboard" is not a piece; the metric card is. Where the request spans several, list the candidates and ask which one to explore.

Restate the brief in one sentence: what the thing is, where it renders, what it has to do.

2. Learn the ground

Variants have to look like they could ship tomorrow, so read what they stand on:

  • The styling system, the component library and any motion library.
  • The tokens: color, spacing, radius, type scale, easing.
  • The product's density and voice. A dense professional tool bounds how far the boldest variant may go.
  • Where the piece renders: against what background, beside which neighbours, at which widths.

With no project to read, use neutral grays, one accent and the system font stack, and say that is what you did.

3. Name the axis before writing code

Default to three variants. Go to five only when asked.

Write the set down first, a name and an axis position each. Names say what the direction is, so Quiet, Editorial, Dense, never Option A.

This step is done when no two variants share a position and you can state each one's axis in a phrase.

4. Build it into the real page

Host the variants on the page that will actually contain the piece, with the real chrome, the real neighbours and realistic data.

Select with a URL search param such as ?__variant=quiet, so every variant is a link you can send someone. A floating control sets it; picker.md holds the spec.

Render one variant at a time, full size. Thumbnails distort spacing and scale, and spacing is usually the thing you are choosing between.

Variant files may import production components. Only the hosting page imports a variant, and nothing else imports from the harness.

Where no page can host it, build one self-contained HTML file and keep the same picker.

Give every variant real content: product-shaped copy, plausible names and the number of items the page will really carry. Lorem ipsum and three rows make every structure look good.

5. Present the tradeoffs and stop

Load the page once in a browser already at hand and flip through every variant. Each one renders, each interaction responds and the console is clean. With no browser at hand, say so and hand the URL over for the user to check.

Then hand the decision over:

VariantAxis positionRight whenCosts
QuietLowest visual weightThe page is used dailyLeast memorable
EditorialLargest type, most spaceThe moment deserves weightEats vertical space

Say where the picker is running, which key flips it and which width you judged at. The answer can change between 375px and 1440px.

Never mark a favourite in the table. Asked directly, answer from how often the piece is seen and from the product's personality, not from which one you enjoyed building.

6. Promote one, delete the rest

On a choice, build that variant properly where it belongs, following the project's own conventions. Then delete the other variants, the picker and the guarded import. Search for the variant names and the __variant param, and check the diff leaves nothing of the harness behind.

Asked for another round instead, keep the harness and run Name the axis before writing code again, taking new positions around the direction you leaned toward.

Before you finish

MistakeFix
Variants differ only in accent color or copyMove one to a different position on the primary axis, or cut it
Every axis varies at onceVary one; let the rest follow from it
Judged on a blank routeHost them on the page that will contain the piece
Lorem ipsum, three rows, "Jane Doe"Real copy and the item count the page will really carry
The boldest variant skips keyboard or focusClear the floor or drop the direction
A favourite marked in the tableState each variant's cost and let the user choose
Picker restyled with the project's tokensKeep it visibly outside the design system
Harness left behind after promotionDelete it and search for the names and the param

Individual skills in this repo

This repo contains 12 individual skills — each has its own dedicated page.

LIKELION-CAPSULE/Landing_Page

Reviews and fixes keyboard and focus behavior, ARIA, accessible names, forms, screen-reader announcements, motion and zoom in your project against WCAG 2.2.

LIKELION-CAPSULE/Landing_Page

Helps you build and check a color system for your project. It generates palettes, names semantic tokens, converts between formats and measures contrast.

LIKELION-CAPSULE/Landing_Page

Combines all of the `better-*` skills into a single review across accessibility, layout, writing, typography, color and UI polish.

LIKELION-CAPSULE/Landing_Page

Helps with grouping, alignment, reading order, responsive structure and room for translated text, so a layout holds up when it is resized, translated or mirrored.

LIKELION-CAPSULE/Landing_Page

Sets and reviews how text renders in your product, from the type scale and spacing to font features, wrapping, truncation and punctuation.

LIKELION-CAPSULE/Landing_Page

Polishes the surfaces, icons and motion in your project with exact values for border radius, optical alignment, shadows, icon states and animation.

LIKELION-CAPSULE/Landing_Page

Writes and reviews your interface copy, from labels and errors to empty states and confirmations, so it matches your product's voice and tells people what to do next.

LIKELION-CAPSULE/Landing_Page

Renders a component you choose under every scenario that can reach it on a temporary page and stress tests it.

LIKELION-CAPSULE/Landing_Page

Builds UI from a Figma file or a design image so it matches the design, using your project's existing tokens and components.

LIKELION-CAPSULE/Landing_Page

Explains how a website, a visual effect or an animation was built, from a live URL or a screenshot.

LIKELION-CAPSULE/Landing_Page

Reviews a branch, pull request or uncommitted change for the interface problems it introduced or regressed, across accessibility, layout, writing, typography, color and UI.

LIKELION-CAPSULE/Landing_Page

Renders every state of a component you choose on a throwaway page, with mock data and a switcher, so you can work on each state.

相關技能