Check content like tests

Goal: verify content before it ships — over-long strings, forbidden phrases, brand drift, structural faults — with a repeatable gate: structured findings, a pass/fail, and an exit code. kapi check never modifies content; fixing flagged blocks is kapi apply's job. For the Report model and every check family, see Checks.

Desktop

Open your project and switch to the Checks view.

1. Run the checkset. Kapi runs the project's bound rules — hygiene, length, patterns, and brand vocabulary when a profile is bound — over the tracked content.
2. Read the findings. Each finding names its rule, severity, and the exact block; click through to see the flagged text in context.
3. Fix and re-run. Edit the source, re-run, and watch the findings clear. The same gate result the CLI reports is what the panel shows.

▣

ScreenshotPending capture

The Checks view: a findings list grouped by rule and severity, with a block-level detail pane and the pass/fail gate summary.

View scene script ↗

Agent (Claude)

With kapi connected, ask for the outcome:

Go through docs/ and fix anything that fails our content rules.

The assistant runs the loop itself: check_file returns the Report (stable rule ids, block locations), it rewrites the flagged blocks, lands them with apply_edits (content-hash guarded, structure preserved), and re-checks until the gate is green. Because rule ids are stable across runs, it can tell a fixed finding from a new one — and stops when the Report is clean.

CLI

Point kapi check at files; add constraints inline or from a profile:

kapi check src/locales/en.json                        # default checkset
kapi check release-notes.md --max-chars 280 --forbid "click here"
kapi check content/*.md --pack marketing-blog          # built-in starter pack
kapi check blog-post.md --profile-file brand/voice.yaml

--json emits the structured kapi.check/v1 Report — pass, a 0–100 score, a gate, one finding per stable rule id, each anchored to a block:

{
  "schema": "kapi.check/v1",
  "pass": false,
  "summary": { "score": 74, "critical": 0, "major": 2, "minor": 3 },
  "findings": [
    {
      "rule": "length.max-chars-exceeded",
      "severity": "major",
      "message": "Block exceeds the 120-character limit (148 chars).",
      "location": { "file": "src/locales/en.json", "block": "onboarding.welcome" }
    }
  ]
}

Field-by-field, the Report is documented in Checks; the flags in the check reference.

Exit codes are the gate: 0 pass, 3 gate failed, 1 operational error — so kapi check drops straight into CI. --strict fails on any critical or major finding; --lenient and --no-fail loosen it for report-only sweeps. --validate report|strict folds reader structure/encoding findings into the same Report.

Bilingual checks (placeholder integrity, do-not-translate, terminology) are opt-in: add --target <file> --target-lang <lang> to check a translation against its source.

In a project: the ship gate

Inside a .kapi project, kapi check with no file arguments checks the project's declared content with the recipe's bound rules. kapi check --ship is the project gate mode: it runs the bound quality gates (brand, terminology, QA) plus the ship/source coverage gates over the project's content, and exits non-zero when any gate is unmet — the pre-release bar. Ordinary builds never fail on target drift; --ship is the explicit enforcement point. See Ship gates & CI.

The two are different bars, not variants of one: a bare kapi check <files> gates the files you name (a checkset over content — the test runner), while --ship gates the project against its ship_gates: coverage thresholds across every target language (the release bar).

Next

• Ship gates & CI — kapi check --ship on every PR.
• Edit content — the inspect → edit → apply loop that fixes what a check flags.
• Content governance for AI — the rules that make agent output pass.
• Checks — the Report schema and every check family.