{"enrichment":{"faq":[{"a":"develop-adr guides you through creating an Architecture Decision Record using Michael Nygard's lightweight format. Start by numbering your ADR sequentially, then document the decision's context (what problem you faced), the decision itself (what you chose), consequences (trade-offs and impacts), and alternatives considered. Include the status (Proposed, Accepted, Deprecated, Superseded) so teams understand the decision's current standing. This structured approach ensures your reasoning is preserved for future team members.","q":"How to write an architecture decision record?"},{"a":"develop-adr's template covers: Title, Status, Context (the issue or problem), Decision (what was chosen), Consequences (positive and negative outcomes), and Alternatives (options that were rejected). Some ADRs also include Rationale (why this choice) and Related Decisions (links to dependent ADRs). This format keeps documentation lightweight yet complete, making it easy for teams to understand not just what was decided, but why and what trade-offs were accepted.","q":"What should an ADR template for technical decisions include?"},{"a":"develop-adr helps you document architectural decisions by providing a structured, numbered format that captures context and consequences. Create a new ADR file for each significant choice\u2014whether it's technology selection, design patterns, or system constraints. Include the decision's background, what you chose, and the trade-offs involved. Store ADRs in version control alongside your code so they evolve with your system and remain accessible to all team members.","q":"How do I record architectural decisions with develop-adr?"},{"a":"develop-adr emphasizes that documenting technical choices preserves institutional knowledge when team members leave or projects shift focus. Recording the context and rationale behind decisions prevents teams from re-debating settled choices or unknowingly repeating past mistakes. ADRs capture trade-offs explicitly, helping future developers understand constraints and assumptions. This lightweight documentation format makes it practical to maintain a decision history without heavyweight process overhead.","q":"Why document technical choices and preserve decision reasoning?"},{"a":"develop-adr uses sequential numbering (ADR-001, ADR-002, etc.) to create an immutable audit trail of decisions in chronological order. Status tracking marks each ADR as Proposed (under consideration), Accepted (approved), Deprecated (no longer used), or Superseded (replaced by another ADR). Together, numbering and status let teams quickly find decisions, understand their evolution, and see which choices remain active versus historical.","q":"What's the difference between ADR numbering and status tracking?"},{"a":"develop-adr is ideal for documenting database selection decisions because these choices have long-term architectural impact. Create an ADR that explains the problem (scalability, consistency, query patterns), the database you chose, consequences (operational overhead, learning curve, cost), and alternatives you rejected. This record helps onboard new team members, justifies the choice to stakeholders, and provides a reference if you later need to reconsider the decision.","q":"When should I use develop-adr for database selection?"}],"shadow_tags":["decision-documentation","technical-rationale","knowledge-preservation","architecture-governance","design-justification","team-alignment","lightweight-process","future-proofing"],"summary_rewrite":"This skill guides you through creating an Architecture Decision Record that captures the reasoning behind significant technical or architectural choices. It follows Michael Nygard's lightweight format to ensure decisions are documented with their context, rationale, and trade-offs\u2014preserving institutional knowledge for future team members. Use it when selecting technologies, establishing development patterns, or documenting constraints that shape your system."},"files":[{"bytes":3759,"path":"skills/develop-adr/SKILL.md","sha256":"6a28a360aa5c178c1a6f965f9b9ee78e7e74933b079a8928c1621b9608271eb9","url":"https://skillfed.io/files/product-on-purpose/pm-skills/develop-adr/a2e370f4/SKILL.md"}],"id":"product-on-purpose/pm-skills/develop-adr","links":{"html":"https://skillfed.io/product-on-purpose/pm-skills/develop-adr","md":"https://skillfed.io/product-on-purpose/pm-skills/develop-adr.md","repo":"https://github.com/product-on-purpose/pm-skills"},"meta":{"agents_supported":[],"first_seen":"2026-07-28","forks":66,"language":"JavaScript","last_updated":"2026-07-24","license":"Apache-2.0","name":"develop-adr","publisher":"product-on-purpose","stars":505},"relations":{"categories":["architecture","engineering-leadership","knowledge-management"],"similar":[{"id":"product-on-purpose/pm-skills/develop-design-rationale"},{"id":"product-on-purpose/pm-skills/develop-spike-summary"},{"id":"product-on-purpose/pm-skills/develop-solution-brief"},{"id":"yonatangross/orchestkit/architecture-decision-record"},{"id":"tech-leads-club/agent-skills/create-adr"},{"id":"codestable/CodeStable/cs-domain"},{"id":"affaan-m/ECC/architecture-decision-records"},{"id":"Mathews-Tom/armory/adr-writer"},{"id":"patricio0312rev/skills/adr-writer"},{"id":"JosiahSiegel/claude-plugin-marketplace/doc-diagnostic"}]},"slug":{"owner":"product-on-purpose","repo":"pm-skills","skill":"develop-adr"},"version":"a2e370f4"}