Skip to content
Reed Docs

reed check

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

Section titled “Options”
--dirpath

Project root. Defaults to the current directory.

--contentpath

Content directory. Defaults to <dir>/content.

--strict-tokensbooleandefault: false

Escalate every warning except DS-D* to an error.

--strict-componentsbooleandefault: false

Escalate DS-D* design-system warnings to errors.

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

Section titled “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

Section titled “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.