Instruction manual

elayadesign/ai-design-skills instruction manual

Portable Markdown skill collection for AI coding tools, currently evidenced by one comprehensive landing-page-design skill covering intake, conversion structure and copy, SEO/AEO, visual rules, interaction states, accessibility, and delivery checks.

1. Repository purpose, scope, and Claude Code classification

AI Design Skills manual

`elayadesign/ai-design-skills` is a public MIT licensed collection of Markdown based design skills for AI coding tools. The supplied repository contains one documented skill: `landing-page-design`. It covers intake, information architecture, conversion copy, SEO and AEO, visual tokens, motion, interaction states, accessibility, and launch details for landing pages and related web interfaces.

**Claude Code classification:** **context injection**, installed as a **Claude extension**, with **low setup effort**. The evidence supports this classification because the repository tells users to copy a self contained skill folder into `.claude/skills/`; Claude Code then reads `SKILL.md` as reusable guidance. It does not document an MCP server, hook, proxy, executable, subagent, or external runtime. The same Markdown guidance can also be placed in Cursor rules, Codex `AGENTS.md`, Windsurf `.windsurfrules`, Cline `.clinerules`, a generic system prompt, or a Claude.ai Project.

The skill’s declared scope is broad: new landing pages, marketing sites, web UI, page sections, components, dashboards, prototypes, edits, reviews, styling, and copy. For a landing page, its central model is **one offer → one audience → one primary action**. It distinguishes this from a homepage, which may serve several intents. Part A determines the message and page structure; Part B supplies the visual system. Complete Part A before applying Part B.

For an existing site redesign, the file points to the separate `redesign-existing-projects` companion repository. That companion is not included here, so this manual does not document its operation.

2. Installation and customization

Install the available skill

The documented Claude Code installation copies the complete `landing-page-design` folder into the current project’s `.claude/skills` directory:

mkdir -p .claude/skills
git clone https://github.com/elayadesign/ai-design-skills.git /tmp/ai-design-skills
cp -r /tmp/ai-design-skills/skills/landing-page-design .claude/skills/

After installation, ask Claude Code in plain language for landing page, marketing UI, component, prototype, copy, styling, or design review work. No separate executable or initialization command is documented.

For Cursor, install the skill as a project rule:

mkdir -p .cursor/rules
curl -o .cursor/rules/landing-page-design.md \
  https://raw.githubusercontent.com/elayadesign/ai-design-skills/main/skills/landing-page-design/SKILL.md

The README also permits pasting the file into **Settings → Rules for AI**. For Codex, copy the contents of `SKILL.md` into `AGENTS.md`; for Windsurf, use `.windsurfrules`; for Cline, use `.clinerules`. A generic tool may receive it in the system prompt. In Claude.ai without a terminal, download `SKILL.md`, upload it to a Project or attach it to a chat, and ask the model to follow it.

Each skill is self contained. The repository says its design values—fonts, colors, spacing, and motion—are grouped near the bottom of the skill file. To customize those values, fork the repository and edit that visual section; the rest of the workflow then refers back to the revised rules. The repository is MIT licensed, and its README permits use, modification, forking, shipping, and selling work built with it without attribution.

3. Intake, assumptions, output order, and iterative build process

Start with one batch of intake questions

Collect only missing information, and ask for it in one batch. Establish the single primary action, exact offer, and conversion event. Identify the ideal customer, their problem, their three leading objections, traffic source, and what they already know. Request available logos, testimonials, metrics, case studies, screenshots, video, GIFs, guarantees, refund terms, and cancellation terms. Finally, establish voice, design direction, and whether mobile is the priority.

If the user cannot answer, make a reasonable assumption, state it in one line, and continue rather than blocking the build.

Return planning material before code

For a new landing page, return these artifacts in this exact order:

  1. Page outline and section order
  2. Hero headline, subheadline, CTA, and proof line
  3. Three to five outcome driven benefits
  4. A three step “How it works” sequence
  5. Six to twelve FAQ questions with answers
  6. SEO or AEO advice, including index status and, when indexed, a title and meta description
  7. Layout recommendation A, B, C, or D, with the reason

Then build incrementally in this order: hero, benefits, how it works, proof, FAQ, and final CTA. Do not regenerate the entire page for every revision; section based iteration keeps changes controlled and reviewable.

The required overall structure begins above the fold with headline, explanatory subheadline, one primary CTA, one proof signal, and a hero visual. The middle presents problem to solution, three to five benefits, three steps, and social proof. The bottom handles objections with FAQ, risk reversal, and a final CTA identical to the first. A separate tagline reveal from the visual system must appear in the middle, usually after the hero or benefits.

4. Layout, conversion copy, proof, and search behavior

Choose the page architecture deliberately

Use **A. Classic hero plus sections** when a screenshot makes the product understandable. Use **B. Long form story** when visitors need education or skepticism must be overcome. Use **C. Minimal conversion page** for high intent traffic or a short offer such as a waitlist or download. Use **D. Comparison page** when search intent includes alternatives such as “X vs Y” or “best for.” State the selected type and the reason.

Match the hero’s promise and visual tone to the traffic source; ad traffic should see language that mirrors the ad. Keep one primary CTA above the fold. Lead with outcomes rather than feature inventories, and place proof beside the claim it supports. Select at least one risk reducer: free trial, free plan, no credit card, cancel anytime, or money back guarantee. Move FAQ content earlier when the offer has high friction.

Specific copy is preferred over vague language. The documented contrast is:

Supported headline formulas are “{Outcome} without {pain},” “The {category} for {audience},” and “Ship {result} in {time}.” A subheadline should use one or two sentences to clarify the product and audience. CTAs combine a verb with the received value: “Start free trial,” “Book a demo,” or “Get the checklist,” never “Learn more” or “Submit.” Benefit bullets put the outcome first, for example: **Faster iteration** — generate three layout variants in one click.

Evergreen pages should be indexed when search intent matches the offer. Add title, meta description, relevant internal links, plain question and answer FAQ content, and FAQ schema when appropriate. Ad only or highly time bound campaign pages should use `noindex` or a non indexed path.

5. Typography, spacing, radius, surfaces, hero, and icons

Apply the fixed visual system

Use one typeface per site: Geist, Manrope, Geist Mono, or Poppins. Geist Mono may accompany the primary face only for functional code, data, or numeric UI. Do not use Inter, Roboto, Arial, Open Sans, Helvetica, italics, or weight 900. Use sentence case. Rewrite copy to avoid hyphens inside headings, labels, and body text. Prevent last line single words with `text-wrap: balance` on headings and `text-wrap: pretty` on body copy.

Font sizes must use Tailwind’s default steps, from `text-xs` through `text-9xl`; arbitrary pixel or rem sizes are not retained. If an existing value falls between steps, select the closest lower step together with that step’s line height. Do not then override its line height independently. Main buttons use `text-base` semibold; smaller header buttons use `text-sm` semibold.

Spacing is limited to 0, 2, 4, 8, 12, 16, 24, 32, 40, 48, 64, 80, and 96px. Main button padding is 8px vertically and 12px horizontally. Radius values must come from Tailwind. For nested shapes separated by less than 32px, calculate `inner radius = outer radius − gap`; apply the result only when it exceeds 2px. The documented example is a 16px `rounded-2xl` card with 8px padding containing an 8px `rounded-lg` element.

Cards receive a full border or none, never a one sided border. Backgrounds are flat, without gradients. Dark surfaces may use only `#000000`, `#181818`, `#1F1F1F`, `#272727`, `#313131`, or `#131209`.

Hero heading text is the sole gradient exception: white to `#9B9B9B` in dark mode, or black to `#666666` in light mode. Cap heading and subheading width at 680px and insert line breaks only where the thought naturally breaks. Use Phosphor, Solar, or Iconamoon icons; do not use Material Icons or Material Symbols.

6. Motion, navigation, viewport reveals, and the mandatory tagline

Use physical, custom easing

Do not use default transitions. The documented Tailwind transition is:

transition-all duration-700 ease-[cubic-bezier(0.32,0.72,0,1)]

A fluid island navbar begins as a floating glass pill with `mt-6`, `mx-auto`, `w-max`, and `rounded-full`. When opened, hamburger lines rotate and translate into a true X using `rotate-45` and `-rotate-45`; they must not merely vanish. Expand the menu into a screen filling glass overlay using `backdrop-blur-3xl bg-black/80` or `bg-white/80`. Reveal menu links from `translate-y-12 opacity-0` to `translate-y-0 opacity-100`, staggering items with `delay-100`, `delay-150`, `delay-200`, and subsequent delays.

Viewport content begins at `translate-y-16 blur-md opacity-0` and settles at `translate-y-0 blur-0 opacity-100` over at least 800ms. For JavaScript driven reveals, use `IntersectionObserver` or Framer Motion’s `whileInView`. Do not use an unthrottled scroll event handler.

Every landing page requires a standalone tagline reveal later than the hero. Write at least two lines that state the core benefit in the established voice, not a generic heading. Set it between `text-4xl` and `text-6xl`, depending on line count, and use the same meaningful line breaking and maximum width treatment as the hero.

Initially render each word at roughly 25 to 35 percent opacity of the theme’s base text color. As the section enters view, activate words individually in reading order when they cross a trigger line, using the custom easing curve. `IntersectionObserver` per word is documented; alternatively, use one scroll listener throttled through `requestAnimationFrame`. The entire block must not switch at once, and a raw unthrottled `window.addEventListener('scroll')` is prohibited.

7. Realistic content and complete interaction states

Replace generated looking filler

Write credible draft content instead of Lorem Ipsum. Do not use “John Doe,” “Acme Corp,” “Nexus,” or “SmartFlow.” Use varied, realistic names and contextual brand names. Avoid suspiciously round invented numbers such as `99.99%`, `50%`, and `$100.00`; the skill’s organic examples are `47.2%`, `$99.00`, and `+1 (312) 847-1928`. Give each person a unique avatar and vary blog publication dates.

Avoid the listed AI clichés: “Elevate,” “Seamless,” “Unleash,” “Next Gen,” “Game changer,” “Delve,” “Tapestry,” and “In the world of.” Prefer active voice. Success messages do not use exclamation marks, and errors do not say “Oops!” The documented direct error copy is: “Connection failed. Please try again.”

Every interactive element must include six state categories. **Hover** changes background, scale, or position slightly. **Active** uses `scale(0.98)` or `translateY(1px)` for physical feedback. **Focus** includes a visible focus ring. **Loading** uses skeletons shaped like the eventual layout rather than circular spinners. **Empty** provides a composed getting started view rather than a blank panel. **Error** is inline and specific; do not use `window.alert()`.

Eliminate dead controls. A link targeting `#` must be connected to a destination or presented as visually disabled. Navigation must mark the current page. These requirements apply not just to full landing pages but also to components, dashboards, prototypes, reviews, and edits within the skill’s declared scope.

8. Shipping requirements, review checklist, and known boundaries

Complete the production details

Before shipping, include privacy policy and terms links in the footer, a branded 404 page, client side validation for email format and required fields, a keyboard accessible skip to content link, cookie consent where jurisdiction requires it, and a branded favicon. Add `<title>`, a meta description, `og:image`, and social sharing tags. Every meaningful image needs alt text. Structure pages with semantic elements such as `<nav>`, `<main>`, `<article>`, `<aside>`, and `<section>`, and provide a route back from every page.

Review strategy first: confirm one offer, one audience, and one action; remove competing above fold CTAs; replace vague claims with specific outcomes; include risk reversal; keep proof beside its claim; and verify that layout A, B, C, or D was intentionally selected. Check for the documented pitfalls: too many CTAs, a vague value proposition, feature lists without outcomes, proof buried at the bottom, unreadable mobile layouts, and no obvious next step.

Review visuals next: one approved typeface, no italics or ultra bold text, no copy hyphens or orphaned words, only Tailwind type steps, only allowed spacing, correct nested radii, no one sided card border, and no background gradient. Confirm the hero’s 680px caps, meaningful breaks, approved icon library, custom cubic bezier transitions, viewport observation, and a two line word by word tagline reveal.

Finally, verify realistic copy, all six interaction states, valid links, active navigation, legal and metadata details, validation, favicon, and alt text. The repository documents guidance rather than automated enforcement: it supplies no linter, test command, build system, framework integration, deployment process, or performance benchmark. Implementation and final review therefore remain the responsibility of the host coding tool and the user. Explicit user instructions override a conflicting skill rule; otherwise the skill says its rules take precedence over framework defaults.