[ukimsanov]

What

The docs take hyperframes.dev's look, and every colour on the page comes from the Studio app's palette (picked on 26 Oct from three options).

Light mode: hyperframes.dev's ground

• Every page sits on hyperframes.dev's beige light, a still of its WebGL ground, fixed so it stays put while text scrolls. It's served from static.heygen.ai.
• A frosted header, as on hyperframes.dev.
• Its ink #131109 for text and headings, its deep green #05563f for links, and its black pill for Download Studio. The pill replaces the cyan-to-green gradient.
• Heavy, tight TT Norms page titles with a light-weight description line.
• Cards, Note/Info/Tip callouts and code blocks are frosted cream. Warnings and Danger keep their colour.
• Every hairline (header bottom, sidebar edge, table rules, footer top and footer divider) is the palette's line, never a pale grey stripe on the beige. Footer links use the secondary ink.

Every other colour: the Studio app

• Greys: Mintlify's gray scale, used for text, borders, step circles, tabs and fills, is moved to the app's warm hue (oklch hue 70) at the same lightness steps. Gray-900 is the app's --ink. In light mode the middle steps are darker so small text passes on the beige.
• Article text and catalog pages: the typography plugin's cool greys and the catalog's own --ve-* greys use the same tokens.
• Code: the browser editor's syntax colours (packages/studio theme.css --color-code-*) in both modes. Mintlify's hosted build ignores a custom code theme, so the default themes stay (GitHub light, VS Code dark) and each of their colours is mapped by role to the editor's colour for that role (strings, keywords, functions and commands, constants, tags, comments). Code blocks and the fade under the copy button sit on the code token.

Dark mode: the Studio app's Night palette

• Warm paper #201e1c, Night cards, warm off-white ink, and the mint accent. It replaces Mintlify's neutral black.
• Body copy uses the app's second ink, brighter than Mintlify's grey-400.

Why

hyperframes.dev, the homepage and the Studio app share one look, but the docs used Mintlify's stock theme. A full inventory of rendered colours on 10 page types found about 70 distinct colours per mode outside the product's palette. They include a blue-tinted grey used 11,000 times, GitHub's syntax colours, white code blocks and a neutral-black dark mode. Someone moving from the site or the app to the docs lands somewhere that looks like a different product.

How we'll know: a side-by-side reads as one product, and docs visitors click Download Studio as often or more (PostHog docs-navbar source).

Related work

Separate from the content PRs (#6378–#6383). It touches only colours: docs.json, custom.css, one catalog chip in catalog-gallery.css, and one tile border in docs-video.jsx. It can merge in any order.

How

• Sources:
  • hyperframes.dev's stylesheet (studioRedesign.css, --sr-*) for the ground, glass, ink, pill and links;
  • the Studio app's packages/desktop/src/index.css (default and data-chrome="night") for greys, surfaces and dark mode;
  • the browser editor's theme.css for code.
• Mostly variables: existing --hf-* tokens take the new values, and Mintlify's own --gray-* and --tw-prose-* variables point at them. Two snippets that fall back to neutral greys read --border-color and --code-block-background, now defined.
• The ground is a CSS background on <html> in light mode. Mintlify's background.image would require a dark image too.
• Verified after the change: a second full colour inventory finds nothing outside the palette, except video placeholders and play buttons that sit on dark video.

Test plan

• mint validate passes; mint broken-links: no broken links
• Contrast:
  • light body text 7.9–11.6:1 on the beige;
  • small grey text ≥4.6:1 and icons ≥3:1 on the darkest beige;
  • code colours 5.4:1 on the cream code blocks, 8.6:1 in dark;
  • dark text 12.6:1, secondary 8.2:1, tertiary 5.6:1.
• Scrolling, in a normally launched Chrome: 119–120 fps and 0 long tasks on the rendering guide and the CLI reference.
• Colour inventory across 10 page types in light and dark (introduction, quickstart, rendering, CLI reference, catalog, a catalog block, Studio app, vs Remotion, lint rules, changelog).
• Manual, in Chrome: those pages in both modes; phone width 390px with no sideways scroll; 0 page errors.
• Unit tests added/updated (styles only)
• Comments follow CONTRIBUTING.md "Comments"

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota.

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated
hyperframes	🟢 Ready	View Preview	Oct 26, 2026, 5:41 AM

💡 Tip: Enable Automations to automatically generate PRs for you.

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated
hyperframes	🟡 Building	–	Oct 26, 2026, 3:53 AM

💡 Tip: Enable Automations to automatically generate PRs for you.

[jrusso1020]

We found no source blocker. Palette tokens match the checked product sources, and text contrast passes against the actual darkest ground pixel in both modes. Intended syntax colors also pass, although the preview still emits the old Shiki inline colors, so we can't confirm the rendered syntax-theme change. Broken links pass. We did not remeasure scrolling FPS.

[jrusso1020]

We checked the follow-up and the hosted preview. The syntax colors now apply in light and dark mode, including the reported string colors. We found no functional blocker. One optional dark-keyword mapping gap is inline; we did not remeasure scrolling FPS.

[jrusso1020]

[P3] One dark keyword color is still outside the mapping. On sdk/quickstart, 12 tokens such as import/from/await use --shiki-dark: #C586C0 and still compute to rgb(197, 134, 192), while the mapped keywords use the editor palette. Consider mapping that keyword variant too. This is palette consistency feedback, not a functional blocker.

[jrusso1020]

We checked the added keyword rule. With the exact-head CSS applied, all 12 SDK tokens use the editor keyword color, resolving the source mapping note. The hosted page still returned the old color before that CSS was injected, so deployed confirmation remains pending. No source blocker found.

[miguel-heygen]

Independent review at 4c285f33643cd221d014843de1350530b42257e9. This PR is open with base main; it is not already merged.

docs/custom.css:1628 now maps both dark keyword variants to the editor role. On the actual hosted SDK quickstart, without CSS injection, all 12 C586C0 keyword tokens compute to oklch(0.829 0.164 318) in dark mode and oklch(0.509 0.211 329) in light mode. Sampled strings likewise match the editor string roles in both modes. This independently closes the deployed-confirmation gap in Rames's last review.

Audited: all four changed files, palette/structural selectors and source role tokens in Studio theme.css. Executed: public hosted-preview SDK route in light/dark at desktop and 390px, screenshots and computed-token assertions; no horizontal overflow. No uncaught page errors. The preview's existing GitHub repository/star-count XHR returns 403 and logs AxiosError; the code/theme assets render, and this CSS-only change does not alter that request. I did not reproduce the author's ten-page inventory, contrast census or 120fps claim.

Current checks: 25 success / 37 skipped, no failures. No source blocker found; no new install, native/provider acceptance, paid call, production write, merge or deployment performed. Approval covers this exact head only.

Verdict: APPROVE
Reasoning: The source mapping matches the editor palette and the formerly unverified keyword rule now applies on the real hosted preview in both themes.

— Magi