Documentation Writing Standards

🌱 初步完成

本文档内容已初步完成，可作为参考。但可能存在错误或需要改进的地方。

Related Pages

Page	Notes
	Explains the sidebar generation rules and the fields that usually need to be edited when pages or directories change.
	A guide to the Markdown extensions, containers, and custom components available in CrychicDoc.
	A guide to using LiteTree to build clear and information-dense tree structures.
	Where configuration, runtime logic, components, plugins, and styles should live in CrychicDoc.
	How to extend hero typography, floating items, shaders, background renderers, and nav/search visuals in CrychicDoc.
	Maintenance guidance for components, i18n, navigation layout, floating elements, and markdown plugins.

External References

Link	Role
	Official framework documentation

Contribution

Workflow

• 1. Fork & Clone
  • Fork the main repository to your own account, then clone it locally.
• 2. Sync and Create a Branch
  • Before you start editing, sync with the upstream repository and create a branch for the change.
• 3. Edit and Commit
  • Make the change on your branch and commit it with a clear message.
• 4. Open a Pull Request
  • Push your branch to your fork and open a pull request back to the main repository.

Project Structure

• CrychicDoc Main project
  • .github CI/CD scripts
    • workflows Automated build scripts
  • .vitepress VitePress configuration
    • config All project configuration
      • lang Locale configuration
      • locale Localization resources
        • langcode Per-language data
          • componennts Component translation keys
          • snippets Home floating text translation keys
          • footer.ts Footer configuration
      • sidebar Sidebar configuration
      • common-config.ts Shared VitePress configuration
      • contributors.json Contributor configuration
      • markdown-plugins.ts Markdown plugin registration
      • project-config.ts Main project configuration
    • plugins Custom plugins
    • theme Custom theme
      • components Vue components
      • styles CSS styles
    • config.mts VitePress entry configuration
    • index.ts Sidebar entry point
  • .vscode VS Code workspace settings
    • settings.json Workspace editor settings
    • launch.json Debug configuration
  • docs Content directory
    • public Static assets
    • zh Chinese content
      • Various files Documentation files
    • en English content
      • Various files Documentation files
  • README.md Project overview
  • LICENSE CC BY-SA 4.0
  • .gitignore Git ignore rules

Writing Conventions

Core Guides:

• - Markdown extensions and custom components.
• - Sidebar generation rules and directory-level field usage.

Supporting Guides:

• - Build clear tree-style structures in Markdown.

Frontmatter Configuration

Each Markdown file should include a frontmatter block for page metadata:

Metadata Mode Examples

---
metadata:
  mode: kubejs
  current:
    label: 1.20.1
    value: kubejs-2001.6.5-build.7
  requiredMods:
    - name: ProbeJS
      version: probejs-6.0.1
  routes:
    - server_scripts
---

---
metadata:
  mode: modding
  current:
    label: 1.20.4
    value: NeoForge 20.4.x
  stack:
    - name: NeoGradle
      version: userdev 7.0.124
  routes:
    - datagen
    - registry
---

---
metadata:
  mode: mod
  side: both
  latest: 1.21.x
  supported: [1.21.x, 1.20.1, 1.19.2, 1.18.2]
  loaders: [Forge, NeoForge]
  sources:
    curseforge: https://www.curseforge.com/minecraft/mc-mods/example
    modrinth: https://modrinth.com/mod/example
---

When metadata.mode: mod, side can be server, client, or both.

Directory-level metadata usually lives in sidebarIndex.md. If a directory needs a clickable landing page, the system looks for index.md -> Catalogue.md -> README.md in that order.

Headings and Anchors