anchor.diff:  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_].
  +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 which automates steps like exporting diagrams and rendering the used Markdown (_AsciiDoc_ in case of _docToolchain_) to the target format.
  +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.
  +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 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 very likely that you already have the tools and processes to work with source code in place.
  +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
  
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: 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
  
  