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: 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_ which is 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 which 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 which only has to be configured and not modified and which 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 very likely that 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
  
negative.code: Git as a distributed version control system even enables collaboration on your docs.
  People can fork the docs and send you pull requests for the changes they made.
  By reviewing the pull request, you have a perfect review process out of the box - by accepting the pull request, you show that you've reviewed and accepted the changes.
  Most Git frontends like https://www.bitbucket.org[Bitbucket], https://gitlab.com[GitLab] and of course https://github.com[GitHub] also allow you to reject pull requests with comments.
  
  === Image References and Code Snippets
  
  