anchor.diff:  
   === Compound and Stakeholder-Tailored Docs
   
  -Since you can not only reference images and code snippets but also sub-documents, you can split your docs into several sub-documents and a master which brings all those docs together.
  -But you are not restricted to one master - you can create master docs for several different stakeholders which only contain the chapters needed for them.
  +Since you can not only reference images and code snippets but also sub-documents, you can split your docs into several sub-documents and a master, which brings all those docs together.
  +But you are not restricted to one master -- you can create master docs for different stakeholders that only contain the chapters needed for them.
   
   === Many more Features...
   
  
positive.code: Before this project started, I wasn't aware of the term _docs-as-code_.
  I just got tired of keeping all my architecture diagrams up to date by copying them from my UML tool over to my word processor.
  
  As a lazy developer, I told myself 'there has to be a better way of doing this'.
  And I started to automate the diagram export and switched from a full fledged word processor over to a markup renderer.
  This enabled me to reference the diagrams from within my text and update them just before I render the document.
  
  === arc42
  
  Since my goal was to document software architectures, I was already using arc42 - a template for software architecture.
  At this time, it used the MS Word template.
  
  But what is arc42?
  
  
negative.code: These explanations are part of every chapter of the template and give you guidance on how to write each chapter of the document.
  
  arc42 is available in many formats like MS Word, textile, and Confluence.
  All these formats are automatically generated from one _golden master_ formatted in https://asciidoctor.org/docs/asciidoc-syntax-quick-reference/[_AsciiDoc_].
  
  === docToolchain
  
  In order to follow the _docs-as-code_ approach, you need a build script that automates steps like exporting diagrams and rendering the used Markdown (_AsciiDoc_ in case of _docToolchain_) to the target format.
  
  Unfortunately, such a build script is not easy to create in the first place ('`how do I create .docx?`', '`why does lib x not work with lib y?`') and it is also not too easy to maintain.
  
  _docToolchain_ is the result of my journey through the _docs-as-code_ land.
  The goal is to have an easy to use build script that only has to be configured and not modified and that is maintained by a community as open source software.
  
  The technical steps of my journey are written down in my blog: https://rdmueller.github.io.
  
  '''
  
  Let's start with what you'll get when you use _docToolchain_...
  
  == Benefits of the docs-as-code Approach
  
  You want to write technical docs for your software project.
  So it is likely you already have the tools and processes to work with source code in place.
  Why not also use it for your docs?
  
  === Document Management System
  