Create content with kapi as the checker

Goal: when you are authoring new content (there is no frozen source to edit; you are writing the document), use kapi as the checker. You write; kapi parses what you wrote, holds it to the voice profile and terminology, and tells you what to fix. No AI provider is involved. This is the author → parse → check loop, the create-side counterpart of Edit content, where the source is fixed and you edit existing blocks.

▶

Walkthrough videoPending recording

A short walkthrough drafting a Markdown page, parsing it back with kapi inspect as the first check, running a voice-and-terminology gate, and landing a content fix and the approved term behind it in one kapi apply.

View scene script ↗

Desktop

Write in your own editor; the desktop is the checker beside it.

1. Track the draft. Add the file to a project collection (or push it through a quick tool for a one-off); the collection card shows the format kapi detected for it.
2. Parse it as the first check. Open it: Preview renders the document as the engine reads it; Blocks lists what you actually wrote, block by block. A missing or merged block means the source needs fixing.
3. Gate on voice and terminology. Run on everything on the project's Overview runs the project's bound rules, and its findings count opens what they found; each finding names its rule and block, with the suggested wording.
4. Revise and re-run until no failing finding remains.

Agent (Claude)

With kapi connected, the assistant is the author and kapi stays the checker:

Draft a release-notes page for the export feature, on brand, using our approved terms.

It writes to the voice and wording kapi states in CLAUDE.md and AGENTS.md, and looks up a term those files do not list with kapi terms lookup, so the first draft is already close. Then it loops check_file → revise until the gate is green. When a check flags a wording that should become a rule, it fixes the draft and records the rule as a suggestion for you to keep, as closing the loop describes.

CLI

Author in a generative format, one kapi can produce from content alone (Markdown, HTML, JSON, YAML, …):

kapi formats --json | jq -r '.formats[] | select(.generative) | .name'

Binary office formats (.docx, .pptx, .xlsx) are editable but not generative: start from an existing file and edit it in place instead. Parse the draft back as the first verification that it is well-formed and says what you intend, then gate it:

kapi stats draft.md --json                            # size and structure survey
kapi inspect draft.md --jsonl                         # block by block, as a reader sees it
kapi check draft.md --profile-file voice.yaml         # one-off; exit 0 pass, 3 gate failed
kapi check --ship                                     # in a project: every bound gate

Load the voice and approved wording before writing so the first draft is already close:

kapi context docs/page.md                 # the voice and words that apply to the file
kapi terms lookup "dashboard" -t en    # the approved term

Fix what the check flags (edit the source directly, or route the fix through kapi apply when you want the round-trip and its guards; see Edit content) and re-check until green.

Close the loop: fix the content and the rule together

When a check flags a term, the durable fix is two changes: correct this draft and record the rule so future drafts are checked against it. Both are operations in one kapi apply change set (requires a kapi project), with the block's ref and rev from kapi inspect draft.md --jsonl:

{"ops": [
  {"op": "replace_text", "at": {"doc": "draft.md", "block": "setup/p#2"}, "if_match": "r:a1b2c3d4e5f60718",
   "edits": [{"find": "control panel", "text": "dashboard"}]},
  {"op": "term", "action": "upsert", "term": "dashboard", "locale": "en", "status": "preferred", "replaces": "control panel"}
]}

kapi apply change.json

The content operation rewrites the block with the file's structure kept, and is refused if the block changed since you read it; the term operation, applied after it, is written into the project store's terms tables and recorded as a decision, so kapi context log names the new term and the next kapi check enforces it. The change set lands whole or not at all: when an operation is refused, nothing is written, and kapi apply names the refusal and exits non-zero. Resending a change set that landed is safe, because an operation already in place reports unchanged. apply also accepts memory and recipe operations; see Keep source on brand for a term operation that adds a word rule.

Writing a rule directly is your decision, so an assistant's term, memory and recipe operations are refused, and the change set that holds them, from its shell and through MCP alike. The assistant applies the content operation on its own and records the rule as a suggestion with kapi context note --from <old> --to <new> --suggest, which you keep with kapi context review (Growing context).

Next

• Edit content: the edit-existing loop, the change set's shape, and what refuses an edit.
• Keep source on brand: the voice check and the term operation that adds a word rule.
• Checks: the kapi.check/v2 report model and the gate exit codes.