Kami · Developers Home GitHub

Developers

Everything an agent needs to drive Kami: one local MCP server, nine content schemas, and a set of deterministic checks that decide whether a document is finished.

01 · Surface

There is no hosted Kami API

Kami is a skill and a template system, not a service. It installs into the agent that uses it and runs on that machine: no account, no API key, no rate limit, no request that leaves the host. There is no REST or GraphQL endpoint to call, and this site publishes no authenticated surface, so nothing here needs OAuth discovery or a token exchange.

The integration surface is therefore local: an MCP server for tool calls, JSON content schemas for structure, and CLI checks for verification. The static files listed at the bottom of this page are the machine-readable index of all of it, and they are generated from the same registry the templates use, so they cannot drift from what ships.

02 · Install

Get the skill

The skill auto-triggers on document requests. No slash command is needed once it is installed.

# Claude Code (v2.1.142+)
/plugin marketplace add tw93/kami
/plugin install kami@kami

# Codex plugin marketplace
codex plugin marketplace add tw93/kami
codex plugin add kami@kami

# Generic agents that read ~/.agents/
npx skills add tw93/kami/plugins/kami -a universal -g -y

# MCP client, from a checkout
claude mcp add kami -- python3 <checkout>/scripts/mcp_server.py

Claude Desktop: download the release asset kami.zip, not GitHub's Source code ZIP, then upload it under Customize > Skills.

03 · MCP

Tools over stdio

Judgment stays in the skill prompt; execution lives in the server. An agent that already knows what it wants can render and verify without loading SKILL.md.

The server speaks newline-delimited JSON-RPC 2.0 on stdin and stdout and has no third-party dependency for the protocol itself. Tools that need WeasyPrint, pypdf, or PyMuPDF surface the install hint as a tool error instead of crashing. Its card, including the protocol version and the tool list, is published at /.well-known/mcp/server-card.json.

04 · Contracts

Content schemas

Each document type has a JSON schema that states its structure and its quality bar. Fill the schema first, lay out second.

Nine schemas live under references/schemas/: changelog, equity-report, landing-page, letter, long-doc, one-pager, portfolio, resume, slides. A new content.json also carries a brief with audience, job, output contract, target, preserve boundary, evidence, and acceptance checks; older IR files remain valid. Validate the content object before layout, then check how much of it actually reached the page:

python3 scripts/build.py --check-content content.json
python3 scripts/build.py --check-content content.json filled.html

The second form reports coverage: fields that exist in the content object but never made it into the document are the most common failure in agent-generated layouts, and they are invisible to a human skim.

05 · Verification

Checks that decide "done"

Run python3 scripts/build.py --help for the authoritative list. Repository-wide checks, python3 scripts/build.py --check, cover template lint, design-token sync, and public-site fact drift.

06 · Catalog

Machine-readable files

Every file below is static, public, and generated from the template registry.