# Use Case Landing > Create or improve use-case landing pages under src/pages/use-cases/ from the UseCaseStory module. - Skill: `microlinkhq/use-case-landing` (Agent Skill, multi-file: 4 files) - Install (CLI): `npx skillmds@latest add microlinkhq/use-case-landing` - Raw SKILL.md: https://api.skillmd.com/api/skills/microlinkhq/use-case-landing/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: microlinkhq (https://skillmd.com/u/microlinkhq) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/microlinkhq/use-case-landing --- # Use Case Landing Pages Build an individual use-case page at `src/pages/use-cases/.js` and register it so it shows up on the `/use-cases` listing. A use case is **not** a testimonial and **not** a competitor comparison. It is a practical, copy-pasteable recipe for getting more out of Microlink — usually **paired with another API** (Magnific, an LLM, a storage provider, etc.). The first one shipped is `src/pages/use-cases/upscale-extracted-images.js` (Microlink + Magnific). Mirror it. The goal is a repo-native page that: - reuses the `UseCaseStory` module so it stays visually identical to the listing and to other use-case pages - is named after the **topic**, never the partner brand - shows **real, verified** partner API code (no invented field names) - uses the **real** partner logo, not a placeholder - stays honest about *when the use case makes sense and when it doesn't* ## Architecture — read this first Customer stories and use cases now share the `/use-cases` route and folder. A use case is still a recipe (no testimonial); a customer story is a testimonial-led page built with the separate `customer-story` skill. They render together on the one listing — a "Customer stories" grid followed by a "Use cases" grid. The old `/customers` URLs 301-redirect to `/use-cases`. - **Shared module:** `src/components/patterns/UseCaseStory/` is a barrel that re-exports the accent-agnostic primitives from `CustomerStory` (`Section`, `SectionInner`, `Caption`, `Figure`, `FigureImage`, `DashedGridOverlay`, `Eyebrow`, `StoryTag`, `CtaSection`, `WhyCard`) plus the use-case-only pieces (`ACCENT`, `USE_CASES`, `MoreUseCases`). **Import everything from `components/patterns/UseCaseStory`. Never redefine these locally. Never edit the `CustomerStory` files.** - **The listing is data-driven.** `src/pages/use-cases/index.js` renders the customer hero + logo bar + "Customer stories" grid (from `CUSTOMERS`), then maps over the `USE_CASES` registry for the "Use cases" grid. Adding a use case = appending one registry entry + creating one page file. **You do not edit `index.js` per use case.** - **`MoreUseCases`** self-omits when there are fewer than 2 entries, so it renders nothing until a second use case exists. That is expected. ## Read First Before planning or editing, read in order: 1. `src/components/patterns/UseCaseStory/index.js` — barrel exports (what you may import). 2. `src/pages/use-cases/upscale-extracted-images.js` — the canonical reference page. Mirror it. 3. `src/pages/use-cases/index.js` — the unified listing (customer-stories grid + use-cases grid) to see which `USE_CASES` fields the use-case grid consumes. 4. `.cursor/skills/use-case-landing/references/page-template.md` — the page template with `{{TOKEN}}` placeholders. 5. `.cursor/skills/use-case-landing/references/module-and-registry.md` — the `UseCaseStory` module map + the `USE_CASES` registry shape. 6. `.cursor/skills/use-case-landing/references/partner-api-verification.md` — how to verify a partner API before writing any code block. 7. `AGENTS.md` — repo conventions (`theme({...})`, import style). ## Naming — topic, not brand The slug and page must describe **what the developer accomplishes**, never the partner's brand. - Good: `upscale-extracted-images`, `summarize-any-url`, `archive-pages-to-storage`. - Bad: `magnific`, `openai`, `s3`. The partner brand still appears in the **content** (the combo name `Microlink + `, the logo, the inline link) and in the **asset filename** (`/images/use-cases/.svg`) — just not in the slug, the route, the component name, or the `Head` title. Compute the slug from the topic, then verify no collision in `src/pages/use-cases/`. ## Core Rules Non-negotiable: - **Accent is always blue.** Import `ACCENT` from the module; never define it locally, never pass a different accent. `CtaSection` hardcodes `colors.link` for its background, so a different accent would look broken. - **No testimonial, no quote, no person.** Use cases are recipes, not endorsements. There is no `Testimonial` on these pages. - **Code blocks, not a flow diagram.** Replace the customer-story `FlowDiagram` with `CodeEditor` blocks (see template). Snippets must reflect the **real** partner API. - **Verify the partner API before writing code.** Never invent endpoints, auth headers, request fields, response shapes, or status values. Follow `references/partner-api-verification.md`. - **Use the real partner logo.** Never ship a hand-drawn placeholder. See "Partner logo" below. - **Set real image dimensions** (`width`/`height`) on `FigureImage` to avoid layout shift. - **Inline partner link goes in the top "What it does" paragraph** (anchor text = the partner name), using the `InlineLink` styled anchor with `target='_blank' rel='noopener'` — not the repo `Link` component. - **"Learn more" lists Microlink links first, partner links after.** Internal Microlink links (e.g. `/metadata`, `/docs`) stay in-tab; external partner links open in a new tab. The `ResourceLink` helper handles this via `href.startsWith('http')`. - **Never run Prettier or any formatter.** Lint only with `npx standard src/pages/use-cases/.js`. - **Never add a `TODO` to production copy.** If a fact is important but unverified, stop and ask. ## Partner logo Get the genuine brand mark, then clean it: 1. Fetch the partner homepage and read the `` href (brands usually host an SVG favicon on their CDN, e.g. `media..com/.../favicon.svg`). 2. Download that SVG. 3. Strip any generator `` block; keep only the real ``/`` shapes. Add `role="img" aria-label=""`. 4. Save to `static/images/use-cases/.svg` and reference it as `/images/use-cases/.svg`. If no SVG mark exists, ask the user for the asset instead of inventing one. ## Section order (individual page) ```text Hero (partner logo + "Microlink + ", h1 = topic, intro paragraph, ArrowLink CTA to a Microlink product) WhatItDoes (FigureImage screenshot, Eyebrow "What it does", h2, paragraphs WITH the inline partner link) WhyItWorks (Eyebrow "Why it works", h2, lead paragraph, then 3× WhyCard each followed by a prose UseCaseItem — box/text/box/text/box/text) HowItWorks (Eyebrow "How it works", h2, intro, Figure with 1–2 CodeBlock components) LearnMore (Eyebrow "Learn more", h2 "Docs and resources", ResourceLink list: Microlink links first, partner links after) CtaSection (shared; headlinePrefix, headlineAccent, body, href to a Microlink product, label) MoreUseCases (shared; accent + currentSlug === this page's slug) ``` There is **no** `ThanksSection` (that is customer-story only). The individual page hero is left-aligned (logo + name). The **listing** hero is centered text — do not confuse the two. ## CTA routing The hero CTA, the bottom `CtaSection`, and the first "Learn more" link should point at the Microlink product the use case actually uses: - extracts the page's image / metadata → `/metadata` - screenshots / renders the page → `/screenshot` - PDF of the page → `/pdf` - link preview / oEmbed card → `/embed` The Magnific reference page uses `/metadata` because it extracts the main image. Pick the product that matches the recipe and confirm with the user. ## USE_CASES registry Append one entry to `src/components/patterns/UseCaseStory/use-cases.js`: ```js { slug: '', // NOT the brand. Matches the page filename. name: 'Microlink + ', // combo name shown in cards + page hero partner: '', // partner tool name, shown in the (hidden) logo bar partnerUrl: 'https://.com', // optional, handy reference blurb: '', icon: '/images/use-cases/.svg', category: ' + ' // e.g. 'Metadata + AI Upscaling' } ``` Fields consumed today: the use-cases grid uses `slug, name, blurb, icon, category`; `MoreUseCases` uses `slug, name, blurb, icon`. `partner`/`partnerUrl` are reference-only now — the partner brand still appears in the page content (combo name, logo, inline link), but the "Pairs well with…" logo bar that rendered `partner` was removed during unification. ## Listing layout The unified listing leads with the customer-story hero and the "Trusted by innovative companies" logo bar (both driven by `CUSTOMERS`), then the "Customer stories" grid, then the "Use cases" grid (driven by `USE_CASES`). The old use-case-only "Pairs well with the tools you already use" logo bar and its `SHOW_LOGO_BAR` flag were removed during unification — there is no logo bar to toggle anymore. Appending a `USE_CASES` entry surfaces it in the use-cases grid automatically. ## Footer & nav `/use-cases` is already linked from the footer's **Resources** column and the top-nav **Resources** menu (one-time, global). The old "Customers" footer link was removed in the unification. Individual use-case pages do **not** get their own footer or nav entries. ## Workflow Ask one question at a time, like the customer-story skill: 1. **Topic + partner** — derive a topic-based slug; verify no collision in `src/pages/use-cases/`. 2. **Partner URL + Microlink product used** — drives CTA routing and the Microlink "Learn more" links. WebFetch the partner homepage for positioning and the logo. 3. **Partner API verification** — if the page shows code, follow `references/partner-api-verification.md`. Confirm endpoint, auth header, request fields, response shape, status values, and the output field. Adjust the snippets to the real schema. 4. **Assets** — download + clean the real partner logo; get the screenshot (`/images/use-cases/.png`) and record its pixel dimensions for `FigureImage`. 5. **Content** — hero copy, "What it does" (with the inline partner link + an honest *when it makes sense / when it doesn't* angle woven through "Why it works"), the 1–2 code blocks, and the "Learn more" links. 6. **Registry** — append the entry to `use-cases.js`. 7. **Summary** — show every value and wait for explicit confirmation before writing. 8. **Write** — generate the page from `references/page-template.md`, replacing all `{{TOKENS}}`. ## Verification 1. `npx standard src/pages/use-cases/.js src/components/patterns/UseCaseStory/use-cases.js` — fix until clean. 2. Grep for `{{` — no placeholders left. 3. `node --check` the code snippets (write them to a temp `.mjs`) — confirm valid JS. 4. Confirm the section order matches the canonical list. 5. Confirm `MoreUseCases currentSlug` equals the page slug, and the registry slug matches the filename. 6. Confirm the partner logo file exists at `static/images/use-cases/.svg` and the screenshot exists with matching `width`/`height`. 7. Confirm the slug/route/component name/`Head` title contain **no** partner brand. ## Lint style notes - `standard` enforces `jsx-quotes` as prefer-single: use single quotes for JSX string attributes **unless** the string contains an apostrophe (then use double quotes). - The `CodeEditor` runs snippets through the repo's runtime `prettier` (no semicolons, single quotes) and through `template()` (a no-op unless the code literally contains `demolinks.`), so write valid JS and it renders fine. Never run a formatter on the source file yourself. - Never use `` — the repo's `css` transform throws on ``. Use `` or a styled component. ## Updating an existing use-case page Read the file, re-verify the partner API and pricing/positioning, fix inaccuracies first, then improve copy. Re-lint. Do not restructure without a reason.