Menü
MADR format, decision log best practices, superseding decisions
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
AWS service selection, well-architected lens, cost patterns
Managed vs self-hosted, multi-cloud, egress costs
Docker, Kubernetes, ECS, Fly.io, Railway — when to use each
Scalability patterns, CAP theorem, database selection, caching
You are a senior backend engineer operating production-grade services under strict architectural and reliability constraints. Use when routes, controllers, services, repositories, express middleware, or prisma database access.
Use when the user wants to design a mobile app, create screens, build UI, or interact with their Sleek projects. Covers high-level requests ("design an app that does X") and specific ones ("list my projects", "create a new project", "screenshot that screen").
| name | adr-writing |
| description | MADR format, decision log best practices, superseding decisions |
An ADR is a short document capturing a significant architectural decision: the context, the options considered, the decision made, and the consequences. It is committed to the repo alongside the code it governs.
Why bother? Future you — and your teammates — need to know why the system is the way it is, not just what it is. ADRs prevent re-litigating the same decisions and make onboarding dramatically faster.
Use this template. Keep it concise — an ADR is not a design doc. It should be readable in under 5 minutes.
# ADR-[NUMBER]: [Short Title]
**Date:** YYYY-MM-DD
**Status:** [Proposed | Accepted | Deprecated | Superseded by ADR-XXX]
**Deciders:** [Names or team]
---
## Context and Problem Statement
[1–3 sentences. What is the situation and why does a decision need to be made?]
## Decision Drivers
- [Constraint or quality attribute that matters most]
- [e.g., "team has no Kubernetes experience"]
- [e.g., "must handle 50K req/s at peak"]
## Options Considered
### Option 1: [Name]
[Brief description]
**Pros:**
- ...
**Cons:**
- ...
### Option 2: [Name]
...
### Option 3: [Name]
...
## Decision
**Chosen option: [Name]**
[2–4 sentences explaining why this option was chosen over the others, tied directly to the decision drivers above.]
## Consequences
**Positive:**
- [What gets better]
**Negative / Trade-offs:**
- [What we give up or take on]
**Risks:**
- [What could invalidate this decision and trigger a revisit]
## Links
- [Related ADR, RFC, or doc]
- [Benchmark or article that informed the decision]
Store ADRs in: docs/architecture/decisions/
File naming: ADR-0001-short-title.md, ADR-0002-short-title.md, ...
Zero-pad to 4 digits so they sort correctly in any file explorer.
Proposed → Accepted → Deprecated
↘ Superseded by ADR-XXXX
| ✅ Do | ❌ Don't |
|---|---|
| Capture the why, not just the what | Document obvious decisions that needed no deliberation |
| List options you actually considered | List strawman options you never seriously evaluated |
| Record the constraints that drove the decision | Write a general design doc — ADRs are decisions, not tutorials |
| Link to supporting evidence (benchmarks, docs) | Leave status as "Proposed" forever |
| Update status when a decision is superseded | Delete or rewrite old ADRs |
Write an ADR when the decision:
Skip an ADR for:
Maintain an INDEX.md in docs/architecture/decisions/:
# Architecture Decision Records
| ADR | Title | Status | Date |
|-----|-------|--------|------|
| [ADR-0001](ADR-0001-use-postgresql.md) | Use PostgreSQL as primary database | Accepted | 2024-01-15 |
| [ADR-0002](ADR-0002-event-driven-notifications.md) | Use event-driven architecture for notifications | Accepted | 2024-02-03 |
adr new "Use PostgreSQL as primary database"