AI Workflows: Text Editing

editing documentation and prose without losing your voice

1. Summary

Claude edits prose well when given explicit constraints. Without them, it defaults to its own style: more verbose, more cautious in tone, and prone to softening technical assertions. A managetext.md file encodes your voice, target audience, and what an editing pass should and should not touch. Loading it at session start prevents the model from improving your text into something generic.

2. managetext.md Structure

# Text Editing Context

## Voice and Tone
Active voice. Direct sentences. No hedging ("it may be the case that", "one might argue").
Audience: experienced software developers.
Use dashes (-), not em dashes.
No emojis.

## What to Edit
- Fix factual errors
- Improve clarity where a sentence is ambiguous
- Fix grammar and punctuation errors
- Convert passive voice to active where the passive is weak

## What Not to Touch
- Technical terminology - do not paraphrase or soften
- Code samples - edit only surrounding prose, never the code itself
- Section structure - do not add, remove, or reorder sections
- Deliberate stylistic choices: short sentences, specific examples, direct assertions

## Output Format
Show only the changed paragraphs, not the full document.
For each change, state briefly why you made it.

3. Example Prompts

Editing selected sections:
Read managetext.md.
Read [content_page.html].

Edit the prose in sections 2 and 3 following managetext.md.
Do not touch the code blocks, section headings, or any HTML structure.
Show only the changed paragraphs with a brief note on each change.
Passive voice sweep:
Read managetext.md.
Read [file].

Find every sentence that uses passive voice or hedging language.
For each, show the original and propose an active-voice replacement.
Do not rewrite sentences that don't need it.
Updating comments in source files:
Read managetext.md.
Read [source_file].

Find every comment that describes what the code does rather than why.
For each, propose a replacement that explains the reason or constraint
instead of restating the action. Leave self-evident code uncommented.
Checking consistency across pages:
Read managetext.md.
Read [page_a.html].
Read [page_b.html].

These two pages cover related topics. Find any place where they describe
the same concept in contradictory or inconsistent ways.
Report the discrepancy and which page's version is more accurate.

4. Generating New Text

When writing new content rather than editing existing text, the same managetext.md applies. Add a brief content brief to the prompt:
Read managetext.md.

Write a summary paragraph for [topic] that will appear at the top of [page].
The paragraph should cover: [three specific points].
One paragraph, direct tone, no hedging.
Show the draft - do not write it to the file yet.
For longer content, scaffold the structure first:
Read managetext.md.

Propose a section outline for a page covering [topic].
Each section should be one sentence describing what it covers.
Do not write the content yet - just the outline for my review.
Then after approving the outline, fill in one section at a time:
The outline looks good. Write section 1 only.
Follow managetext.md for tone. Stop after that section.

5. What to Watch For

ProblemPrevention
Claude rewrites the whole document State "show only changed paragraphs" in managetext.md and in the prompt
Technical terms softened or paraphrased State "do not paraphrase technical terminology" explicitly
Code blocks modified State "do not touch code blocks" in managetext.md
Sections added that weren't asked for State "do not add or remove sections"
Hedging introduced ("it is worth noting that") Name the specific hedging phrases to avoid in managetext.md