> ## Documentation Index
> Fetch the complete documentation index at: https://bytekit.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# 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:

```bash theme={null}
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:

```bash theme={null}
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

<Steps>
  <Step title="Confirm the package API">
    Check the `bytekit` repo before documenting modules, options, import paths, or examples.
  </Step>

  <Step title="Edit the relevant page">
    Keep the page scoped to one job: getting started, a guide, or package reference.
  </Step>

  <Step title="Update navigation if needed">
    If you add or rename a page, keep `docs.json` in sync.
  </Step>

  <Step title="Run link validation">
    Run the link validation command before you commit.
  </Step>
</Steps>

## 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.