RedPen.cc, Vale.sh, TextLint, and LanguageTool are all invaluable NL linters. Low hanging fruit. CodeSpell is a universal spell checker that understands most m

RedPen.cc, Vale.sh, TextLint, and LanguageTool are all invaluable NL linters. Low hanging fruit. CodeSpell is a universal spell checker that understands most markup, as long as it's not some demonic XML/SGML specification from the Department of Defense. If you really want to be a hardass, pre-commit hook based on a NL linter and a spellchecker. OK, low hanging fruit. That's the first stop. Second stop is to understand what needs to come out, and what needs to come in. This is going to depend on, well, what you're doing. Sketch something out with graphviz or plantuml to catch the flows. If you can, talk to the audience, and classify them if you can. In aerospace we have "maintenance levels" (lots of different acroterms for that) which delineate how well trained the audience needs to be to perform the task being considered. But anyway. Third stop How similar are the deliverables? Do you want to re-use any of the content? Or do you want to optimize on BDMs (Big Dumb Manuals) aka - maybe using a more scientific term here - unified manuals? If you want to chunk the content up (using conditional content to filter out stuff), you have a few options, ranging from the XML world (DITA, DocBook, S1000D) to the world of lightweight markup (Asciidoc includes+conditional directives, MarkdownPP extension, RsT includes, etc). Broadly known as Component Content Systems. Don't get fast-talked; the vendors are insistent and they are all liars of one stripe or another. CCS isn't a cure-all, and XML isn't the "ultimate doc language". CCS isn't even an optimal fit for most purposes. But sometimes it is, and it can save you some time. CCM/CCS is composed of the following: *files* (DMs, topics, etc) that contain content, *conditions* (applic, ditaval, etc) that customize content, and *maps* (PMs, ditamaps, etc) that point to *files* to create a doc, and a *product* that is being documented. The relationship between the *product* and the *files+conditions+map(s)* is what's sometimes called document *architecture*. *Architecture* can contain 1) the document "chunking" (how *files* are created/named) and 2) the *conditions* needed for a particular deliverable, and 3) how the *maps* that generate the deliverable tie the content deliverable to the *product*. Currently, when people are just experimenting with the CCS concept, I advise them to try it out with Asciidoc, because you can do that right now, versus paying a hundred grand and waiting a few weeks for your DITA solution. Sure, some vendors are great, but a lot aren't, and they change around all the damn time. Particularly in the S1000D XML world.