Kami skill

---
name: kami
description: 'Typeset professional documents with Kami templates: resumes, one-pagers, white papers, letters, portfolios, and slide decks. Use when asked to 做 PDF / 排版 / 简历 / 一页纸 / PPT / slides, or to create a Kami landing page. Not for auditing or restyling an existing product site.'
---

# kami · 紙

**紙 · かみ** means paper in Japanese.

Good content deserves good paper. Use Kami’s templates and layout rules to create documents and landing pages with serif fonts, warm backgrounds, and ink-blue accents.

Part of `Kaku · Waza · Kami` - Kaku writes code, Waza drills habits, **Kami delivers documents**.

Commands and paths below are relative to this skill's directory. Keep the document in the user's working directory and call the scripts from there by their full path (`python3 <skill>/scripts/build.py ...`); relative file arguments resolve from your working directory first.

**Update check (non-blocking).** At the start of a task, run `bash scripts/check-update.sh`. It keeps a local daily marker and, at most once a day, reads Kami's latest published GitHub Release; it uploads no document or task content and stays silent when offline or sandboxed. When it prints a line about a newer Kami, relay it and continue.

**Brand profile.** If `~/.config/kami/brand.md` (or the legacy `~/.kami/brand.md`) exists, read `references/brand-profile.md` and apply it. Precedence: explicit prompt > editorial judgment > habit notes > frontmatter defaults > built-in defaults. The profile fills gaps silently and never overrides the current conversation. When the user names another project as the visual reference, run the style scan in the same file. When they give only a brand website, `python3 scripts/brand_extract.py <url>` drafts a profile; show the draft and use it for this document only after they accept it.

## 1 · Lock the contract

Before creating or changing an output, lock six things: language, template, output formats, page or length target, visual acceptance, and the verification command. Infer them from the request, then state the contract to the user in one short line in their language (template, length, formats, the figures you plan, any missing material) and continue without waiting. If they push back, adjust.

**Question budget.** Infer first. Ask at most once, in one compact question with at most two parts, and only when two or more of purpose, audience, hard constraints, or success are genuinely unresolvable, or two templates genuinely both fit. Otherwise take the smallest reasonable assumption and report it at the end.

Route by the artifact's current state:

| Current task | Mode | Contract |
|---|---|---|
| New document or substantial restructuring | **New document** | Lock the contract, write `content.json` with `brief` + `content`, then fill and deliver |
| Text replacement, translation, or factual correction in an existing artifact | **Content-only** | Preserve CSS and layout unless the new copy proves a fit defect |
| User supplies a render or screenshot and rejects how it looks | **Visual repair** | Treat the render as the brief; follow «Feedback protocol» |
| Standalone generated illustration, cover, social card, or redraw | **Generated asset** | Lock the semantic brief before pixels (`references/diagrams.md` section 11); preserve accepted parts across iterations |

Use the nearest existing template and check. Do not add a template, shared CSS layer, dependency, script flag, or optional mode unless the request cannot be met without it.

### Language

| User language | HTML templates | Slides (PDF default) | Slides (PPTX, only when an editable deck is requested) | Slides (Marp) |
|---|---|---|---|---|