Back to catalog

book-writing-gdoc

Write books with Obsidian review and markdown production.

Category ✍️ Writing

Book Writing via Obsidian + Markdown

Write, review, and produce a book using markdown files in Obsidian as both the writing workspace and the production source.

When to Use

  • Writing a book or long-form guide (10+ chapters)
  • Author reads and comments in Obsidian (synced via Dropbox)
  • Need style consistency across multiple chapters
  • Need a clean path from draft to PDF/Gumroad

Architecture

plan.md          → Structure, decisions (source of truth for what to write)
task.md          → Chapter-level checklist (source of truth for progress)
progress.md      → Session log, thread handover
*.md files       → Writing workspace AND production source
reviews/         → Version snapshots + comment logs

Comment Format

Author uses Obsidian callouts in markdown files:

> [!hh] Change this paragraph to focus on stock investing
> [!hermes] Should we list some skills here?

Place callout directly after the paragraph it refers to. > [!hh] for corrections, > [!hermes] for questions.

Workflow

1. Plan

Create plan.md with TOC, structure, decisions. Author reviews and approves.

2. Write (batched)

Write 2-3 chapters per batch:

  • Read source material
  • Apply style rules (blogging skill: Minto Pyramid, Flesch 65-70, ASD-STE100, I-voice)
  • Write to markdown files in book directory
  • Dropbox syncs to author's Mac
  • Author opens in Obsidian, reads, leaves > [!hh] callout comments

3. Review

Comments can arrive two ways:

  • Obsidian callouts in the markdown files: > [!hh] or > [!hermes]
  • Slack messages referencing the file (e.g., "on chapter 2, I left comments")

Same workflow either way.

Before processing:

1. Save v1 snapshots: cp .md reviews/round-N-v1-.md

2. Extract comments: grep -n "> \\[!hh\\]\\|> \\[!hermes\\]" *.md > reviews/round-N-comments.md

(Skip this step if comments came via Slack — read the Slack messages instead)

Processing:

1. Read each callout or Slack message, understand feedback

2. Apply fixes to markdown files

3. Remove callout if present (comment addressed)

4. Save v2 snapshots: cp .md reviews/round-N-v2-.md

After processing — update tracking files:

1. progress.md: Add a dated "Fixes applied after round N" section listing every change made

2. progress.md: Update the "Awaiting" line to reflect what's done vs. what's still pending

3. task.md: Check off any chapter that has been fully reviewed and approved

Result: complete audit trail — what text was, what author said, what it became. Tracking files stay current.

4. Repeat until all chapters written

5. Format

Export markdown → PDF (pandoc). Cover, typography, layout.

6. Produce

Final editorial pass → PDF → Gumroad.

Finding Comments

grep -n "> \[!hh\]\|> \[!hermes\]" books/<project>/*.md

Style Consistency

  • Blogging skill loaded for every chapter write
  • No-ai-slop applied during writing, not just editing
  • Author reviews each batch for voice
  • Published blog post serves as style anchor

Thread Handover

New thread opens with: plan path, task path, progress path, chapter list, reviews path, current phase, pending decisions.

Pitfalls

1. Callout placement matters. Put the callout directly after the paragraph it refers to, not at the end of the file.

2. One callout per issue. Don't bundle multiple feedback items into one callout.

3. Remove callouts after addressing. Don't leave resolved comments in the file.

4. Version snapshots before every review round. Without them, you lose the before/after comparison.