Generators, linters, repositories, CI pipelines and the systems around documentation.
Sphinx, MkDocs, Astro and other generators optimize for different content models and teams. Choose by authoring workflow, extensibility, localization and maintenance cost instead of feature-list enthusiasm. A generator demo can look excellent and still be wrong for your documentation.
Documentation search should be selected and tuned around the queries users fail to resolve, not around a feature checklist from vendors. Search is most valuable when readers know a term or symptom but not where the information lives.
Text-defined diagrams are maintainable and reviewable, but only when the visual problem matches what the notation can express clearly. Use text-defined diagrams for flows, states, dependencies and sequences where relationships are the main information.
Treat documentation as a build artifact: validate structure, links, examples and publication rules before changes reach readers. CI cannot decide whether an explanation is useful, but it can reject many predictable defects before a human spends time on them.
Markdown stays simple only when a team agrees on structure, metadata and extensions before thousands of files make every exception permanent. Standardize filenames, frontmatter, headings, image locations and internal-link conventions early.
Style linting is valuable when it catches terminology drift, risky wording and repeatable editorial defects. Keep the rule set small, explainable and quiet enough that writers trust a failed check. A style linter can check thousands of sentences in seconds, which makes it tempting to encode every editorial preference.