AI Skill Report Card

Designing Book Interior Typography

A88·Aug 26, 2026·Source: Web
Markdown
--- name: designing-book-interior-typography description: Guides complete book interior design workflow from typography exploration through council-style decision making to functional HTML/CSS/JS layout prototypes and technical specification documents. Use when designing print book interiors, selecting font pairings for novels/manuscripts, creating page layout prototypes with precise dimensions (mm/cm), or producing typography specification sheets with extractable SVG decorations. ---
14 / 15

Given cover description + genre + constraints, execute 4 phases sequentially:

Phase 1: Generate 5 font-pairing options (title/author/body)
Phase 2: Simulate 5-expert council debate → pick 1 winning combo
Phase 3: Build working HTML/CSS/JS prototype (4 pages, 2 spreads)
Phase 4: Build spec document (full layout + typo table + copyable SVGs)

Never skip phases or merge them into one response unless the user explicitly asks for a condensed output. Each phase's output feeds the next.

Recommendation
Add a third example showing a failure/pitfall scenario (e.g., a font missing italic being caught and disqualified) to reinforce the 'bad outcome' half of examples
15 / 15
Progress:
- [ ] Phase 1: Typography exploration (5 combos)
- [ ] Phase 2: Council decision (5 agents debate, pick 1)
- [ ] Phase 3: 4-page HTML/CSS/JS prototype
- [ ] Phase 4: Spec doc with typo table + pure SVG dropdowns

Phase 1 — Typography Exploration

For each of 5 combos, specify:

  • Title font (Google Fonts) — must render well in UPPERCASE and Title Case
  • Author font — harmonizes with title (contrast in weight/style, not competing)
  • Body font — must have Regular, Bold, Italic in its Google Fonts family (verify this before proposing; a body font without italic is disqualified)

Requirements per combo:

  • Reject overused fonts (Playfair Display + Lato, Merriweather + Open Sans, etc.) unless genre specifically demands convention (e.g., academic non-fiction).
  • Apply any negative constraints from input immediately (e.g., banned fonts) — filter these out before drafting, don't propose then retract.
  • Show a mini visual mockup in text form:
    JUDUL BUKU DALAM UPPERCASE
    (Font: X, weight 700, size ~28-36pt equivalent)
    
    oleh Nama Penulis
    (Font: Y, italic or small-caps, size ~12pt)
    
    Body text lorem ipsum dolor sit amet...
    (Font: Z, Regular 11pt, leading 1.6)
    
  • Justify each combo against: genre mood, cover's visual weight (serif/sans, geometric/organic, era), and target reader expectations (YA vs. literary fiction vs. thriller read very differently).

Phase 2 — Council Decision

Structure as a real debate, not a rubber-stamp. Assign distinct concerns:

AgentConcern
Art DirectorCover-to-interior visual continuity, brand feel
Lead TypographerKerning, x-height, contrast ratio between title/body, font pairing theory
Editorial DesignerGenre convention vs. differentiation, reader expectation
Accessibility SpecialistLegibility at body size, line length (CPL 45-75), contrast, dyslexia-friendliness if relevant
Production EngineerFont licensing (must be Google Fonts, free for commercial print), variable font support, file weight for future digital conversion
  • Each agent must raise at least one objection to at least one combo (no combo should sail through unchallenged).
  • Resolve conflicts explicitly — e.g., "Art Director prefers Combo 3 for mood, but Accessibility flags its body font's low x-height; council compromises by keeping Combo 3's display font but swapping body to Combo 2's."
  • End with a clear verdict: Winning Combo, final font trio locked, with one-paragraph rationale synthesizing all 5 viewpoints.

Phase 3 — 4-Page Prototype

Single self-contained HTML file (inline <style> and <script>).

Hard specs (do not deviate unless user overrides):

  • Page size: 148mm x 210mm (or user's custom size) using CSS @media print + on-screen mm-unit boxes with box-shadow to simulate paper on a neutral gray/dark background.
  • Margin: 20mm all sides via padding on inner content box, not the page box itself (page box = trim size, content box = trim minus margins).
  • Layout: 2 spreads shown side by side (page 1-2, then page 3-4), each spread = two page divs in a flex row, verso (even) on left, recto (odd) on right.
  • Color: strictly #000/#fff/grayscale. No color accents.
  • Body paragraph style: first paragraph of chapter/section uses drop cap (CSS ::first-letter or a wrapping span, 3-line drop), subsequent paragraphs use first-line indent (no space between paragraphs), justified text with reasonable hyphenation (hyphens: auto).
  • Decoration: one elegant recurring motif consistent with cover mood (geometric line, minimal rule, small custom SVG glyph) — explicitly avoid ❦ or any default "fleuron" unless user asks for one. Motif appears at chapter openings and/or page footers.
  • Page numbers: styled with a small decorative flourish (thin rules flanking the number, or a custom small SVG mark) — recto numbers bottom-right, verso bottom-left (standard book convention).
  • Include minimal JS only if it adds real value (e.g., toggle between screen-preview mode and print-accurate mode, or a button to jump between spreads). Don't force JS if pure CSS suffices.

Deliver as one code block, ready to paste and open in browser.

Phase 4 — Specification Document

Single HTML file, sections in this order:

  1. Full layout render — reuse Phase 3's 4-page prototype embedded/iframed or duplicated inline.
  2. Typography table — one row per text role (Chapter Title, Author Byline, Body Text, Drop Cap, Page Number, Running Header/Footer, Folio, etc.) with columns: | Element | Font Family | Weight/Style | Size (pt & px) | Line Height | Letter Spacing | Notes |
  3. SVG decoration dropdowns — use native <details><summary> (no JS framework needed) per decorative element, each with two copy-ready blocks:
    HTML
    <!-- Black variant --> <svg>...fill="#000"...</svg> <!-- White variant --> <svg>...fill="#fff"...</svg>
    SVGs must be pure/inline (viewBox set, no external refs, no <style> classes that only work in the doc's own CSS — inline fill/stroke attributes only, so they paste cleanly elsewhere).
Recommendation
Description is slightly long/dense—could be tightened to lead with the trigger conditions more crisply
16 / 20

Example 1: Input: Cover = dark minimalist geometric line art, Genre = literary fiction/adult, Constraint = no Syne, no ❦ Output: Phase 1 proposes combos like Fraunces (title) + Space Grotesk (author) + Newsreader (body) — high contrast serif display against geometric sans byline, warm literary body serif with full italic support. Phase 2 council flags Fraunces' heavy optical sizing needs care at small trim sizes; resolves by locking display weight to 400 for cover echo but 600 for interior chapter openers. Phase 3/4 use a thin diagonal line motif (echoing cover's geometric lines) instead of any fleuron.

Example 2: Input: Cover = pastel illustrated YA fantasy, Genre = YA fantasy Output: Combos lean toward friendlier serifs (Literata, Bitter) paired with rounded sans for author name (Fraunces excluded here as too somber); council prioritizes Accessibility Specialist's concerns since YA audience skews toward reluctant/young readers — locks larger body size (11.5-12pt) and generous leading (1.7).

Recommendation
Consider adding a brief note on how to handle non-Latin scripts or RTL languages if genre/market requires it, since hyphenation lang attribute is mentioned but broader localization isn't addressed
  • Always verify a body font's Google Fonts page actually lists Italic and Bold before committing — many "elegant" serifs only ship Regular.
  • Keep CPL (characters per line) in body text between 45-75 by calculating column width against chosen font size — adjust margins or size if a spec produces walls of text.
  • Drop caps: constrain to 2-4 lines deep; taller breaks vertical rhythm.
  • When user uploads a cover image, describe what you infer (mood, era, geometric vs organic) before proposing fonts — ties Phase 1 justification to real visual evidence, not generic claims.
  • Treat "custom size" input literally in all CSS mm values — don't default back to 148x210 if user specified otherwise.
  • For production engineer's licensing concern: confirm every proposed font is actually on Google Fonts (not just "Google Fonts style") to guarantee free commercial use.
  • Don't let Phase 2's "debate" be decorative — if all 5 agents agree instantly with no tension, rewrite to surface real trade-offs.
  • Don't use px for physical page dimensions in the print-accurate view — use mm or cm so Phase 3 prototype is dimensionally trustworthy, not just visually approximate.
  • Don't embed default browser fonts as fallback without matching metrics (e.g., don't fallback serif title to Georgia if x-height differs wildly) — pick fallbacks that won't break layout if Google Fonts CDN fails.
  • Don't forget hyphenation language attribute (lang="id" or appropriate) — hyphens: auto silently does nothing without a matching lang on the html/body element.
  • Don't produce SVGs with CSS classes dependent on the parent document's stylesheet — Phase 4's whole point is copy-paste portability; keep styling inline on the SVG itself.
  • Don't ignore explicit negative constraints from input — scan them first and filter Phase 1 options before drafting, not after.
0
Grade AAI Skill Framework
Scorecard
Criteria Breakdown
Quick Start
14/15
Workflow
15/15
Examples
16/20
Completeness
19/20
Format
14/15
Conciseness
13/15