Kami Document Generation Engine

repository·main·Indexed 11 days ago

https://github.com/tw93/Kami

A constraint-based design system and document generation engine for AI agents. Kami transforms raw content into professionally formatted, print-ready documents—including resumes, reports, and slide decks—using a consistent aesthetic of parchment backgrounds and ink-blue accents. It features eight primary templates, 18 inline SVG diagram types, and support for Marp, WeasyPrint, and python-pptx. Compatible with Claude Code, Claude Desktop, and Codex.

Tokens
83.7K
Snippets
137
Records
333
Agent score
94%

What's inside Kami

  1. Overview of the Kami skill

    main

    Kami (紙 · かみ) is a skill designed to typeset professional documents and product landing pages, including resumes, one-pagers, white papers, letters, portfolios, slide decks, and landing pages. It follows a specific design language: a warm parchment canvas, ink-blue accents, and a serif-led hierarchy.

    It is part of the Kaku · Waza · Kami suite, where Kami specifically handles document delivery.

    Triggers: Kami is triggered by requests such as:

    • "做 PDF / 排版 / 一页纸 / 白皮书 / 作品集 / 简历 / PPT / slides / Marp / markdown slides / マークダウンのスライド / 落地页 / 官网 / landing page / product page"
    • "build me a resume / make a one-pager / design a slide deck / turn this into a PDF / make this presentable / create a landing page"
  2. What is Kami?

    main

    Kami is a constraint-based design system for documents intended to be written by AI agents and read by humans. Unlike a template gallery, it enforces a fixed set of visual constraints to prevent AI models from making poor layout decisions (such as inconsistent accent colors or improper typography).

    Key features include:

    • Fixed Visual Constraints: Uses a parchment canvas (#f5f4ed), a single ink-blue accent (#1B365D), serif-led hierarchy, and editorial whitespace.
    • Multi-format Export: Produces HTML that can be exported to PDF, PNG, or editable PPTX.
    • Document Types: Includes templates for one-pagers, letters, long documents, portfolios, resumes, slides, equity reports, and changelogs.
    • Diagrams: Provides 18 inline SVG diagram types (e.g., architecture, flowchart, candlestick, Venn).
    • Content Validation: Ships nine JSON content schemas and a set of checks to detect common AI failures like unfilled placeholders, markdown syntax leaks, or poor page breaks.
  3. Overview of Kami Design and Templates

    main

    Kami is a constraint system for generating high-quality printed documents. It uses a specific design language: a warm parchment canvas (#f5f4ed) with ink blue (#1B365D) accents and serif typography.

    Core Capabilities

    • Templates: Eight primary templates (One-Pager, Long Doc, Letter, Portfolio, Resume, Slides, Equity Report, and Changelog) plus a Landing Page system. Supports EN, CN, and KO.
    • Diagrams: 18 inline SVG types. Supports Mermaid text which is re-themed to the Kami palette via scripts/mermaid_normalize.py.
    • Slides: Supports WeasyPrint (HTML to PDF) by default, python-pptx for editable PPTX on request, and Marp for Markdown-first decks.
    • Code: Uses Pygments for syntax highlighting (requires Pygments to be installed; otherwise, code is monochrome).
    • Print Variants: While parchment is the default, an opt-in white-paper variant is available for home/office printers to save ink while maintaining hierarchy.
  4. Styling Mermaid diagrams with Kami

    main

    Mermaid text is converted into Kami-styled diagrams using beautiful-mermaid and the scripts/mermaid_normalize.py script. The styling follows the Kami design system: a parchment canvas, warm neutrals, serif text (with CJK fallback), and a single chromatic accent (ink-blue) used only for focal elements.

    Key technical details:

    • Theme Mapping: The theme maps beautiful-mermaid's seven color roles to the Kami canonical palette. The source of truth is references/mermaid-theme.json, which is kept in sync with tokens.json.
    • Color Normalization: The normalizer converts color-mix() derivations into static hex values (e.g., #dad9d3) to ensure shades remain warm and do not introduce cool grays.
    • PDF Support: Flowchart, state, sequence, class, and ER diagrams are supported in PDF.
    • Browser-only Feature: xychart-beta is only supported in browsers because it relies on <style> class selectors that WeasyPrint cannot apply.
  5. Core Principles of the Kami Design System

    main

    The Kami design system is a constraint system for print, focused on stability, clarity, and readability. Its aesthetic is defined by a warm parchment canvas, ink-blue accents, and serif-driven hierarchy.

    Key Invariants:

    • Background: Use parchment #f5f4ed, never pure white.
    • Accent: Use a single ink-blue accent #1B365D. Avoid second chromatic colors.
    • Grays: All grays must be warm-toned (yellow-brown undertone); avoid cool blue-grays.
    • Typography: Use serif for English headlines and body. For Chinese, use serif headlines and sans body. Sans is reserved for UI elements (labels, eyebrows, meta).
    • Weights: Serif weight is locked at 500; do not use bold (except for specific heading weights).
    • No Italics in Print: Do not use font-style: italic in any PDF template or demo. The only exception is the screen-only landing page.
    • Tag Backgrounds: Must be solid hex colors, never rgba(), to avoid rendering artifacts in WeasyPrint.
  6. Use Kami to brief AI image renderers

    main

    Kami's design constraints extend beyond documents to include briefs for AI image renderers. This allows you to generate illustrations that match the Kami aesthetic (e.g., specific color palettes, stroke styles, and typography) in a single pass.

    When the host environment does not have built-in image generation, Kami provides a complete text brief that you can copy and paste into an external image model (like ChatGPT/DALL-E) to achieve a consistent look.

    Redraw this as a clean editorial diagram. Background: warm parchment (#f5f4ed), never pure white. One accent only, ink blue (#1B365D); everything else in warm gray with a yellow-brown undertone, no other colors. Thin single-line geometric strokes and simple flat icons. No gradients, no drop shadows, no 3D. Labels in a serif typeface. Generous whitespace, calm and composed, like a figure in a well-typeset report.
  7. Core quality rules by document type

    main

    Follow these single most important rules for each document type to maintain Kami quality standards:

    DocumentCore quality rule
    ResumeEvery bullet: Action + Scope + Measurable Result + Business Outcome
    PortfolioOpen with the problem and stakes, not the project name
    SlidesSlide titles are full sentences (assertions), not topic labels
    Equity ReportLead with variant perception: what you see that the market doesn't
    Long DocumentEach chapter claim paragraph must survive the "so what?" test
    One-PagerMetrics are the headline; if the 4 cards don't tell the story, the metrics are wrong
    LetterFirst paragraph states purpose in one sentence
    ChangelogOne sentence per change, verb-led, user-facing language
  8. Embed diagrams and charts in documents

    main

    When a user requests a diagram inside an existing document (like a long-doc or portfolio), do not use a separate template. Instead, route to assets/diagrams/ and extract the <svg> block into a <figure> tag.

    Diagram Routing:

    • Architecture boards: For full-system panoramas, control planes, or roadmaps.
    • Maintained diagram assets: For diagrams existing in a user's repo (e.g., README figures). Keep the index.html + PNG + prompt.md trio consistent.
    • Illustration briefs: For standalone raster illustrations or redraws of photos/screenshots.

    Automatic Chart Selection: When content contains numerical data, automatically select and embed a chart type:

    • Donut charts: Use only for $\le$ 6 items sharing a total.
    • Horizontal bar charts: Use for $\ge$ 7 items in a donut-style distribution.
    • Bar charts: Use for single time series where absolute counts dominate (rather than rates).
    • Line charts: Use for time series where rates are the focus.

    Always embed charts inside a <figure> with a caption stating the insight, not just the data range.

  9. Follow icon style guidelines

    main

    Icons in Kami diagrams must be drawn using basic SVG primitives (rect, circle, line, path) rather than icon fonts or sprites.

    Style Rules:

    • Stroke: Single line, 1pt to 1.5pt stroke weight. Maintain consistency within a single diagram.
    • No Fills/Effects: No fills (except for focal icons), no drop shadows, no gradients, and no 3D/glassmorphism.
    • Tone: Editorial schematic style. Avoid emojis, mascots, or expressive characters. Use minimal line drawings for humans if absolutely necessary.
    • Focal Icons: May use --brand stroke or fill, but the total ink-blue area must respect a 5% cap.

    Canonical Shapes:

    • Terminal / CLI: Rounded rectangle with three dots at top-left.
    • Document / spec: Rectangle with three short horizontal lines.
    • Checklist / verification: Rectangle with two check marks.
    • Gear / system: 8-tooth gear outline.
    • Magnifier / inspect: Circle with a 45° handle.
    • Shield / safety: Shield silhouette.
    • Cloud / hosted service: Three-arc cloud outline.
    • Chip / hardware: Square with leg lines on four sides.
    • GPU / compute rack: Rectangular stack with port indicators.
  10. Configure PPTX dimensions and safe zones

    main

    When generating PowerPoint presentations, use the following dimension standards to ensure content is not cropped by projectors:

    • 16:9 widescreen (preferred): 13.33 × 7.5 inch
    • 4:3 traditional: 10 × 7.5 inch
    • Safe zone: Maintain a 0.5 inch margin on all sides and an additional 0.3 inch at the bottom for page numbers.
  11. Write effective node titles and copy

    main

    Follow these rules for text within diagrams to reduce cognitive load:

    Naming Convention

    Node titles should follow the pattern: Function first, Protocol noun second. Avoid using only the protocol noun.

    Weak (Noun only)Strong (Function + Noun)
    Registry插件注册表 Registry
    Queue任务队列 Queue
    Policy Hook写动作准入 Policy Hook
    Inbox任务收件箱 Inbox

    Copy Constraints

    • Scope: Use copy for objects, boundaries, and actions only. Keep arguments in the accompanying prose.
    • CJK Usage: Use short labels with commas, slashes, or semicolons. Never use the CJK full stop (。) inside a node. If a sentence is required, it belongs in the document prose, not the diagram.
  12. Apply the spacing scale

    main

    Kami uses a base unit of 4pt (which translates to 4px on screen). Use the following tier scale to maintain consistent rhythm in layouts:

    TierValueUse
    xs2-3ptInline adjacent elements
    sm4-5ptTag padding, dense layout
    md8-10ptComponent interior
    lg16-20ptBetween components / card padding
    xl24-32ptSection-title margins
    2xl40-60ptBetween major sections
    3xl80-120ptBetween chapters (long docs)

    Layout Principles

    • Proximity Law: To ensure a heading belongs to the content that follows, the gap UNDER a section head must be clearly smaller than the gap ABOVE it (ideally by 2x or more).
    • Heading Density: If a heading block feels cramped, adjust its internal spacing (e.g., eyebrow-to-title or title-to-lede) rather than the macro section gaps.
    • Two-column Rows: For image-plus-copy layouts, cap both tracks and justify them to the edges. Instead of letting the copy column grow freely and leaving an empty far edge, push the slack into the gutter so both outer edges align with the container.
    /* Base unit reference */
    /* 4pt = 4px on screen */