Architecture Decision Records

A decision record answers one question a future reader will ask: why is it like this? It names the situation, the options that were on the table, the one chosen and what it cost. Written well, it outlives the people who wrote it, which is the point — a design system team turns over, and the record is the channel between one iteration of the team and the next.

The format here is the Equinor Design System team's: Michael Nygard's record (context, decision, consequences) as structured by MADR (drivers, options with pros and cons, Good, because / Bad, because consequences, confirmation), with the team's own choices — bullet-list metadata instead of YAML front matter, pros and cons inline under each option, a flat ## Decision with ### Consequences and ### Confirmation beneath it, and ## Related last. The template is references/template.md, verbatim.

This skill emits no values: its output is a Markdown record, an index and a lint result, not tokens.