القائمة
Holocron is a Mintlify-compatible docs site generator and Vite plugin. Use this skill when creating, migrating, customizing, or deploying a Holocron documentation site.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | holocron |
| repo | https://github.com/remorses/holocron |
| description | Holocron is a Mintlify-compatible docs site generator and Vite plugin. Use this skill when creating, migrating, customizing, or deploying a Holocron documentation site. |
Holocron documentation changes fast. Do not rely on stale training data or repository-relative source paths. Fetch the public docs first, then search them.
Fetch https://holocron.so/sitemap.xml to see all available pages. Append .md to any page URL
to get raw markdown. Never pipe curl output through head, tail, sed -n, or any truncation
command. Read the full output every time.
curl -s https://holocron.so/sitemap.xml
curl -s https://holocron.so/docs/quickstart.md
When the user asks about a specific workflow, fetch the matching page directly:
docs.json config: https://holocron.so/docs/organize/docs-json.mdcurl -fsSL https://holocron.so/docs/quickstart.md
curl -fsSL https://holocron.so/docs/organize/docs-json.md
Use the CLI to create a new docs site with a working template:
npx -y "@holocron.so/cli" create --name "My Docs" my-docs --skip-auth
The --skip-auth flag skips cloud setup & AI chat setup (suitable for agents and local-only
usage). The template includes vite.config.ts, docs.jsonc, sample pages,
navigation with tabs, anchors, and icons.
After scaffolding, start the dev server:
cd my-docs
pnpm install
pnpm dev
docs.json basicsHolocron reads docs.json, docs.jsonc, or holocron.jsonc. Prefer
docs.jsonc when writing by hand because comments and trailing commas make it
easier to maintain.
Always fetch the schema before adding uncommon config fields:
curl -fsSL https://holocron.so/docs.json
Simple docs.jsonc:
{
"$schema": "https://holocron.so/docs.json",
"name": "Acme",
"description": "Documentation for Acme.",
"colors": { "primary": "#6366f1" },
"icons": { "library": "lucide" },
"navigation": {
"groups": [
{
"group": "Getting Started",
"icon": "lucide:rocket",
"pages": ["index", "quickstart"]
},
{
"group": "Guides",
"icon": "lucide:map",
"pages": ["guides/install", "guides/deploy"]
}
],
"global": {
"anchors": [
{ "anchor": "GitHub", "href": "https://github.com/example/docs", "icon": "lucide:github" },
{ "anchor": "Changelog", "href": "https://github.com/example/docs/releases", "icon": "lucide:newspaper" }
]
}
}
}
Page slugs in navigation.pages map to MDX files. quickstart loads
quickstart.mdx, and guides/install loads guides/install.mdx.
Do not dump every page into one flat directory. Put pages in subfolders named after their navigation group, so the file layout matches the sidebar. This keeps large docs sites navigable and makes each slug self-documenting.
docs.json group file layout slug in nav
┌────────────────┐ ┌──────────────────────────┐ ┌─────────────────────────┐
│ Getting Started│──────►│ getting-started/setup.mdx│───►│ getting-started/setup │
│ Guides │──────►│ guides/deploy.mdx │───►│ guides/deploy │
│ Reference │──────►│ reference/commands.mdx │───►│ reference/commands │
└────────────────┘ └──────────────────────────┘ └─────────────────────────┘
Rules:
getting-started/ folder. Use kebab-case folder names.guides/deploy.mdx has slug guides/deploy
and renders at /guides/deploy. Reference that full path in navigation.pages.index at the root. The home page stays index.mdx at the top level.navigation.pages slug and every internal link that points at the old flat
path (/old-slug becomes /group/old-slug). The build's broken-link check catches
links you miss.Anchors in navigation.global.anchors are persistent sidebar links visible
across all tabs. Use them for GitHub, Changelog, Discord, or other external
links.
Progressive disclosure in navigation. Order groups, pages, and tabs the way a reader would read them top-to-bottom. Start with introductory content (getting started, quickstart), then core concepts and guides, then advanced topics and reference material last. The reader should never need to jump ahead to understand the current section.
Tab order. In navigation.tabs, list documentation and guides first, then
API reference, then changelog. Tabs that link out to external URLs (href) go
last. This guides the reader from concepts to reference.
Use prefixed icon names so the source library is explicit:
"icon": "lucide:rocket"
"icon": "fontawesome:brands:github"
Plain names resolve against the configured library. See https://holocron.so/docs/customize/icons.md for the full reference.
If a group has an icon, do not use the same icon on the first page in that group. It looks like a duplicate in the navigation tree.
MDX pages can import .md, .mdx, .tsx, or .ts files. Prefer relative
imports (./ or ../) over absolute / imports. For example, import a root
README as the index page:
---
title: My Project
---
import Readme from '../../README.md'
<Readme />
See https://holocron.so/docs/create/local-imports.md for details.
[!IMPORTANT] Internal links must ALWAYS be relative (
./or../). NEVER use an absolute link starting with/.
Every internal link from one page to another must:
./ or ../ — a relative path from the current file. Never
start a link with /..md/.mdx file, not
a route or slug..md/.mdx extension.✅ [SDK reference](../sdk/README.mdx)
✅ [Browser Analytics](../docs/browser-analytics.mdx)
✅ [Quickstart](./quickstart.mdx)
❌ [SDK reference](/sdk/README) // absolute, hardcodes the route
❌ [Browser Analytics](/docs/browser-analytics)
❌ [Quickstart](/quickstart)
The reason: an absolute /slug link hardcodes the route, which depends on
pagesDir. The same file produces different slugs across projects
(pagesDir: './src' vs pagesDir: './src/pages'), so absolute links are
fragile and break when pagesDir or the folder layout changes. A relative path
to the real file is pagesDir-independent: Holocron resolves it to the right
route and strips the extension, and the link also opens the real file on GitHub.
Never reason about slugs or pagesDir when writing a link. Write the
relative path to the actual file on disk, the way you would for GitHub. Holocron
does the rest. The only links that may start with / are external full URLs
(https://...) and knownPaths entries declared in docs.json.
A common pattern is importing a repo README.md as the docs index page so the
same file renders on both GitHub and the Holocron site. The README links to
other docs (pricing, guides, reference), and those links must work in both
places.
The rule is simple: always link to the real target file with a correct
relative path, ending in .md or .mdx. Do not reason about slugs, pagesDir,
or where / ends up. Write the link the way you would for GitHub: a relative
path from the README to the actual file on disk.
Holocron does the rest. When it inlines an imported file, it recomputes every
relative link to be correct relative to the importing page, then strips the
.md/.mdx extension. So a README link to a real file lands on that file's
page automatically, with no per-environment guessing.
Link to the real file. The target must be an actual .md/.mdx file on
disk at the relative path you write. This is what makes GitHub work, and it is
what Holocron rewrites. If the file does not exist, GitHub 404s and Holocron's
broken-link check warns.
Always use a relative path (./ or ../), never absolute. The README is
rendered from different base directories on GitHub vs Holocron, so an absolute
/docs/x or a guessed path breaks in one of them. A relative path to the real
file works in both because Holocron recomputes it.
Keep the .md/.mdx extension. GitHub needs it to open the file;
Holocron strips it automatically so the link resolves to the rendered page.
The target file must be rendered by a page in the site. Holocron resolves
the rewritten link against pages. If the file you link to is itself a page (or
is imported by one) and that page is in docs.json navigation, the link
resolves. If nothing renders it, the site 404s — so add the page and put it in
navigation.
README.md [pricing](./docs/pricing.md) ◄── correct relative path to a real file
│
├──────────────────────► GitHub opens ./docs/pricing.md
│
▼ imported into the index page
Holocron recomputes the relative path ──► strips .md ──► lands on the page that renders pricing
│
▼
/docs/pricing ◄── resolves as long as a page renders that file and it is in docs.json
If the rewritten slug has no matching page, the build prints a broken-link
warning pointing at the README line. Fix it by creating the page at
<pagesDir>/<slug>.mdx (or a wrapper importing the shared .md) and adding its
slug to docs.json navigation.
Do not use MDX JSX components (like <Aside>, <Note>, <CardGroup>,
<Card>, etc.) inside README.md. GitHub does not render markdown inside
unknown HTML tags; content inside them appears as raw unformatted text.
The README should use only standard markdown. MDX-specific components belong in
the .mdx file that imports the README, not in the README itself.
Every MDX page can include YAML frontmatter. See https://holocron.so/docs/create/pages.md for the full fields reference.
---
$schema: https://holocron.so/frontmatter.json
title: Quickstart
description: Build and deploy your first Holocron docs site.
icon: lucide:rocket
tag: NEW
---
Title should be 50-60 characters max. It appears in the OG image at large font size, in the browser tab, and in search results. Keep it concise and descriptive.
Sidebar title — if title is longer than 30 characters, add a
sidebarTitle field in frontmatter with a shorter label (under 30 chars). The
left nav is only 230px wide; long titles wrap to multiple lines and break the
visual rhythm. The sidebarTitle replaces the title only in sidebar navigation;
the full title still appears in the page heading, browser tab, and OG image.
---
title: Configuring Authentication Providers
sidebarTitle: Auth Providers
---
Description should be 120-150 characters. It appears in the OG image below the title and in search engine snippets. Write a single sentence that summarizes the page content. Longer descriptions get truncated with an ellipsis.
Holocron renders the browser <title> as {page title} — {site name}. Two
frontmatter fields control what appears where:
title — browser tab, Google results, OG image, page heading. Write for SEO.sidebarTitle — sidebar navigation only. Write for scannability (short label).Always set both. title is the full descriptive phrase; sidebarTitle is
the short sidebar label. Without sidebarTitle, the full title shows in the
sidebar and often wraps or looks verbose.
---
title: Open-source browser automation for AI agents
sidebarTitle: Home
description: Automate any browser with a simple TypeScript API.
---
Browser tab: Open-source browser automation for AI agents — Playwriter
Sidebar: Home
Rules:
title identical to the site name. Playwriter — Playwriter is redundant.title MUST be descriptive, not a generic label. Introduction, Getting Started, Overview say nothing in a browser tab. Write what the page covers.title MUST be unique across the site.index.mdx MUST use sidebarTitle: Home (or Overview) and a descriptive title.Set mode in frontmatter to hide sidebars. Use for landing pages, tool pages, or pages that should not show left nav or AI chat. See https://holocron.so/docs/customize/layout.md for details.
center — hides the left nav, centers content. Right aside still works.custom — hides both sidebars and the editorial grid. Only navbar, tab bar, and footer remain. See example/src/landing.mdx for a full example.In both modes the content can feel too wide. Use maxWidth to constrain it:
---
mode: "custom"
maxWidth: 700
---
When the site mounts Holocron inside an existing Spiceflow app (the entry
option in the Vite plugin), always fetch the custom entry docs first. This page
covers middleware order, the shared theme cookie, Tailwind @reference rules,
and how to keep docs (including OpenAPI and Changelog tabs) under a /docs/*
namespace so they never collide with app routes like /api:
curl -fsSL https://holocron.so/docs/custom-entry.md
When restructuring docs, add redirects in docs.json. See
https://holocron.so/docs/create/redirects.md for the full reference.
Holocron warns about internal links pointing to non-existent pages during build
and dev. Links to redirect sources and static files (.json, .pdf, etc.) are
not flagged. The warning includes the source page, line number, and the
broken href so you can find and fix it quickly.
knownPathsWhen docs are mounted alongside other routes (API endpoints, dashboards, blogs),
internal links to those non-MDX paths trigger false broken-link warnings. Use
the knownPaths field in docs.json to tell Holocron these paths are valid:
{
"knownPaths": ["/api/*", "/dashboard", "/blog/*"]
}
Supported patterns:
"/dashboard" matches only /dashboard."/api/*" matches /api/users, /api/v2/health,
and any other path starting with /api/.Wildcards only work as a trailing /* suffix. Glob patterns like /api/*/users
are not supported.
When wrapping MDX content in a <div> or custom component, add
flex flex-col gap-(--prose-gap) so children get correct vertical spacing.
Without it, elements collapse together. Add no-bleed too if the wrapper
contains images or code blocks that shouldn't escape its bounds.
<div className='no-bleed flex flex-col gap-(--prose-gap)'>
First paragraph.
Second paragraph with correct spacing above.
</div>
Always use multi-line form for container components like Callout, Note,
Warning, Info, Tip, Check, Danger, Aside, Accordion, Steps,
Card, Expandable, Panel, Frame, and Prompt.
<Note>
Use `Note` for neutral supporting information.
</Note>
Single-line form can produce bare phrasing children without paragraph wrapping, which changes styling.
Native headings (h1-h6) are auto-fixed; Holocron unwraps the paragraph
wrapper regardless of form. For other leaf-like elements (<span>, <div>,
or custom uppercase components), use single-line form to avoid the wrapper.
<MyBanner className='text-xl'>Short announcement text</MyBanner>
Aside is positioning-only and has no visual frame. Always wrap visible content
inside Note, Tip, Info, Warning, Callout, or another framed component.
<Aside>
<Note>
This appears in the sidebar with a proper callout frame.
</Note>
</Aside>
Exception: Aside full can contain TableOfContentsPanel directly.
Only use <Aside> in sections with enough content. A non-full Aside shares
its vertical space with the section it belongs to (the content between two
headings). If the aside is taller than the section text, extra whitespace appears
below the main content to accommodate the aside height. Keep aside callouts
short, and only place them in sections that have at least a few paragraphs of
body text.
When moving or renaming a page, always add a redirect from the old slug to
the new one so existing links and bookmarks don't break. Update internal links
in other pages and the slug in docs.json navigation to match.
After creating a new .mdx or .md page, add its slug to docs.jsonc
navigation. Pages not in the navigation tree will not appear in the sidebar
and return 404.
Read the existing navigation structure first, then place the page in the best tab, group, and reading order.
The real docs live in website/src/pages/docs/, not example/src/. The example/
folder is a demo fixture, not the published docs site.
Before adding or editing docs content, always read website/docs.json first
to see the full navigation tree and existing pages. Then decide:
.mdx file and
add it to the best group in website/docs.json.Never append unrelated sections to a page just because it was the last file you had open. Match the topic to the right page or create a new one.
After editing MDX pages, docs.json navigation, or frontmatter, always build the site to
catch issues early. The build surfaces broken internal links, MDX parsing errors, missing pages
referenced in navigation, and rendering problems that the dev server may not show until a page
is visited.
pnpm build
Fix any warnings or errors before considering the changes done. Common issues:
[link](/some-page) pointing to a slug not in navigation.docs.json navigation but no matching .mdx file exists.If the build warns about links to paths that are not MDX pages but do exist at runtime (API
routes, external apps mounted alongside docs, dashboard pages), suppress those warnings with
the knownPaths field in docs.json. See the Broken link detection
section above.
Run --help to see all available commands. Never truncate the output.
npx -y "@holocron.so/cli" --help
Key commands: login, logout, whoami, deploy, projects list,
projects create, keys list, keys create, keys delete, create.
Before logging in, always check if the user is already authenticated:
npx -y "@holocron.so/cli" whoami
If whoami succeeds and shows user, orgs, and projects, skip login. Only run
npx -y "@holocron.so/cli" login if whoami fails.
When the user asks to "deploy the site", they may mean deploying with their own
script and platform (Cloudflare Workers, a Node server, CI pipeline), not
holocron deploy. Check package.json scripts first: if there is a deploy,
deployment, or similar script (e.g. wrangler deploy), use that instead of the
Holocron CLI. Only use holocron deploy when the project has no own deploy
script or the user explicitly asks for holocron.so hosting.
holocron deploy builds the docs site and uploads it to holocron.so hosting.
It is the fastest way to publish without managing your own server.
npx -y "@holocron.so/cli" deploy
The command runs the build, uploads only changed files, finalizes the deployment,
and prints the live URL. Use --project prj_xxx if the account has multiple
projects and you are using session auth. Use --branch <name> to override
branch detection for preview deploys.
Auth priority: HOLOCRON_KEY env var > session token from holocron login >
GitHub Actions OIDC token (automatic in GitHub Actions with id-token: write).
See https://holocron.so/docs/deploy/holocron.md for the full reference including deployment URLs, GitHub Actions OIDC setup, and org/project resolution.
Always deploy preview before production. If preview fails, stop.
When adding icons to any element in docs.json or MDX frontmatter, apply them consistently across all siblings at the same level. Inconsistent icon usage looks unfinished and breaks visual rhythm.
Rules:
navigation.global.anchors has an icon, all anchors must.icon, all pages in that group should. Exception: a group with only 1-2 pages where icons add no navigational value.<Card> in a <CardGroup> has an icon prop, every card in that group must.When reviewing or creating navigation and MDX content, scan siblings and fill in missing icons before finishing. Pick icons from the same library (usually Lucide) and choose semantically distinct icons for each item.
Every section and every paragraph must have at least one bold keyword or phrase. Readers skim docs pages; they do not read every word. Bold text acts as anchor points that let the eye jump to the relevant paragraph.
Pick the word or phrase that captures the core idea. Do not bold entire sentences or generic filler words. Bold the specific term, API name, or concept that a reader would scan for.
Use <Aside> often to place supplementary content in the right sidebar column. Asides break the monotony of a single-column text flow and give readers contextual notes exactly where they are relevant. A page with zero asides looks flat and underuses the layout.
Good candidates for Aside content:
Always wrap Aside content in a framed component (Note, Tip, Info, Warning, Callout).
## Authentication
The deploy command authenticates via **GitHub Actions OIDC** when running in CI.
<Aside>
<Info>
If OIDC is not available, fall back to a **`HOLOCRON_KEY`** environment variable
or a session token from `holocron login`.
</Info>
</Aside>
Aim for roughly one Aside per major section (per ## heading). Not every section needs one, but if a page has more than three ## sections without a single Aside, look for opportunities.
Avoid asides in short sections. A non-full Aside shares vertical space with its section (the text between two headings). If the aside callout is taller than the section body, empty whitespace fills the gap below the main content. Only add asides to sections with enough prose to match or exceed the aside height. Keep aside callouts concise (1-2 sentences).
Use ASCII diagrams frequently in MDX pages. Always use the diagram language hint on the code fence. Holocron renders diagram fences with special styling; Unicode box-drawing characters and arrows get colored differently from labels.
Layout rules:
npx -y "@holocron.so/cli" diagrams fix <file> (see dedicated section below).```diagram
┌───────────────┐
docs.jsonc ───►│ Vite Plugin │──────► Build Output
└───────┬───────┘
│
┌───────▼───────┐
│ sync.ts │ MDX files ──► parsed sections
│ (walk nav) │ git SHA diff ──► cache hit/miss
└───────┬───────┘
│
┌──────────────┼──────────────┐
▼ ▼ ▼
navigation page cache virtual modules
tree.json holocron-mdx holocron-pages
holocron-config holocron-config
```
diagrams fix after editing diagramsLLMs cannot count characters reliably. Every time you create or edit a diagram in an MDX page, you must run the alignment fixer before committing. This is not optional.
npx -y "@holocron.so/cli" diagrams fix path/to/file.mdx
The command:
If the output says "No changes", the diagram was already correct. If it reports width violations, shorten the offending lines manually and re-run.
Do not skip this step. Even if the diagram looks correct in your editor, run the command. Off-by-one padding errors are invisible to LLMs but obvious to humans in monospace fonts.
OpenAPI operation summary fields become sidebar titles. The sidebar is only
230px wide, so summaries must be short: 2-3 words, ideally under 20
characters. Use the same concise style as page sidebarTitle fields.
List users, Create order, Get me, Upload files.Upload deployment files (zip batch) becomes Upload files.Deploy, the summary should not start with "Deploy".Always wrap YouTube embeds, videos, and large images in <div className='bleed'>
so they extend into both page margins instead of sitting at narrow prose width.
<Frame> also accepts className='bleed'. Containers like Callout, Card, and
Accordion apply no-bleed automatically to keep descendants inside their frame.
See https://holocron.so/docs/customize/bleed.md for the full reference.
When customizing the look of a Holocron site, always use CSS variable overrides in :root instead of targeting internal class names, DOM structure, or aria labels. Holocron exposes a set of documented CSS variables for colors, typography, spacing, code blocks, blockquotes, and sidebar navigation. These are stable across Holocron updates; internal markup is not.
/* style.css */
:root {
--weight-heading: 700;
--code-block-background: var(--muted);
--code-block-border: 1px solid var(--border-subtle);
--sidebar-link-radius: var(--radius-sm);
--blockquote-border-color: var(--border-subtle);
}
Fetch the full list of available tokens:
curl -fsSL https://holocron.so/docs/customize/theme.md
If a user wants to customize something that has no CSS variable, do not hack it with fragile selectors. Instead, open an issue on the Holocron repo (https://github.com/remorses/holocron/issues) requesting a new CSS variable for that use case. Holocron actively adds new variables based on user needs. Internal selectors like .slot-sidebar-left nav > div:first-child > a or figure[class~='group/code'] button[aria-label='Copy code'] will break on any refactor and should never be used.
pagesDir. Before creating or
editing any docs page, read the project's vite.config.ts (or vite.config.mts)
to find the pagesDir option passed to the Holocron plugin. If pagesDir is not
set, it defaults to the project root. All .mdx and .md page files must live
inside that directory; files outside it are invisible to the navigation and build.diagram language hint on the
code fence (```diagram). This renders them with proper styling on the
website instead of plain monospace.npx -y "@holocron.so/cli" diagrams fix <file>
to auto-fix alignment. LLMs cannot count characters reliably.--help output through head, tail, or any truncation
command. Always read the full output.