Writing

Technical writing

Turn how something works into docs a reader can actually follow.

Knowledge cards
Knowledge card
Define the Terms You're Quietly Assuming
A technical-writing pattern where you have Claude identify the terms, acronyms, and concepts a piece assumes the reader knows, and define them at first use — pitched to the actual audience rather than to the author.
L2 · Context engineering
Best practice
Tell Claude the Reader's Level So It Explains at the Right Altitude
A calibration step: tell Claude exactly who will read the explanation and what they already know, so it pitches the depth, jargon, and examples at the right altitude — the same concept explained differently for an executive, a practitioner, and an implementer.
L2 · Context engineering
Knowledge card
Lead With a Worked Example, Then Explain
A technical-writing pattern where you have Claude open with a concrete, runnable example — the smallest real case — and only then generalise into the rule, rather than leading with abstract description.
L2 · Context engineering
Best practice
Write Docs From the Reader's Task, Not the Feature List
A documentation approach where you ask Claude to organise around the reader's tasks — the things they're trying to accomplish — rather than cataloguing every feature and setting. The unit of docs is a job to be done, not a UI element.
L2 · Context engineering
Claude for technical writing

Accuracy is the whole job

Technical writing fails differently from other writing: a wrong sentence is a bug in the docs, and a fluent explanation of something inaccurate is worse than no explanation at all. This is where Claude's tendency to stay faithful to source material pays off. Give it the real thing — the code, the spec, the API, the actual behaviour — and ask it to explain from that, not from a general sense of how such systems usually work. Grounding the writing in the source is what keeps documentation trustworthy.

Write for the reader who is stuck

Good docs are written for someone mid-task, not someone reading for pleasure. Tell Claude who the reader is and what they are trying to do, and ask for the explanation that unblocks them — the concrete steps, the gotchas, the example that clarifies. Ask it to include a worked example, since one example often teaches more than three paragraphs. Then check the technical claims yourself: Claude drafts clear, structured docs quickly, but you own their correctness.

Frequently asked
Is Claude good for technical documentation?

Yes — its faithfulness to source material suits docs where accuracy matters. Give it the real code, spec, or behaviour and ask it to explain from that rather than general knowledge.

How do I make Claude's docs clearer?

Tell it who the reader is and what they are trying to do, and ask for the explanation that unblocks them, including a worked example. Docs should serve someone mid-task.

Should I trust Claude's technical explanations?

Trust the structure and clarity, but verify the technical claims yourself. Claude drafts good docs quickly, but you own their correctness, especially for anything others will rely on.