sample-adr-poor

An ADR (Architecture Decision Record) documents key architectural choices, their rationale, and consequences. Architecture documentation captures decisions for frontend, backend, and fullstack projects, helping teams understand why choices were made and their trade-offs.

Effective ADRs include clear problem statements, evaluated alternatives with reasoning, selected decision, and documented consequences or risks. This Skill shows a deliberately poor example to illustrate what to avoid: minimal details, missing alternatives, and incomplete rationale.

Poor ADRs lack alternatives, rationale, consequences, and risk analysis. Review your ADR against quality criteria: does it explain why this decision over others, what trade-offs exist, and what impact it has on the system and team?

ADRs apply to frontend, backend, and fullstack projects with scale-adaptive depth. Complexity scoring and project-type detection adjust documentation richness to match your project's scope and architectural needs.

A complete ADR requires the problem context, multiple considered alternatives with trade-offs, the chosen solution with justification, and explicit consequences or risks. Avoid minimal ADRs that skip alternatives and rationale.