Architecture Decisioning
This skill guides the process of proposing, reviewing, and documenting architectural decisions via ADRs.
Workflow
- •Identify Trigger: Recognize when a decision warrants an ADR (e.g., new database, major refactor, new library).
- •Consult History: Check
docs/specs/shared/adr/andjust temporal-ai-queryfor past decisions to ensure consistency. - •Draft ADR: Create a new ADR using the standard template:
- •Title: Clear and concise.
- •Status: Proposed.
- •Context: Why are we making this decision? What are the constraints?
- •Decision: What is being decided?
- •Consequences: Positive and negative impacts.
- •Review: Validate the ADR against strategic principles (Invariants, Idempotency, Isomorphism).
ADR Template Structure
markdown
# [ADR-XXX] Title **Status**: Proposed | Accepted | Rejected | Deprecated **Date**: YYYY-MM-DD **Authors**: [Names] ## Context The issue motivating this decision... ## Decision We will... ## Consequences **Positive**: - ... **Negative**: - ...
Strategic Alignment
Ensure the decision aligns with:
- •Hexagonal Architecture: Does it respect layer boundaries?
- •Isomorphism: Does it maintain structural alignment?
- •Safety: Does it introduce security or type safety risks?