MultiTool Checks

Reference

This page documents the multi check command, the CHECKS.md file format, and the settings that control how checks run.

The multi check command

multi check [path]

Scans path (the current directory by default) recursively for files named CHECKS.md, evaluates every check it finds, and prints a report. Files and directories excluded by .gitignore are skipped.

Run multi check --help for full usage.

Flags

Flags take precedence over environment variables and the config file. Environment variables take precedence over the config file.

Exit codes

Because most CI systems fail the job when a command returns a non-zero status code, you can run multi check in CI to validate that all checks pass.

Report

Each requirement's title is printed, shown in green when it passes and red when it fails. Under a failed requirement, its failing checks are listed with the agent's evidence explaining why each did not pass. Passing checks are omitted. Coloring follows --enable-colors and falls back to plain text when disabled.

The CHECKS.md format

A CHECKS.md file is ordinary Markdown. H1 and H2 headers have a semantic meaning. H1s are used for requirements, while H2s are used for checks.

Requirements

An H1 whose text begins with Requirement declares a requirement. The rest of the line is its title. Req is an accepted alias.

# Requirement No yellow text

# Req No yellow text

Both declare a requirement titled "No yellow text".

Checks

An H2 whose text begins with Check declares a check belonging to the nearest requirement above it. The text after Check is the check's title, and the Markdown beneath it, up to the next heading, is the prompt handed to the agent.

# Requirement No yellow text

Optional context for the requirement.

## Check CSS colors

Scan each CSS file. For every rule that sets `color`, confirm the value is not `yellow`.

A requirement is satisfied only if all of its checks pass.

Single-check requirements

If a requirement has no ## Check heading, its prose body becomes a single check that inherits the requirement's title.

# Requirement No serif fonts

Scan the CSS files in this directory. Confirm none of the named fonts are serif.

This is equivalent to one requirement with one check, both titled "No serif fonts".

When a requirement has one or more ## Check headings, its own prose body is treated as optional context and is not evaluated.

Errors

The following are errors:

• A requirement with neither a ## Check nor a prose body.
• A ## Check with no requirement above it.

Multiple files

A project may contain any number of CHECKS.md files. Every one under the target directory is discovered recursively, so you can colocate requirements with the code they describe or split a large suite across files. .gitignore rules are respected.

Titles need not be unique. Two requirements, or two checks, may share a title, and both are kept.

Configuration

Four settings control how checks run.

model is validated against a list of known IDs for the selected provider. An unknown ID is an error.

effort sets the agent's reasoning budget. low runs without extended thinking, for speed and lower cost. medium and high enable extended thinking with progressively larger budgets.

concurrency caps how many checks run at once. A value of 0 is rejected.

Resolution order

Configuration values can be set via CLI flags, environment variables, or configuration files. Any value left unset uses its default. Defaults have the lowest precedence; flags, environment variables, and config files override them, in that order of precedence:

1. Command-line flags: --provider, --model, --effort, --concurrency.
2. Environment variables, under the MULTI_CHECKS_ prefix: MULTI_CHECKS_PROVIDER, MULTI_CHECKS_MODEL, MULTI_CHECKS_EFFORT, MULTI_CHECKS_CONCURRENCY.
3. The [checks] table of a MultiTool.toml file, discovered by searching up the directory tree. .json and .jsonc manifests are also supported.

[checks]
provider    = "anthropic"
model       = "claude-sonnet-5"
effort      = "low"
concurrency = 8

Credentials

API keys are read only from each provider's native environment variable. They are never read from the config file or the MULTI_CHECKS_ prefix — this keeps credentials out of config files that could be accidentally committed or shared.

A provider can only be selected when its API key is present. Selecting a provider whose key is missing is an error.

A base URL can also be set per provider in the config file:

[checks.providers.anthropic]
base_url = "https://..."

Routing through an Anthropic-compatible endpoint

A service that exposes an Anthropic-compatible Messages API (for example, Fireworks) can be used through the anthropic provider. Set the base URL to that endpoint and ANTHROPIC_API_KEY to the service's key.

[checks]
provider = "anthropic"
model    = "accounts/fireworks/routers/glm-5p1-fast"

[checks.providers.anthropic]
base_url = "https://api.fireworks.ai/inference"

The model must be on the Anthropic provider's known-model list. Adding a new model ID currently requires a code change.

Platform and check support

• The CLI runs on macOS and Linux. Windows support is planned.
• Checks are prompts evaluated by an AI agent. Shell-based, executable, and browser-based checks are planned.
• Agents evaluate checks with read-only access and cannot modify or run your project.