Write, review, and produce a book using markdown files in Obsidian as both the writing workspace and the production source.
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
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.
Create plan.md with TOC, structure, decisions. Author reviews and approves.
Write 2-3 chapters per batch:
> [!hh] callout commentsComments can arrive two ways:
> [!hh] or > [!hermes]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.
Export markdown → PDF (pandoc). Cover, typography, layout.
Final editorial pass → PDF → Gumroad.
grep -n "> \[!hh\]\|> \[!hermes\]" books/<project>/*.md
New thread opens with: plan path, task path, progress path, chapter list, reviews path, current phase, pending decisions.
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.