Skip to main content

​
What this page covers

This page is for contributors who edit the ByteKit docs site itself.
  • Use it when you add or rewrite docs pages.
  • Use it when you change navigation in docs.json.
  • Use it when package exports or examples change in the main bytekit repo.

​
Prerequisites

  • Node.js 18 or newer
  • The docs CLI available in your shell
  • Access to the bytekit package repo when you need to verify exports or examples

​
Run the docs site locally

Start the local preview from the root of this docs repo: 
mintlify dev
The site runs at http://localhost:3000.

​
Validate before you publish

Run the broken-link validation after moving pages, renaming slugs, or editing navigation: 
mintlify broken-links

​
Keep docs aligned with the package

This site should reflect the real ByteKit package surface. When you update content:
  • Verify import paths against the package exports map.
  • Prefer examples that match the actual public API.
  • Remove or rewrite generic starter content that does not describe ByteKit.
  • Keep the landing page and reference pages aligned with the package surface area.

​
Where to edit common things

  • Edit docs.json for navigation, navbar links, footer links, and global anchors.
  • Edit index.mdx for the product landing page.
  • Edit quickstart.mdx for the first-run developer path.
  • Edit files in guides/ for topic-driven documentation.
  • Edit files in reference/ for import paths, modules, and package structure.

​
Content standards for ByteKit docs

  • Lead with the developer task, not the implementation detail.
  • Use code examples that can plausibly be copied into a real app.
  • Prefer focused examples over placeholder demos.
  • Use code formatting for package names, commands, paths, imports, and identifiers.
  • Keep terminology consistent across guides and reference pages.
1

Confirm the package API

Check the bytekit repo before documenting modules, options, import paths, or examples.
2

Edit the relevant page

Keep the page scoped to one job: getting started, a guide, or package reference.
3

Update navigation if needed

If you add or rename a page, keep docs.json in sync.
4

Run link validation

Run the link validation command before you commit.

​
What a good docs change looks like

  • The page speaks directly about ByteKit.
  • Code samples match current public exports.
  • Navigation stays in sync with the content.
  • Link validation passes before commit.