build-planetscale-landing-pages

어떤 스킬인가요?

Primary design skill for technical marketing pages explicitly requesting a PlanetScale-inspired or document-like visual language: monospace typography, editorial copy, stark surfaces, ruled grids, tables, proof-heavy sections, and restrained accent color. Use for developer-tool, infrastructure, database, API, open-source, technical SaaS, launch, and pricing pages when that specific direction is wanted. For broader plain infrastructure UI, dashboards, docs, or design review without this landing-page brief, use plain-design-engineer instead. Preserve the product's identity; do not copy PlanetScale branding or content.

설치 방법

웹에서 배포되는 스킬입니다. 원문 페이지의 설치 안내 ↗를 따라주세요.

스킬 원문 파일

interface:
  display_name: "Build PlanetScale-Style Pages"
  short_description: "PlanetScale-inspired technical landing pages"
  default_prompt: "Use $build-planetscale-landing-pages to design and implement a technical landing page with a precise, document-like visual system."

# Implementation and QA

## Implementation workflow

1. Identify the route entry, layout shell, component primitives, global styles, font loading, and breakpoint system.
2. Inventory existing public copy and product evidence before rewriting.
3. Sketch the section order using plain text.
4. Define or map a minimal token set: page, surface, text, muted, rule, link, action, shell width, type scale, and spacing.
5. Build semantic structure first: header, nav, main, sections, tables/lists/figures, and footer.
6. Add the shared shell and rule system.
7. Add responsive behavior before visual polish.
8. Add only small interaction states after the static hierarchy works.
9. Render, compare, and tighten.

Preserve the target project's framework. Do not introduce a new UI library just to produce borders, grids, or typography.

## Component boundary

Extract a component when it repeats, owns behavior, or encodes a stable content model. Useful boundaries include:

- `SiteHeader`
- `AnnouncementBar`
- `EditorialSection`
- `ProofTable`
- `CustomerGrid`
- `Quote`
- `RuledFooter`

Avoid wrappers such as `Card`, `SectionCard`, and `FeatureCard` when they add only a rounded rectangle.

## Semantic recipes

### Ruled grid without doubled borders

```css
.ruled-grid {
  display: grid;
  border-block-start: 1px solid var(--rule);
  border-inline-start: 1px solid var(--rule);
}

.ruled-grid > * {
  border-inline-end: 1px solid var(--rule);
  border-block-end: 1px solid var(--rule);
}
```

### Mobile-safe table

```css
.table-scroll {
  overflow-x: auto;
  overscroll-behavior-inline: contain;
  scrollbar-gutter: stable;
}

.table-scroll table {
  min-width: 44rem;
  width: 100%;
  border-collapse: collapse;
}
```

Wrap the region with an accessible label when the table's caption is not sufficient.

### Crisp focus

```css
:where(a, button, input, select, textarea):focus-visible {
  outline: 2px solid var(--link);
  outline-offset: 3px;
}
```

Never remove focus outlines without a replacement.

## Copy rules

- Lead with a product truth, not a mood.
- Name the user, workload, or constraint.
- Prefer verbs such as deploy, inspect, route, query, migrate, recover, and measure.
- Pair every large claim with proof nearby.
- Use exact units and conditions for benchmarks.
- Explain unfamiliar technical terms once.
- Keep CTAs direct: `Read the docs`, `View benchmarks`, `Start a project`, `See pricing`.

Reject copy such as:

- “Revolutionize your workflow.”
- “Unlock limitless possibilities.”
- “The future of innovation is here.”
- “Seamlessly supercharge your stack.”

## Visual QA

Render at minimum:

- `1440x1000` desktop
- `1024x768` compact desktop/tablet
- `390x844` mobile

Check:

- The first viewport states the product and shows or leads directly to proof.
- Major left edges align.
- Body copy does not become an unreadably wide wall.
- Navigation does not wrap.
- Rules meet cleanly with no accidental 2px seams.
- Dashed dividers are structural, not visual noise.
- Tables and proof grids remain usable on mobile.
- Logos keep aspect ratio and accessible names.
- No horizontal page overflow exists.
- Link, muted text, borders, and focus states pass contrast requirements.
- Text remains usable at 200% zoom.
- Reduced-motion mode removes nonessential animation.

## Functional QA

- Exercise all navigation, CTA, menu, pricing, and external links.
- Verify heading order and one primary page heading.
- Verify landmarks and skip navigation.
- Verify keyboard-only use, menu dismissal, and focus return.
- Verify images have meaningful alternatives or are intentionally decorative.
- Verify analytics and forms still work after a redesign.
- Run formatter, lint, typecheck, tests, and production build at the project's normal scope.

## Design review output

When reviewing without editing, report:

1. The three highest-impact mismatches.
2. The specific component or section affected.
3. Why it weakens the technical-document system.
4. A concrete change with token, spacing, or layout guidance.
5. Any claim, accessibility, or responsive risk.

Do not reduce the review to “make it more minimal.” Name the broken relationship.

# Visual Language

Use these values as a calibration range, not a mandatory theme. Map them into the target project's tokens.

## Palette

### Dark

```css
--page: #0d0d0d;
--surface: #111111;
--text: #e7e7e7;
--muted: #9a9a9a;
--rule: #727272;
--rule-strong: #b8b8b8;
--link: #00a9ef;
--action: #ff4f00;
```

### Light

```css
--page: #fbfbfa;
--surface: #ffffff;
--text: #171717;
--muted: #6f6f6f;
--rule: #c9c9c6;
--rule-strong: #8e8e8a;
--link: #4f7fc8;
--action: #ee4b16;
```

Use one link accent consistently. Reserve the action color for the main CTA or a small section marker. Check WCAG contrast after mapping colors.

## Type

Start with the project's licensed mono. If none exists:

```css
font-family:
  ui-monospace,
  "SFMono-Regular",
  "Cascadia Code",
  "Roboto Mono",
  Menlo,
  Consolas,
  monospace;
```

Suggested scale:

```css
--text-xs: clamp(0.75rem, 0.72rem + 0.12vw, 0.8125rem);
--text-sm: clamp(0.875rem, 0.83rem + 0.18vw, 1rem);
--text-body: clamp(1rem, 0.94rem + 0.24vw, 1.1875rem);
--text-lead: clamp(1.125rem, 1rem + 0.42vw, 1.5rem);
--text-title: clamp(1.5rem, 1.15rem + 1.25vw, 2.75rem);
```

- Set body line height to `1.55-1.75`.
- Set headings to `1.1-1.3`.
- Use `600-700` for claims and section labels; keep body text at `400`.
- Use underlines for linked or navigational headings.
- Avoid all-caps paragraphs. Short labels may use caps only when the brand already does.
- Keep line length around `60-90ch`; broad technical sections can reach `100ch`.

## Grid and spacing

```css
.shell {
  width: min(calc(100% - 2rem), 88rem);
  margin-inline: auto;
}

.section {
  padding-block: clamp(3rem, 7vw, 7rem);
}

.prose {
  max-width: 88ch;
}
```

- Use `16-32px` mobile gutters and `32-64px` desktop gutters.
- Anchor all major content to one shell.
- Repeat a small spacing set such as `8, 12, 16, 24, 32, 48, 72, 112`.
- Prefer large gaps between sections and compact gaps inside related copy.
- Do not center every section. Left alignment is the default.

## Rules

- Use `1px solid` rules for grids, tables, navigation divisions, and customer matrices.
- Use `1px dashed` or a spaced dotted rule between editorial chapters.
- Keep border color quiet enough that content leads.
- Avoid doubled grid borders with shared parent borders or negative margins.
- On high-density displays, verify dashed rules remain visible without becoming bright decoration.

Example chapter divider:

```css
.chapter + .chapter {
  border-top: 1px dashed var(--rule-strong);
}
```

## Navigation

- Keep the nav one row on desktop.
- Separate groups with thin vertical rules.
- Use a compact logo, then primary links, then account and CTA actions.
- Make the primary CTA rectangular with little or no radius.
- Hide lower-priority links behind an accessible menu on narrow screens.
- Give every control a minimum `44px` touch target even when the visible treatment is compact.

## Opening section

Prefer a compact claim over a giant promotional H1:

```text
Infrastructure that survives the boring failures.

Run production workloads across regions with automatic failover,
observable deploys, and no proprietary runtime.

Read the architecture →
```

Use a short colored rule, caret, or bracket as the only decorative marker. Follow the opening with concrete proof.

## Product table

Use a semantic `<table>` for products, pricing, benchmark results, or plan comparisons.

- Keep 2-4 meaningful columns.
- Use rules rather than tinted cards.
- Make the entire row scannable; align numeric content.
- On mobile, allow horizontal scroll with a visible edge cue or convert each row into labeled fields.

## Customer or ecosystem matrix

- Use CSS grid with shared 1px borders.
- Normalize logo boxes, not logo artwork: preserve each mark's aspect ratio.
- Use authorized SVGs or text names. Never extract marks from the reference screenshot.
- Keep each cell generous and visually equal.
- Prefer 5 columns on wide layouts, 3 around tablet, and 2 on mobile.
- Include accessible names for every logo.

## Editorial chapters

Use chapters for reliability, security, performance, cost, migration, or architecture:

- Underlined section label.
- Two or three evidence-rich paragraphs.
- Linked bullet list using `*`, `→`, or `+` markers.
- Optional quote with a single left rule and muted attribution.
- Dashed divider before the next chapter.

Do not turn each chapter into a rounded card.

## Footer

Build the main footer as a bordered grid:

- 4-6 link columns on desktop.
- Underlined bold group headings.
- Compact vertical link rhythm.
- A legal row inside the enclosing border.
- A separate social row below.
- On mobile, use 1-2 columns and preserve the dividers.

Keep legal text muted but readable. Use the current year dynamically where the framework supports it.

## Light and dark selection

Choose one strong default based on product identity:

- Use light for documentation-forward, open, or minimal products.
- Use dark for infrastructure, terminal-adjacent, or high-contrast technical products when it fits the brand.
- Support both only if the existing product already has a reliable theme system or the user asks for it.

Do not invert the screenshots mechanically. Re-check all border, link, muted text, logo, and focus colors in the chosen theme.

---
name: build-planetscale-landing-pages
description: "Primary design skill for technical marketing pages explicitly requesting a PlanetScale-inspired or document-like visual language: monospace typography, editorial copy, stark surfaces, ruled grids, tables, proof-heavy sections, and restrained accent color. Use for developer-tool, infrastructure, database, API, open-source, technical SaaS, launch, and pricing pages when that specific direction is wanted. For broader plain infrastructure UI, dashboards, docs, or design review without this landing-page brief, use plain-design-engineer instead. Preserve the product's identity; do not copy PlanetScale branding or content."
---

# Build PlanetScale Landing Pages

Create technical marketing pages that feel like a confident product document: direct, structured, information-dense, and almost unstyled at first glance. Use the reference grammar, not the PlanetScale brand.

## Start from the product

Before changing code:

1. Inspect the current route, component system, tokens, fonts, icon library, framework, and responsive conventions.
2. Gather real product evidence: features, commands, API calls, schemas, benchmarks, customers, reliability claims, pricing, and screenshots.
3. Decide the page's one primary claim and one primary action.
4. Preserve working behavior, accessibility, routing, analytics, and existing brand assets.
5. Choose light or dark from the product's identity. Do not force dark mode merely because the references include it.

Do not invent customer logos, metrics, quotes, compliance claims, or benchmarks. Use clearly marked placeholders only when the user asks for a mockup.

## Compose the page

Build a coherent editorial sequence rather than a stack of interchangeable cards:

1. Optional one-line announcement strip.
2. Compact navigation divided by thin vertical rules.
3. Claim-led opening with a short technical explanation and direct text or rectangular CTA.
4. Concrete proof near the fold: product table, code sample, benchmark, architecture diagram, or customer grid.
5. Long-form sections separated by dotted or dashed rules.
6. Trust section with authorized customer marks, a real quote, or measurable operating facts.
7. Bordered multi-column footer with legal and social rows.

Use only the sections supported by the product. A short honest page is stronger than a long generic one.

## Apply the visual grammar

- Use one deliberate monospace family for most or all visible type. Prefer an existing project font; otherwise use a high-quality local/system mono stack.
- Use compact bold headings, readable body copy, and generous line height. Keep headings blunt rather than oversized.
- Set the page on a near-black or near-white canvas. Use one main accent for links and one optional CTA accent.
- Create hierarchy with type weight, whitespace, underlines, and 1px rules.
- Align navigation, copy, tables, proof grids, and footer columns to a shared content grid.
- Keep corners square or nearly square. Use shadows only for functional overlays.
- Let empty space create rhythm, but keep the content column broad enough to feel infrastructural rather than blog-like.
- Use real tables when the information is tabular. Use CSS grid for visual matrices and footer navigation.
- Make hover and focus states crisp: underline, foreground shift, background inversion, or a 1px outline.
- Keep motion minimal and functional. Prefer a quick reveal, row highlight, or underline transition; support reduced motion.

Read [references/visual-language.md](references/visual-language.md) for exact tokens, spacing, responsive behavior, and component recipes.

## Use the screenshots deliberately

Inspect the images in `assets/` when the task needs close visual calibration:

- `reference-light-page.png`: light canvas, navigation, opening copy, product table, and long-form rhythm.
- `reference-logo-grid.png`: dark navigation, accent usage, technical copy, and bordered customer matrix.
- `reference-editorial-sections.png`: section rules, linked bullet lists, quote treatment, and long-form density.
- `reference-footer.png`: ruled footer columns, legal row, and social links.

Treat the screenshots as study material. Do not ship their logos, names, exact copy, or trademarked visual assets.

## Adapt instead of cloning

Translate the system through the target brand:

- Replace PlanetScale orange/cyan with the product's strongest existing accent.
- Replace database-specific artifacts with evidence from the actual product.
- Keep an existing logo and recognizable brand type where appropriate.
- Use the project's components and tokens when they can express the system cleanly.
- Preserve useful UI from an existing page; restyle or reorder only where it improves the hierarchy.

## Responsive rules

- Collapse navigation into an accessible menu before links wrap or crowd.
- Change wide proof grids from 5 columns to 2, then 1 only when the content requires it.
- Turn comparison tables into horizontal scroll regions or labeled stacked rows; do not silently remove columns.
- Stack footer columns while preserving rules and headings.
- Reduce outer gutters and section spacing, not body readability.
- Keep at least one concrete proof artifact visible in the first mobile viewport or immediately after it.

## Avoid the wrong look

Do not add:

- Gradient text, ambient glows, glass panels, blobs, or decorative 3D objects.
- Pill-shaped navigation and rounded cards around every paragraph.
- A huge centered slogan followed by three generic feature cards.
- Emoji used as product icons.
- Fake terminal windows, fake metrics, or fabricated social proof.
- Decorative noise, scanlines, or “retro terminal” effects that harm reading.
- Monospace text at tiny sizes or low contrast.
- Dashed borders on every element; reserve them for section structure, tables, and footer grids.
- A direct PlanetScale clone with substituted nouns.

## Implement and verify

Read [references/implementation-and-qa.md](references/implementation-and-qa.md) before editing a production codebase or performing a design review.

Finish by:

1. Run the project's formatter, typecheck, tests, and build at the appropriate scope.
2. Render the page at desktop and mobile sizes.
3. Compare hierarchy, grid alignment, density, wrapping, and border continuity against the intended system.
4. Test keyboard navigation, visible focus, landmarks, heading order, contrast, and reduced motion.
5. Remove placeholders and verify every public claim and link.

In the final response, state what changed, what real product evidence was used, and what validation ran.