with one click
writing-adrs
Document architectural decisions. Use when making significant technical decisions that should be recorded. Covers ADR format and decision documentation.
Menu
Document architectural decisions. Use when making significant technical decisions that should be recorded. Covers ADR format and decision documentation.
Based on SOC occupation classification
Biome 2.x linting and formatting patterns. Use when configuring code quality tools, setting up linting rules, formatting code, or integrating with CI/CD. Covers migration from ESLint/Prettier.
Hono 4.x web framework patterns. Use when building APIs, middleware, routing, or server-side applications. Covers multi-runtime support (Node, Bun, Cloudflare Workers), validation, CORS, and error handling.
Radix UI primitive patterns. Use when building accessible, unstyled UI components like dialogs, dropdowns, tooltips, tabs, and selects. Covers Tailwind styling, keyboard navigation, animations, and portal management.
React development patterns. Use when building React components, managing state, creating custom hooks, or optimizing React applications. Covers React 19 features, TypeScript integration, and composition patterns.
Tailwind CSS 4.x utility-first styling patterns. Use when building UI components, creating responsive layouts, implementing design systems, or customizing themes. Covers CSS-first configuration, @theme directive, and component patterns.
Vite 7.x build tool patterns. Use when configuring build setup, development server, environment variables, asset handling, or optimizing production builds for React applications.
| name | writing-adrs |
| description | Document architectural decisions. Use when making significant technical decisions that should be recorded. Covers ADR format and decision documentation. |
An Architecture Decision Record captures an important architectural decision along with its context and consequences.
Short phrase describing the decision.
What is the situation? What forces are at play?
What is the change we're making?
Why is this the best choice?
What are the trade-offs? Both positive and negative.
# ADR: Use PostgreSQL for Primary Database
## Status
Accepted
## Context
We need a database for our new service. Requirements:
- ACID transactions
- JSON support
- Strong ecosystem
- Team familiarity
## Decision
We will use PostgreSQL 15+ as our primary database.
## Rationale
- Mature, reliable RDBMS
- Excellent JSON support with JSONB
- Strong extension ecosystem (pgvector, PostGIS)
- Team has deep PostgreSQL experience
- Well-supported by all cloud providers
## Consequences
### Positive
- Reliable, battle-tested technology
- Rich feature set
- Easy to find developers
### Negative
- Vertical scaling has limits
- Requires careful connection management
- More operational overhead than managed NoSQL
ADR-001, ADR-002, etc.