Technical writing

Identify the reader, their starting knowledge, and what they need to do or understand. Inspect the relevant implementation and existing documentation before changing claims. Keep proposed behavior, observed behavior, and requirements distinct.

• Choose the appropriate form: guided learning, a task procedure, API reference, or explanation. Read document forms when organizing a document or writing a PR, release note, or migration guide.
• Put prerequisites before commands and explain expected results, relevant failure cases, and cleanup. Use the smallest example that teaches the actual contract.
• Define unfamiliar terms at first use. Prefer concrete subjects and verbs; retain precise technical vocabulary.
• Keep one authoritative explanation per topic and link to it. Preserve useful URLs or redirects when moving published pages.
• Trace API names, options, defaults, compatibility claims, and numeric limits to source or current authoritative documentation. Mark uncertainty when evidence is missing.
• Preserve normative strength: editing “may” into “will” or dropping a condition changes a promise. Do not convert a design proposal into a claim of implementation.

Check code samples with the project's tools when practical and record exactly which examples ran. Inspect the rendered result when structure, links, or code blocks change. Use the available unslop skill for the final editorial pass; it complements contract verification.