technical-writinglisted

# Technical writing Give the intended reader a usable explanation or working route through the product. Choose the right depth and structure, make examples understandable, and tie claims to the available sources. This is not a release pipeline. ## Choose the reader's path Identify reader, goal, document type, delivery format and the scope opened by the request. A feature-list review is not a whole-README publication audit. Infer version scope from the brief, checkout, release record or versioned site; require a visible page version only when its absence creates real ambiguity. - `draft`: compose the requested document from the relevant sources. - `edit`: a `copyedit` preserves structure, code, identifiers, data and link targets in the opened area; a `rewrite` may reorganize. Technical changes still require evidence and authorization. - `review`: findings only, no edits or command execution by default. A separately authorized validation can run its named checks in the allowed environment. Infer the mode. Ask only about a missing fact or choice that changes the outcome. ## Design a complete document, not a filled checklist For a new document or substantial rewrite: 1. **Start from the reader's next need.** A README helps decide whether to use the product and reach a first result; an explanation builds understanding; a reference makes an exact answer easy to locate. 2. **Select the necessary material.** Separate the main path from alternatives, reference d