This playbook directs AI agents working in the RustFS documentation repository so that every deliverable stays accurate, auditable, and easy to maintain.
- Framework: VitePress; source files live in
docs/, site-wide configuration in.vitepress. - Goal: produce documentation for a distributed object storage product aimed at a global audience, currently English-first with room for other locales.
- Navigation:
docs/sidebar.tsanddocs/config.tsdefine the site structure; new pages must be reflected in these files immediately.
- Accuracy: Data, APIs, and commands must be reproducible; cite third-party information with a concise source note.
- Consistency: Match the existing file layout, naming, frontmatter, and heading hierarchy.
- Minimal change: Touch only files relevant to the task; avoid drive-by formatting or reordering.
- Readability: Use concise active-voice English; spell out technical terms once with their abbreviations (e.g., Large Language Model, LLM).
- Security: Never commit secrets, tokens, or real certificates; scrub sensitive values from sample configs.
git checkout main && git pullto sync with the latest baseline.- Install dependencies via
pnpm install(ornpm install) whenever the repo is fresh or packages changed. - Create a topic branch for the task:
git checkout -b docs/<topic>-<short-desc>.
- Locate or create the Markdown file under
docs/; when adding a section, createindex.mdin that directory as its entry point. - Reuse existing frontmatter fields (
title,aside,outline, etc.) to keep VitePress behavior intact. - Store images in a sibling
images/folder orpublic/, use descriptive names, and reference them via relative paths such as./images/<name>.png. - For multilingual work, mirror the default structure under
docs/<locale>/...exactly. - Update navigation by editing
docs/sidebar.tsor the relevant scopedsidebar.ts, keeping paths free of extra prefixes.
- Manually preview Markdown: keep heading levels sequential and leave blank lines between lists and code blocks.
- Compare against requirements or issues to confirm every acceptance criterion is satisfied.
- Run the commands listed in Section 5 to ensure builds succeed without warnings.
- Structure: Start with context, then cover “Overview → Steps → References/Constraints.”
- Terminology: Bold or code-style the first mention of product/module names; wrap commands and filenames in backticks.
- Code blocks: Include language hints (
bash,rust, etc.) and provide runnable snippets only. - Tables and media: Tables need a header row; every image requires meaningful
alttext. - Update note: Optionally append “Last Updated: YYYY-MM-DD” at the end for traceability.
- Build: Run
pnpm build(ornpm run build) to ensure VitePress generates the site without errors. - Preview (optional):
pnpm devis recommended when navigation or interactive pieces change. - Links/assets: Watch the terminal for warnings; confirm external URLs use the right protocol and remain reachable.
- Self-checklist:
- Frontmatter is complete and valid.
- Every relative path points to an existing file.
- No new console warnings were introduced (missing default export, TS errors, etc.).
- Use
git statusto verify only task-related files changed. - Write semantic commits such as
docs: <scope>orfeat: add xxx guide. - Include in the Pull Request:
- A concise change summary.
- Build/preview commands and their outcomes.
- Links to related issues or requirement docs.
- When translation or locale sync is involved, list the language directories covered.
pnpm install # install dependencies
pnpm dev # local development preview
pnpm build # generate static site
pnpm preview # preview the build output- Avoid PRs that mix unrelated domains (e.g., config refactors plus large wording sweeps).
- Prefer Markdown + Mermaid for diagrams; if an image is required, provide the source or reproduction steps.
- Fix historical doc issues in the same PR only when documented as a “drive-by fix” with rationale.
Following these guidelines keeps AI agent contributions maintainable and ready for future reviews or automation hooks.