---
title: reed check
description: Validate the config and content without building. Always offline.
---

```sh
reed check [--dir <path>] [--content <path>] [--strict-tokens] [--strict-components]
```

Validates `docs.json` against the schema and runs static checks over your content — page
references resolve, components exist and carry their required props, referenced assets
are present. It does not build the site.

**Prerequisites: none.** `check` is unconditionally offline. It never invokes the
dependency-install step, so it needs no prior `reed prefetch`, no package manager, and no
network. That makes it the right check to run on every pull request, in any sandbox.

## Options

<ParamField name="--dir" type="path">
  Project root. Defaults to the current directory.
</ParamField>

<ParamField name="--content" type="path">
  Content directory. Defaults to `<dir>/content`.
</ParamField>

<ParamField name="--strict-tokens" type="boolean" default="false">
  Escalate every warning except `DS-D*` to an error.
</ParamField>

<ParamField name="--strict-components" type="boolean" default="false">
  Escalate `DS-D*` design-system warnings to errors.
</ParamField>

The two strict flags cover disjoint sets of diagnostics and compose — pass both to
escalate everything, or either alone to escalate just that category.

## Diagnostics

Problems are reported as `DS-*` codes. A representative one:

```
✗ [DS-S03] content file "api/limits.mdx"'s "ParamField" is missing required prop "name" (contract: ParamField)
```

A component name outside Reed's catalog reports `DS-S06`, so a typo fails here rather
than rendering as literal text on a published page.

## Relationship to `build`

`check` and `build` share one validation path — schema parse, template resolution,
per-token diagnostics, static checks — so they cannot disagree about whether a project is
valid. A green `check` means `build` will not fail for any of these reasons.