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
- Very specific: line 12
Use rspress.config.ts and defineConfig from @rspress/core
- Very specific: line 14
Keep site-wide settings such as title, description, icon, logo, base, and lang in config instead of repeating them in page files
- Distinctive: line 15
Prefer first-class Rspress options before custom theme code or low-level bundler overrides
- Very specific: line 16
Keep custom theme code in a top-level theme/ directory and import original theme pieces from @rspress/core/theme-original
- Very specific: line 20
Use rspress dev for local development
- Very specific: line 21
Use rspress build for production output
- Very specific: line 22
Use rspress preview only for local preview of the built site
- Very specific: line 23
Use rspress eject only when CSS variables, class overrides, or layout wrapping cannot solve the customization
- Distinctive: line 27
Keep docs content under one clear docs root and group pages by topic or workflow, not by team ownership
- Very specific: line 28
Use _meta.json or _nav.json to control sidebar and navigation labels/order instead of encoding order in filenames
- Distinctive: line 29
Put reusable MDX snippets or shared components in shared files instead of duplicating them across pages
- Distinctive: line 30
Keep landing pages concise and link to deeper task-oriented guides from them
- Very specific: line 34
Add clear title and description frontmatter, and set sidebar, outline, navbar, or footer only when page defaults are not enough
- Very specific: line 35
Use pageType: home, doc, doc-wide, custom, or blank intentionally based on layout needs
- Distinctive: line 36
Write task-first headings and short intros.
- Distinctive: line 37
Prefer one topic per page and split overly long pages by workflow or feature area
- Distinctive: line 38
Keep code examples minimal, runnable, and version-accurate
- Distinctive: line 42
Use MDX for interactive docs and embedded components, but keep the main narrative understandable as plain markdown
- Distinctive: line 43
Prefer documented Rspress theme/runtime APIs over importing from internal source paths
- Distinctive: line 48
Prefer CSS variables for brand colors, spacing, and surface styling
- Very specific: line 49
Prefer BEM class overrides or Layout slots before ejecting built-in components
- Distinctive: line 51
Avoid full component ejection unless config, CSS, and wrapping cannot meet the requirement
- Distinctive: line 56
Keep descriptions and other frontmatter text in the same language as the page content
- Distinctive: line 62
Import source-managed images and components from docs/theme source when they belong to the content
- Very specific: line 63
Use public/ only for assets that must keep stable URL paths, such as favicons, social images, or download files
- Distinctive: line 68
Prefer official Rspress plugins for search, preview, and API-doc scenarios before building custom solutions
- Distinctive: line 70
Keep plugin usage explicit in config and remove unused plugins to reduce maintenance cost
- Very specific: line 75
Verify broken links, missing assets, and wrong base handling before deployment
- Distinctive: line 76
Keep generated output out of source control unless the hosting workflow explicitly requires committed artifacts
- Distinctive: line 77
When debugging content issues, inspect the resolved docs root, frontmatter, and theme overrides before assuming a bundler problem
- Distinctive: line 82
Use the config and API docs when checking exact option names or current behavior
≈ “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.
Files
Rspress best practices
Apply these rules when writing or reviewing Rspress (v2) sites.
Configuration
- Use
rspress.config.tsanddefineConfigfrom@rspress/core - Set
rootexplicitly when docs are not under the defaultdocs/directory - Keep site-wide settings such as
title,description,icon,logo,base, andlangin 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 devfor local development - Use
rspress buildfor production output - Use
rspress previewonly for local preview of the built site - Use
rspress ejectonly 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.jsonor_nav.jsonto 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
titleanddescriptionfrontmatter, and setsidebar,outline,navbar, orfooteronly when page defaults are not enough - Use
pageType: home,doc,doc-wide,custom, orblankintentionally 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
globalUIComponentsor 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
Layoutslots before ejecting built-in components - In
theme/files, keepexport * 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
llmsorssgMdonly 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
baseis 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-previewand@rspress/plugin-api-docgenwhen 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 devandrspress build; a page that works in dev can still fail during static generation - Verify broken links, missing assets, and wrong
basehandling 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
Other versions2 projects use a version of this.
Word for word · 0
None found.
Edited · 2
- open-spaced-repetition/ts-fsrs★ 84695% same
- Muromi-Rikka/cc-learn★ 295% same
Wrote their own version · 0
None found.
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository31 other files it gives its agents.
- AGENTS.mdAGENTS.md
- create-draft-release-notesSkill
- mdx-to-markdownSkill
- pr-creatorSkill
- release-blog-writerSkill
- rstack-docs-writerSkill
- rstack-eco-ci-debugSkill
- rstack-repo-maintainSkill
- rstack-skill-evaluatorSkill
- migrate-to-rsbuildSkill
- migrate-to-rslibSkill
- migrate-to-rslintSkill
- migrate-to-rstestSkill
- rsbuild-best-practicesSkill
- rsbuild-v2-upgradeSkill
- rsdoctor-analysisSkill
- rsdoctor-v2-upgradeSkill
- rslib-best-practicesSkill
- rslib-modern-packageSkill
- rspack-best-practicesSkill
- rspack-debuggingSkill
- rspack-split-chunksSkill
- rspack-tracingSkill
- rspack-v2-upgradeSkill
- rspress-custom-themeSkill
- rspress-description-generatorSkill
- rspress-docs-generatorSkill
- rspress-v2-upgradeSkill
- rstest-best-practicesSkill
- rstest-debuggingSkill
- storybook-rsbuildSkill
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.

