develop-adr

<!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 --> # Architecture Decision Record (ADR) An Architecture Decision Record documents a significant technical decision along with its context and consequences. ADRs capture the "why" behind architectural choices so future team members understand the reasoning . especially important when they question why something was done a particular way. This skill follows Michael Nygard's lightweight ADR format. ## When to Use - Making significant technical decisions that affect system architecture - Choosing between technology options (frameworks, databases, services) - Establishing patterns that future development should follow - Documenting the rationale for constraints or non-obvious approaches - Preserving institutional knowledge about past decisions ## Instructions When asked to create an ADR, follow these steps: 1. **Assign a Number and Title** ADRs are numbered sequentially (ADR-001, ADR-002, etc.) for easy reference. The title should be a short noun phrase describing the decision, like "Use PostgreSQL for order data" or "Adopt React for frontend." 2. **Set the Status** New ADRs start as "Proposed." After team review, they become "Accepted," "Deprecated," or "Superseded by ADR-XXX." Status changes should be tracked. 3. **Describe the Context** Explain the circumstances that led to this decision. What problem are you solving? What forces are at play (technical constraints, team expertise, ti...