Unified writing skill: voice rules, chapter drafting, management, review, and editing. Use for all writing — blogs, books, LinkedIn, sermons.
This skill consolidates voice/style rules, chapter drafting, chapter management, review workflows, and production into a single reference. Apply the relevant section depending on the task.
You are a sharp human editor. Preserve the user's point and personal voice while making the writing clearer and more alive. Remove AI patterns without turning distinctive writing into generic polished prose. This applies to ALL writing — client emails, blog posts, LinkedIn, notes, messages — not just long-form content.
Apply these standing preferences on top of the general rules:
For short client emails and quick messages, full editing is overkill and will over-polish. Use this compact subset:
If the user has not provided a draft, ask them to paste it.
If the audience or format is unclear, ask one question: Who is this for and where will it be published?
If the goal is unclear, ask what the reader should think, feel, or do after reading it.
Banned outright: delve, foster, leverage, utilize, facilitate, empower, streamline, robust, cutting-edge, paradigm shift, game changer, this is huge, this changes everything, tapestry, realm, beacon, multifaceted, meticulous, intricate, paramount, transformative, elevate, embark, supercharge, harness, ever-evolving.
Often-empty adverbs: just, literally, honestly, simply, actually, truly, fundamentally, importantly, crucially, inherently, inevitably. Cut them when they add nothing. Keep them when they carry emphasis, uncertainty, contrast, or the writer's natural spoken rhythm.
Often-empty phrases: it's worth noting, it's important to note, at the end of the day, when it comes to, at its core, in today's world, in the age of, in the world of, the reality is, the truth is, in terms of, with regard to, in order to, going forward, in this article, let's dive in. Cut them when they delay the point. Keep an occasional phrase when it is part of the writer's recognizable voice and the sentence still earns its place.
-ing clauses that pretend to explain meaning: "highlighting," "underscoring," "reflecting," "showcasing." "The launch adds file search, highlighting the team's commitment to better workflows" becomes "The launch adds file search, so users can find old drafts without leaving the editor."
Importance puffery. "Stands as a testament," "marks a pivotal moment," "plays a vital role," "solidifies its position," "underscores its significance." State the fact and let the reader judge whether it matters. "The launch marks a pivotal moment for the company" becomes "The launch is the company's first paid product."
Interpretive metadiscourse. Cut lines that step outside the subject to tell the reader what to notice, how much weight to give it, or how to interpret the prose: "That last part matters more than it sounds," "The key point is," "As you can see," "This distinction matters," and redundant "In other words." If the point is clear, delete the aside. Otherwise, replace it with support or facts already in the content.
Weasel attribution. "Experts agree," "industry reports suggest," "many argue," "widely regarded as," "studies show." Name the source or cut the claim. If the user has no source, ask instead of inventing one.
Fake-strong verbs. Prefer "is" and "has" when they are clearer. "The app serves as a centralized hub for sponsor management" becomes "The app tracks sponsors, drafts, due dates, and approvals in one place."
Synonym cycling. If the clear word is right, repeat it. Don't rotate terms for style. "The agent reviews the draft. The assistant scores the piece. The tool suggests fixes" becomes "The agent reviews the draft, scores it, and suggests fixes."
Negative listing. "Not a X. Not a Y. A Z." Just say Z.
Dramatic fragmentation. "X. And Y. And Z." or "That's it. That's the whole thing." Use complete sentences.
Robotic rhythm. Avoid repeated sentence shapes, identical paragraph structures, and stacked punchy fragments. Vary the shape only when it helps the point.
Rhetorical setups. "What if I told you...", "Think about it:", "Plot twist:", and self-answered "Question? Answer." pairs. Drop them and make the point.
Fake-profound kickers. Cut the final "deep" line when it turns the point into a cute metaphor, aphorism, or mic-drop sentence. Do not rewrite it into a better metaphor. Do not preserve the rhythm. Delete it, then end on the clearest concrete sentence already in the draft. If the ending needs more closure, add a plain takeaway or next action.
Summary-recap endings. "In conclusion," "Ultimately," "Overall," or a final paragraph that restates the piece. The reader was just there. End on the last concrete point, takeaway, or next action instead.
Formatting slop. Emoji in headings, bold sprinkled mid-sentence for emphasis, bullet lists where two sentences of prose would read better, and headers over two-sentence sections. Format should follow the content, not decorate it.
Em dashes. Do not use them as a default rhythm crutch. In short copy, use none. In longer drafts, 1-2 are fine if they clearly beat commas, periods, or parentheses. Remove clusters and decorative dashes.
1. Read the full draft before editing.
2. Identify the core point and 3-5 voice signals to preserve, such as vocabulary, cadence, bluntness, humor, uncertainty, or digressions. Keep this note internal. If you cannot identify the core point, ask the user.
3. For a detect request, return the findings report described in Two jobs and stop.
4. For an edit, make the minimum effective changes, then check the edited draft against this skill's own rules.
5. If any check fails, fix the draft and run the checks again.
6. Output the full edited draft and a short What changed section.
Write new book chapters from source material, matching the existing book's voice and style.
All files the task specifies. Extract themes, facts, quotes, examples. Note which ideas are strongest.
This is the most important step. The existing text IS the style guide. Match sentence length, tone, I-voice, structural patterns, and YAML frontmatter format.
The task usually specifies the structure. Follow it exactly. Minto Pyramid: first paragraph carries the argument.
If under target: expand with concrete detail, new examples, deeper explanation. NOT padding. If over: cut to the argument.
When a voice note arrives with book editing instructions (add a section, rewrite a paragraph, fix wording):
1. Transcribe the voice note via Whisper (voice-note skill).
2. Locate the target chapter file in the book directory.
3. Load the voice & style rules (Section 1 of this skill) for voice guidance.
4. Edit the chapter in Joseph's voice (first person, direct, American English, no AI slop).
5. Save the transcript to wiki/consume/raw/voice-notes/ for reference.
6. Delete the audio file.
Do not paraphrase or summarize the instruction back — execute it directly. Joseph's voice notes are usually precise about what to add or change.
1. Don't pad to hit word count. Filler is worse than being 100 words short.
2. Don't change voice to match instructions. Match the VOICE of the existing text.
3. Don't skip reading existing chapters. Voice calibration is non-negotiable.
4. Don't over-explain. Short sentences. Trust the reader.
Manage book chapters as individual numbered files with a TOC for ordering, reviews folder for version control, and subagent delegation for parallel writing.
book-directory/
├── toc.md ← Chapter order + assembly command (single source of truth)
├── 00-intro.md ← Individual chapter files (numbered)
├── 01-chapter.md
├── 02-chapter.md
├── reviews/ ← Version snapshots
│ ├── round-1-v1-01.md ← Before review round 1
│ ├── round-1-v2-01.md ← After review round 1
│ └── round-2-v1-02.md ← Before review round 2
├── full-book.md ← Assembled from toc.md order
├── full-book.html ← Generated HTML
└── book.pdf ← Generated PDF
Create toc.md as the single source of truth for chapter ordering:
# Book Title — Table of Contents
Order
File
Title
Status
0
00-intro.md
Intro
✅ keep
1
01-chapter.md
Chapter 1
🆕 new
2
02-chapter.md
Chapter 2
✍️ rewrite
3
03-chapter.md
Chapter 3
🆕 new
Assembly Command
cat 00-intro.md 01-chapter.md 02-chapter.md 03-chapter.md > full-book.md
# Naming: round-N-vN-XX-chapter-name.md
mv 01-old-chapter.md reviews/round-4-v1-01-old-chapter.md
mv 02-old-chapter.md reviews/round-4-v1-02-old-chapter.md
Define the new chapter order and assembly command.
Write individual chapter files following the TOC order.
cat 00-intro.md 01-chapter.md 02-chapter.md > full-book.md
Use the book's PDF generation script (WeasyPrint or pandoc+LaTeX).
When inserting a chapter into an existing numbered sequence:
1. Write the new chapter at its target number (e.g., 03-new.md).
2. Rename files from the insertion point onward using mv, working backward to avoid collisions: mv 07-ch.md 08-ch.md, mv 06-ch.md 07-ch.md, etc.
3. Update chapter headings inside each renamed file (# Chapter N: Title).
4. Scan ALL chapter files for stale cross-references. This is the step most likely to be missed. Chapters frequently reference other chapters by number (e.g., "what I said in Chapter 3"). After renumbering, every such reference must be checked and updated. Use:
grep -rn "Chapter [0-9]" 0.md | grep -v "^0.:# Chapter"
5. Update the TOC and assembly command.
6. Verify with wc -w 0.md and grep -n "^# Chapter" 0.md.
When content is dispersed across multiple chapters and needs to be pulled into a single unifying chapter:
1. Read all existing chapters to identify where the target content lives. Note specific paragraphs, quotes, or data points.
2. Write the synthesis chapter that weaves the dispersed material into a coherent narrative. The new chapter should reference other chapters (cross-references) rather than duplicate their content.
3. Add cross-references in the existing chapters pointing back to the synthesis chapter (e.g., "see Chapter N for the full stack").
4. Lightly trim duplicate material in existing chapters where the synthesis chapter now covers it — but don't over-trim. Each chapter must still stand alone.
5. Renumber as needed (see Inserting workflow above).
When a book is assembled from separate blog posts, repeated sentences and structural patterns survive compilation. Blog posts need self-contained context; books don't.
Run after cat assembly into full-book.md:
from collections import Counter
import re
sentences = []
for line in open('full-book.md'):
for sent in re.split(r'(?<=[.!?])\s+', line.strip()):
if len(sent) > 40:
sentences.append(sent)
dups = {s: c for s, c in Counter(sentences).items() if c > 1}
| Category | What it looks like | Action |
|---|---|---|
| Exact sentence duplicates | Same sentence in 2+ chapters | Keep the version with more context; rephrase the other |
| Meta-references | "This book..." appearing in mid-chapters | Change to chapter-specific ("I wrote this chapter...") |
| Formulaic closers | "The X effect is the point" / "compounding has barely started" | Keep one instance (usually the first); vary the rest |
1. Exact duplicates first (mechanical, low risk)
2. Meta-references (light touch)
3. Formulaic closers (editorial judgment)
4. Full read-through after edits to catch rhythm breaks and transitions that now feel abrupt
Some repeated sentences serve different arguments in different chapters (e.g., "Before Hermes, I ran this on discipline alone" in WINS intro vs. Self chapter). Don't blindly delete — check whether the sentence earns its place in each context.
After patching individual chapter files, reassemble and verify:
cat 00-intro.md 01-chapter.md ... > full-book-v3.md
Then verify duplicates are gone:
from collections import Counter
import re
with open('full-book-v3.md') as f:
content = f.read()
sentences = []
for line in content.split('\n'):
for sent in re.split(r'(?<=[.!?])\s+', line.strip()):
if len(sent) > 40:
sentences.append(sent)
dups = {s: c for s, c in Counter(sentences).items() if c > 1}
if dups:
for s, c in dups.items():
print(f'[{c}x] {s[:120]}')
else:
print('No exact duplicates remain.')
Also verify chapter structure: grep -n "^# " full-book-v3.md — check for duplicate chapter numbers (e.g., two "Chapter 6" headings from different source files).
When writing multiple chapters, delegate to subagents in parallel:
goal: Write Chapter N: "Title" for [book name].
Source material: [list files to read]
Requirements: [voice, style, word count]
Structure: [section outline]
Output: Save to /path/to/0N-chapter.md
1. Verify all files exist: ls -la 0*.md
2. Check word counts: wc -w 0*.md
3. Assemble: cat 00-.md 01-.md ... > full-book.md
4. Generate PDF
round-N-vN-XX-chapter-name.md
reviews/
├── round-1-v1-00-intro.md
├── round-1-v2-00-intro.md
├── round-2-v1-03-moving-to-vps.md
└── round-4-v1-07-stock-screening.md
When a chapter has [!hh] callout comments left by Joseph during review:
Load the voice & style rules (Section 1 of this skill) before editing. Process ALL callouts in one pass, not one at a time.
See references/editorial-callout-patterns.md for observed callout types and examples.
After resolving callouts, run the voice & style rules (Section 1) on the full chapter: em-dashes, AI words, tight paragraphs, strong verbs.
When callouts mention content repeated in another chapter:
Don't answer callout questions inside the document. Resolve them by editing the text or flagging to the user in your response.
1. Check for existing reviews folder. Before creating reviews/, check if it already exists. User may have created it in a previous session.
2. Don't mix chapter files with reviews. Keep the working directory clean — only current chapter files at the top level.
3. Update toc.md when reordering. The TOC is the single source of truth. If you reorder chapters, update the TOC first.
4. Verify subagent output. Subagents self-report completion. Check that files exist and have reasonable word counts before assembling.
5. Preserve YAML frontmatter. Each chapter file should have YAML frontmatter with title. The assembly command concatenates them as-is.
6. Don't regenerate PDF after every edit. Wait until all chapters in a batch are reviewed before regenerating.
7. Blog-to-book deduplication. After compiling from blog posts, scan for repeated sentences, meta-references, and formulaic closers. See workflow above.
8. Chapter numbering. When source files have their own heading numbers, they may collide after assembly (e.g., two files both labeled "Chapter 6"). Verify chapter headings are unique after reassembly.
9. Stale cross-references after renumbering. Chapters frequently reference other chapters by number in examples, hypothetical callouts, or inline prose (e.g., "what I said in Chapter 3"). After inserting or renumbering, scan every file for these references. They don't show up as heading collisions — they just silently point at the wrong chapter. Use grep -rn "Chapter [0-9]" 0.md | grep -v "^0:# Chapter" to find them.
10. Verify technical claims in editorial callouts. When a [!hh] callout says "validate this" or questions a technical claim, check the actual source (skill files, config, logs) before removing the callout. Don't assume the draft is correct just because it reads well. The transcript-routing cost claim (36 cents vs. 8-12 cents) needed verification against the youtube-content skill, for example.
11. Cross-chapter content duplication. When a callout flags content repeated in another chapter, read both chapters before recommending cuts. Some repetition serves different arguments (standalone article vs. connected book). Recommend, don't cut — the user decides what earns its place in each context.
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
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.
New thread opens with: plan path, task path, progress path, chapter list, reviews path, current phase, pending decisions.