MultiTool Checks

How to use MultiTool Checks

This guide takes you from nothing to running your first checks on a small sample project. By the end you'll have installed the CLI, validated two requirements, watched one pass and one fail, and learned how to read the report. It takes about ten minutes.

This is the shortest path to a working result. For the full list of available options, see the Reference.

Prerequisites

You'll need:

• macOS or Linux. MultiTool Checks runs on macOS and Linux; Windows isn't supported yet.
• An API key from one supported model provider: Anthropic, OpenAI, or Gemini. This guide uses Anthropic. Checks are evaluated by that provider's model, so usage is billed to your own account.

MultiTool Checks only reads your code, it never modifies or runs it.

Step 1: Install the CLI

Install with Homebrew:

brew install wack/tap/multi

(No Homebrew? Download a binary from the Releases page instead.)

Step 2: Add your API key

MultiTool Checks reads your key from an environment variable. Create a key in the Anthropic Console, then export it in your terminal:

export ANTHROPIC_API_KEY="sk-ant-..."

This lasts for the current terminal session. To keep it set across sessions, add the same line to your shell profile (~/.zshrc for zsh, ~/.bashrc for Bash, or ~/.config/fish/config.fish for Fish).

Step 3: Create a sample project

Create a small throwaway folder so you can reproduce a clear pass and a clear fail:

mkdir checks-demo && cd checks-demo

Add a README; this will satisfy a check later.

cat > README.md <<'MD'
# Demo Project

A tiny project for trying MultiTool Checks.
MD

Add a stylesheet with a deliberate problem. In this example, we'll use a yellow text color:

cat > styles.css <<'CSS'
body { color: black; }
.warning { color: yellow; }
CSS

Step 4: Declare your requirements

Requirements live in a file named CHECKS.md. Create one at the root of checks-demo:

cat > CHECKS.md <<'MD'
# Requirement Documentation exists
The project contains a README file, and it is not empty.

# Requirement No yellow text
Scan every CSS file in this project. For each rule that sets `color`,
confirm the value is not `yellow`.
MD

Two things to notice:

• Each # Requirement <title> line declares one requirement.
• Neither requirement here has a ## Check subheading, so its prose body is its single check. You add ## Check <title> subheadings only when one requirement needs several checks (all of which must pass). The full syntax is in the Reference.

Step 5: Run the checks

From inside checks-demo:

multi check

MultiTool Checks finds your CHECKS.md, evaluates each check with an AI agent, and prints a report. (On OpenAI or Gemini, run multi check --provider openai --model <id> instead.)

Step 6: Read the report

Your output will look similar to this. The exact wording of the evidence varies between runs, but the structure is stable:

✓ Documentation exists
✗ No yellow text
    .warning sets color: yellow (styles.css:2)

How to read it:

• A green ✓ means the requirement passed; a red ✗ means it failed.
• Beneath a failed requirement, MultiTool Checks shows the evidence — here, the exact rule and line that broke it. Passing checks are left out to keep the report focused.

Now fix the problem. Open styles.css, change yellow to a non-yellow color such as orange, and run multi check again. Both requirements should pass:

✓ Documentation exists
✓ No yellow text

You've now written a requirement, watched it fail on a real problem, and confirmed the fix.

Step 7: Gate CI on your checks (optional)

multi check exits 0 when every requirement passes and 1 when any fails, so you can fail a CI job on unmet requirements:

multi check || echo "requirements not met"

Drop that into your pipeline to block a merge whenever a requirement regresses.

Next steps

• Check your own repo. Add a CHECKS.md to a real project and start with one or two requirements you care about. The Reference covers multi-check requirements and the full syntax.
• Tune the run. Set the provider, model, effort, and concurrency in the Reference.