Development

Work on the ByteKit documentation site locally and keep content aligned with the package.

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.

Recommended update workflow

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.