agentleFS
rstackjsrstackjs/agent-skills/skills/rspress-best-practices/SKILL.md

rspress-best-practices

Skill97 starsChanged 3 months agoMITView on GitHub

Configure, review, or troubleshoot Rspress v2 sites, including content conventions, navigation, MDX, assets, search, and deployment.

We split this skill into the rules it gives an agent

31 rules. About 0 are common, 18 are distinctive, and 13 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈18

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 13

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Use rspress.config.ts and defineConfig from @rspress/core

    line 12
  2. Very specific:

    Keep site-wide settings such as title, description, icon, logo, base, and lang in config instead of repeating them in page files

    line 14
  3. Distinctive:

    Prefer first-class Rspress options before custom theme code or low-level bundler overrides

    line 15
  4. Very specific:

    Keep custom theme code in a top-level theme/ directory and import original theme pieces from @rspress/core/theme-original

    line 16
  5. Very specific:

    Use rspress dev for local development

    line 20
  6. Very specific:

    Use rspress build for production output

    line 21
  7. Very specific:

    Use rspress preview only for local preview of the built site

    line 22
  8. Very specific:

    Use rspress eject only when CSS variables, class overrides, or layout wrapping cannot solve the customization

    line 23
  9. Distinctive:

    Keep docs content under one clear docs root and group pages by topic or workflow, not by team ownership

    line 27
  10. Very specific:

    Use _meta.json or _nav.json to control sidebar and navigation labels/order instead of encoding order in filenames

    line 28
  11. Distinctive:

    Put reusable MDX snippets or shared components in shared files instead of duplicating them across pages

    line 29
  12. Distinctive:

    Keep landing pages concise and link to deeper task-oriented guides from them

    line 30
  13. Very specific:

    Add clear title and description frontmatter, and set sidebar, outline, navbar, or footer only when page defaults are not enough

    line 34
  14. Very specific:

    Use pageType: home, doc, doc-wide, custom, or blank intentionally based on layout needs

    line 35
  15. Distinctive:

    Write task-first headings and short intros.

    line 36
  16. Distinctive:

    Prefer one topic per page and split overly long pages by workflow or feature area

    line 37
  17. Distinctive:

    Keep code examples minimal, runnable, and version-accurate

    line 38
  18. Distinctive:

    Use MDX for interactive docs and embedded components, but keep the main narrative understandable as plain markdown

    line 42
  19. Distinctive:

    Prefer documented Rspress theme/runtime APIs over importing from internal source paths

    line 43
  20. Distinctive:

    Prefer CSS variables for brand colors, spacing, and surface styling

    line 48
  21. Very specific:

    Prefer BEM class overrides or Layout slots before ejecting built-in components

    line 49
  22. Distinctive:

    Avoid full component ejection unless config, CSS, and wrapping cannot meet the requirement

    line 51
  23. Distinctive:

    Keep descriptions and other frontmatter text in the same language as the page content

    line 56
  24. Distinctive:

    Import source-managed images and components from docs/theme source when they belong to the content

    line 62
  25. Very specific:

    Use public/ only for assets that must keep stable URL paths, such as favicons, social images, or download files

    line 63
  26. Distinctive:

    Prefer official Rspress plugins for search, preview, and API-doc scenarios before building custom solutions

    line 68
  27. Distinctive:

    Keep plugin usage explicit in config and remove unused plugins to reduce maintenance cost

    line 70
  28. Very specific:

    Verify broken links, missing assets, and wrong base handling before deployment

    line 75
  29. Distinctive:

    Keep generated output out of source control unless the hosting workflow explicitly requires committed artifacts

    line 76
  30. Distinctive:

    When debugging content issues, inspect the resolved docs root, frontmatter, and theme overrides before assuming a bundler problem

    line 77
  31. Distinctive:

    Use the config and API docs when checking exact option names or current behavior

    line 82

≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Rspress best practices

Apply these rules when writing or reviewing Rspress (v2) sites.

Configuration

  • Use rspress.config.ts and defineConfig from @rspress/core
  • Set root explicitly when docs are not under the default docs/ directory
  • Keep site-wide settings such as title, description, icon, logo, base, and lang in config instead of repeating them in page files
  • Prefer first-class Rspress options before custom theme code or low-level bundler overrides
  • Keep custom theme code in a top-level theme/ directory and import original theme pieces from @rspress/core/theme-original

CLI

  • Use rspress dev for local development
  • Use rspress build for production output
  • Use rspress preview only for local preview of the built site
  • Use rspress eject only when CSS variables, class overrides, or layout wrapping cannot solve the customization

Docs structure and navigation

  • Keep docs content under one clear docs root and group pages by topic or workflow, not by team ownership
  • Use _meta.json or _nav.json to control sidebar and navigation labels/order instead of encoding order in filenames
  • Put reusable MDX snippets or shared components in shared files instead of duplicating them across pages
  • Keep landing pages concise and link to deeper task-oriented guides from them

Writing and frontmatter

  • Add clear title and description frontmatter, and set sidebar, outline, navbar, or footer only when page defaults are not enough
  • Use pageType: home, doc, doc-wide, custom, or blank intentionally based on layout needs
  • Write task-first headings and short intros; avoid marketing-heavy copy in technical docs
  • Prefer one topic per page and split overly long pages by workflow or feature area
  • Keep code examples minimal, runnable, and version-accurate

MDX and components

  • Use MDX for interactive docs and embedded components, but keep the main narrative understandable as plain markdown
  • Prefer documented Rspress theme/runtime APIs over importing from internal source paths
  • For app-wide UI or providers, use globalUIComponents or theme overrides instead of repeating imports in each page

Theme and styling

  • Prefer CSS variables for brand colors, spacing, and surface styling
  • Prefer BEM class overrides or Layout slots before ejecting built-in components
  • In theme/ files, keep export * from '@rspress/core/theme-original' unless intentionally replacing a named export
  • Avoid full component ejection unless config, CSS, and wrapping cannot meet the requirement

I18n, Search, And AI

  • For multilingual sites, organize locale content under per-language directories and keep navigation mirrored where practical
  • Keep descriptions and other frontmatter text in the same language as the page content
  • Configure search intentionally: use local search for small or medium sites, and hosted search when scale or cross-version indexing requires it
  • Enable llms or ssgMd only when the site benefits from machine-readable outputs, and keep descriptions accurate because those outputs surface page summaries

Assets and public files

  • Import source-managed images and components from docs/theme source when they belong to the content
  • Use public/ only for assets that must keep stable URL paths, such as favicons, social images, or download files
  • Reference public assets by absolute site path and make sure they still work when base is set

Plugins and integration

  • Prefer official Rspress plugins for search, preview, and API-doc scenarios before building custom solutions
  • For component or library docs, use @rspress/plugin-preview and @rspress/plugin-api-docgen when interactive demos or API tables are needed
  • Keep plugin usage explicit in config and remove unused plugins to reduce maintenance cost

Build, Deploy, And debugging

  • Validate both rspress dev and rspress build; a page that works in dev can still fail during static generation
  • Verify broken links, missing assets, and wrong base handling before deployment
  • Keep generated output out of source control unless the hosting workflow explicitly requires committed artifacts
  • When debugging content issues, inspect the resolved docs root, frontmatter, and theme overrides before assuming a bundler problem

Documentation

  • For the latest Rspress docs, read https://rspress.rs/llms.txt
  • Use the config and API docs when checking exact option names or current behavior

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

Reviews can't be read right now.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.