Below is the (markdown) template I use for my Architectural Decision Records (ADRs).
It is a shortened version of [this template](https://github.com/joelparkerhenderson/architecture-decision-record/blob/main/templates/decision-record-template-madr/index.md) with slight renaming to make things clearer.
It is explicitly designed to be as minimal as possible while providing the main benefit that I personally care about from ADRs, which is **enabling better conversations about decisions and, thus, better decision-making.
# Template
```
# [short title of problem]
* Status: [proposed | rejected | accepted | deprecated | … | superseded by [ADR-0005](0005-example.md)] <!-- optional -->
* Deciders: [list everyone involved in the decision] <!-- optional -->
* Links: [list all the related links] <!-- optional -->
## Context and Problem Statement
[Describe the context and problem statement, e.g., in free form using two to three sentences. You may want to articulate the problem in form of a question.]
## Evaluation Criteria
* [criteria 1, e.g., a force, facing concern, …]
* [criteria 2, e.g., a force, facing concern, …]
* … <!-- numbers of criteria can vary -->
## Considered Options
### [option 1]
[example | description | pointer to more information | …] <!-- optional -->
* Pros & Cons:
* Good, because [argument a]
* Good, because [argument b]
* Bad, because [argument c]
* … <!-- numbers of pros and cons can vary -->
Does/doesn't meet criteria and why: yes/no
### [option 2]
[example | description | pointer to more information | …] <!-- optional -->
* Pros & Cons:
* Good, because [argument a]
* Good, because [argument b]
* Bad, because [argument c]
* … <!-- numbers of pros and cons can vary -->
Does/doesn't meet criteria and why: yes/no
### [option n]
[example | description | pointer to more information | …] <!-- optional -->
* Pros & Cons:
* Good, because [argument a]
* Good, because [argument b]
* Bad, because [argument c]
* … <!-- numbers of pros and cons can vary -->
Does/doesn't meet criteria and why: yes/no
## Decision Recommendation
Recommend option: "[option 1]", because [justification. e.g., only option, which meets k.o. criterion evaluation criteria | which resolves force force | … | comes out best (see below)].
### Expected Positive Consequences <!-- optional -->
* [e.g., improvement of quality attribute satisfaction, follow-up decisions required, …]
* …
### Expected Negative Consequences <!-- optional -->
<!-- Every decision has tradeoffs and negative consequences. Which ones can we already foresee if we chose the perceived best option? -->
* [e.g., compromising quality attribute, follow-up decisions required, …]
* …
```