Architecture Decision Records Skill (architecture-decision-records)

The architecture-decision-records skill provides templates and lifecycle governance for capturing significant technical and architectural choices in Architecture Decision Records (ADRs).

When to Write an ADR

• When adopting or replacing major frameworks, database systems, or deployment architectures.
• When making non-trivial design trade-offs impacting security, performance, or operational workflows.
• Do not write ADRs for minor version updates or routine bug fixes.

MADR Standard Format

Every ADR must include:

1. Title & Status: Clear sequential title (e.g., ADR-001: Adopt Astro SSG for Static Modernisation) and status (Proposed, Accepted, Deprecated, Superseded).
2. Context & Problem Statement: The background context and problem triggering the decision.
3. Decision Drivers: Factors influencing the choice (e.g. security, zero-cost cloud hosting, performance).
4. Considered Options: The alternatives evaluated.
5. Decision Outcome: The chosen option, rationale, and positive/negative consequences.

FAQs

When should an ADR be marked as Superseded?

When a subsequent architectural decision (recorded in a new ADR) replaces or alters a previously accepted choice.

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