diataxis-how-tolisted

# diataxis-how-to Produces a **how-to guide** in the Diataxis sense: *task-oriented*. The reader is already competent and has a specific goal in mind; success is that the goal is accomplished. A how-to is not a tutorial (it does not teach) and not reference (it does not catalog) and not explanation (it does not theorize) — keep those modes out. ## Pattern (industry: Diataxis, diataxis.fr) 1. **Title** — states the goal directly: "How to `accomplish X`". 2. **Context line** — one or two sentences naming when/why you'd do this. 3. **Prerequisites** — the concrete starting state and access the task assumes. 4. **Numbered action steps** — an ordered sequence of real commands/actions that move from the starting state to the goal. Each step does one thing. 5. **Completion** — a short line confirming the goal is now met. Stop there. ## Rules that keep it a how-to - Assume competence. Do not teach concepts or define terms — link out instead. - No theory, background, or "why it works" prose — that is an explanation doc. This holds inside a step's own sentence, not just as separate paragraphs or sections: a trailing clause that justifies *why the step is safe* or explains a system's internal mechanics (e.g. "...so both are valid at the same time", "...so any replica still mid-rollout keeps authenticating") is rationale riding on the same sentence as a real action — cut it, or move it to the linked explanation doc. A clause naming the step's own direct, immediate e