kami · 紙

紙 · かみ - the paper your deliverables land on.

Good content deserves good paper. One design language across eight document types: warm parchment canvas, ink-blue accent, serif-led hierarchy, tight editorial rhythm.

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

Step 0 · Load brand profile (if exists)

Check ~/.config/kami/brand.md (preferred) or ~/.kami/brand.md (legacy fallback). If found, read references/brand-profile.md for the full four-layer application spec (placeholder substitution, session defaults, visual customization, habit notes) and its six guardrails. If no profile exists, continue without interruption.

Key rule: explicit prompt > editorial judgment > habit notes > frontmatter defaults > built-in defaults. Profile fills gaps silently; it never overrides the current conversation.

Step 1 · Decide the language

Match the user's language. Chinese -> *.html / slides.py. English -> *-en.html / slides-en.py. Japanese -> CJK path (.html / slides.py) as best-effort, JP Mincho first, visual QA before shipping. Reference docs are shared English specs.

When ambiguous (e.g. a one-word command like "resume"), ask a one-liner rather than guess.

Always use CHEATSHEET.md and references/*.md for design, writing, production, and diagram guidance.

Step 1.5 · Intent extraction (silent checklist)

Before choosing a template, verify these four dimensions are clear. Do not ask unless 2+ are missing and cannot be inferred from context.

Rules:

• If the conversation already answered a dimension, skip it silently.
• If a dimension can be inferred from the document type (e.g. resume purpose is always "get an interview"), skip it.
• If 2+ dimensions are genuinely unclear, ask in a single compact question (max 2 sub-questions).
• Never ask all four as a checklist. This is a background verification, not a form.

Step 2 · Pick the document type

Changelog vs. release notes: The changelog template above is for styled document output. GitHub release notes are a separate deliverable; use /write with Release Note Template Mode.

Long deck (>20 slides): also read Deck Recipe (design.md section 8).

If unsure, ask a one-liner about the scenario rather than guess.

Diagrams (primitives, not a 7th doc type)

When the user asks for a diagram inside a long-doc / portfolio / slide (not a standalone document), route to assets/diagrams/ rather than a template:

Read references/diagrams.md before drawing - it has the selection guide, kami token map, and the AI-slop anti-pattern table. Extract the <svg> block from the template and drop it into a <figure> inside long-doc / portfolio.

Before drawing, always ask: would a well-written paragraph teach the reader less than this diagram? If no, don't draw.

Auto-select charts from data. When content contains numerical data, choose the chart type and embed it without waiting for the user to specify. Decision tree (first match wins):

When data fits multiple types, prefer the one that shows variance most clearly. Always embed inside a <figure> with a caption that states the insight, not just the data range.

Step 2.1 · Source and material pass

Run this before distilling or filling content when the document depends on facts or materials outside the user's draft. Skip it only for personal drafts where the user already supplied everything needed.

Source check

Trigger when the document mentions a specific company, product, person, release date, version, funding round, metric, market fact, technical spec, or any current fact likely to change.

• Use primary sources before writing: user-provided material, official site, docs, filings, press release, app store page, or repo release
• Keep a short note of source names and dates for facts that drive the document
• If sources conflict or a fact cannot be checked quickly, ask the user instead of choosing silently
• Avoid current-sounding claims such as "latest", "recent", "new", version numbers, launch dates, or financial figures unless they are checked

Material check

Trigger when the document is about a company, product, project, venue, or personal brand.

Confirm the materials that make the subject recognizable before layout:

If a required item is missing, use a compact gap table and ask once. Do not replace missing material with generic imagery, approximate logo drawings, or invented values.

Materials status block

After the material check, output a structured status block before continuing. This is a one-shot transparency display, not a question:

Materials status:
- Logo: OK assets/client-logo.svg
- Brand colors: OK #1B365D mapped to --brand
- Product screenshot: MISSING (proceeding with kami default placeholder)
- UI screenshot: not required for this doc type

Use OK, MISSING, or not required. If a required item is missing and no user input arrived, ask once with the gap table; otherwise continue silently.

Step 2.5 · Distill raw content (if applicable)

Auto-detect whether to distill. Do not ask the user; judge from the input:

When in doubt, run distill. Distill is cheap; rebuilding a misaligned doc is not.

When the user hands over raw material (meeting notes, brain dump, existing doc in different format, chat transcript, scattered points):

1. Extract: pull out every factual claim, number, date, name, source, material reference, and action item
2. Classify: map each extract to the target template's sections (see references/writing.md for section structure per doc type)
3. Gap-check: list what the template needs but the raw content doesn't have - include missing facts, missing proof, and missing materials
4. Ask once: share the gap table with the user. Do not guess to fill gaps.

Example gap-check:

Then proceed to Step 2.6 (slides) or the layout note (all other doc types) with structured, distilled content.

Step 2.6 · Deck pre-flight (slides only)

Skip this step for every doc type except slides.

Before drafting any slide, confirm these six points with the user. Ask all six in one shot, not one at a time:

If the user has already answered any of these in the conversation, skip only those questions.

Step 2.7 · Layout note (transparent, non-blocking)

Before loading specs and filling the template, write a short editor-style note stating the layout intent: template choice, length target, narrative arc, embedded diagrams, material status, and output formats. Match the document's language. Keep it under 80 words, written as prose, not a status panel. Continue immediately after; do not wait.

Example (CN):

排版意图：Equity Report 中文版，2 页 A4。先立论与目标价，进入估值 (DCF 与可比公司)，落于催化剂与风险。中段嵌一张营收趋势折线和 FY26 收入桥瀑布。Logo 已就位，产品图暂缺，header 改走纯文字。输出 HTML 与 PDF。

Example (EN):

Layout intent: Equity Report (EN), two pages A4. Open with thesis and price target, run through valuation (DCF and comparables), close on catalysts and risks. A revenue line chart and an FY26 waterfall sit mid-doc. Logo is in hand; product image is absent, so the header stays text-only. Output: HTML and PDF.

The note is for transparency, not approval. If the user pushes back, adjust; otherwise proceed to Step 3.

Step 3 · Load the right amount of spec

Pick the tier that matches the task. Default to the lowest tier that covers the work.

You can always escalate mid-task if the work turns out to need more than the initial tier.

The full spec files for reference:

• Design: references/design.md
• Writing: references/writing.md
• Production: references/production.md
• Diagrams: references/diagrams.md

Step 4 · Fill content into the template

• Copy the template into your working directory; don't write HTML from scratch
• CSS stays untouched, only edit the body
• Content follows writing.md: data over adjectives, distinctive phrasing over industry clichés
• Avoid patterns listed in references/anti-patterns.md: emptiness, fabrication, mimicry, excess, source gaps, tone contamination
• Before filling, read the quality bar for your document type in writing.md section "Quality bars by document type". Structure is necessary but not sufficient: a resume bullet needs Action + Scope + Result + Business Outcome; an equity report needs variant perception + quantified catalysts; slides need assertion-evidence titles. Meeting the quality bar is as important as filling every placeholder.

Do not generate

These are the most common AI document failures. Cross-reference references/anti-patterns.md for the full list.

• Do not leave placeholder text in the final document ("Lorem ipsum", "[Insert here]", "TBD")
• Do not invent metrics, financial data, or statistics; mark gaps with [DATA NEEDED: description]
• Do not use stock-image descriptions as image placeholders ("A diverse team collaborating in a modern office")
• Do not pad content to fill template slots (a resume with 3 real projects does not need 5 fabricated ones)
• Do not write a paragraph that merely restates its own heading in sentence form

Fill PDF metadata (WeasyPrint reads these into the PDF)

Every template has meta placeholders in <head>. Fill all four before building:

<meta name="generator" content="Kami"> is already fixed in the template; do not change it.

Author inference: build.py automatically sets PDF /Author metadata from:

1. git config user.name (primary)
2. KAMI_AUTHOR environment variable (fallback)
3. "Kami" (final fallback)

For personal documents (resume/letter/portfolio), the HTML <meta name="author"> should match the person's name in the content. For non-personal documents (one-pager/long-doc), leave the placeholder as-is and let the build script infer it.

Step 4.5 · Auto-select output format

Do not ask the user which format to export. Decide from context:

PDF always ships. PPTX follows slides. PNG follows sharing context. The user should never need to think about formats.

Step 5 · Build & verify

python3 scripts/build.py --verify           # build all templates + page count + font check + slides
python3 scripts/build.py --verify resume-en # single target full verification
python3 scripts/build.py --verify slides    # single slide deck verification
python3 scripts/build.py --check-placeholders path/to/filled.html
python3 scripts/build.py --check-density              # page whitespace scanner (skips cover)
python3 scripts/build.py --check            # CSS rule violations only (fast, no build)

Source templates intentionally keep {{...}} fields. Run placeholder checks on completed documents, not on the template library.

Visual anomalies (tag double rectangle, font fallback, page break issues) -> production.md Part 4.

Fonts

Chinese

• Main serif: TsangerJinKai02-W04.ttf (400 weight) + TsangerJinKai02-W05.ttf (500 weight, real bold)
• Templates use dual @font-face declarations: W04 for body text, W05 for headings
• Both files are commercial fonts. Keep them available in the repository for local preview and CDN fallback, but do not bundle them inside Claude Desktop skill ZIPs
• Fallback chain baked into templates: Source Han Serif SC -> Noto Serif CJK SC -> Songti SC -> STSong -> Georgia

Japanese (best-effort)

• Uses CJK template path, no dedicated -ja templates yet
• JP Mincho-first stack: YuMincho -> Hiragino Mincho ProN -> Noto Serif CJK JP -> Source Han Serif JP -> TsangerJinKai02 -> serif
• Visually verify line breaks, punctuation rhythm, and emphasis weight before shipping

English

• Single serif: Charter (system-bundled, macOS/iOS), used for both headlines and body
• No separate sans: --sans: var(--serif), one font per page
• Fallback: Georgia (cross-platform) / Palatino / Times New Roman

Font files next to HTML with relative @font-face paths is the most stable setup. scripts/package-skill.sh excludes TsangerJinKai TTFs from the Claude Desktop ZIP.

Font auto-recovery (Claude Desktop)

Before building Chinese documents, check font files. If missing, download into assets/fonts/:

# Check
test -f assets/fonts/TsangerJinKai02-W04.ttf || {
  curl -fsSL "https://cdn.jsdelivr.net/gh/tw93/Kami@main/assets/fonts/TsangerJinKai02-W04.ttf" \
    -o assets/fonts/TsangerJinKai02-W04.ttf
  curl -fsSL "https://cdn.jsdelivr.net/gh/tw93/Kami@main/assets/fonts/TsangerJinKai02-W05.ttf" \
    -o assets/fonts/TsangerJinKai02-W05.ttf
}

Run once before building. If network is unavailable, WeasyPrint falls back to Source Han Serif SC.

Feedback protocol

When the user gives vague visual feedback ("looks off", "太挤了", "not elegant"), do not guess. Ask back with current values:

Template response: "X is currently set to Y. Would you like (a) [specific alternative within spec] or (b) [another option]?"

Never say "I'll adjust the spacing" without naming the exact property and its new value.

When not to use this skill

• User explicitly wants Material / Fluent / Tailwind default - different design language
• Need dark / cyberpunk / futurist aesthetic (this is deliberately anti-future)
• Need saturated multi-color (this has one accent)
• Need cartoon / animation / illustration style (this is editorial)
• Web dynamic app UI (this is for print / static documents)

Next: apply Step 3's tier table to decide what to read, then copy the matching template and start filling.