Skip to main content

Purpose

The architecture-decision-records skill provides a structured framework for documenting significant technical decisions through Architecture Decision Records (ADRs). It captures the context, rationale, trade-offs, and consequences behind architectural choices, ensuring historical clarity and facilitating decision reviews.

When to Write an ADR

Write an ADR when making significant architectural or technological choices, such as:
  • Selecting or replacing a database technology, framework, or message broker.
  • Adopting a new system-wide security, deployment, or state synchronization pattern.
  • Making trade-offs between latency, consistency, complexity, and operational cost.
Do NOT write an ADR for: Minor dependency version bumps, bug fixes, or localised code refactorings.

Standard ADR Format (MADR Schema)


Best Practices

  • Durable Explanation: Focus on why the decision was made given the constraints at the time.
  • Explicit Triggers: State what conditions or metrics would prompt the team to revisit the decision in the future.

Deep State of Mind (DSOM) For My AI Protocol | Harisfazillah Jamel (LinuxMalaysia) | 2026-09-02 Standard: UK English | DBP-standard Bahasa Melayu Malaysia (Piawai) | GNU General Public License v3.0