菜单
Document technical decisions as Architecture Decision Records (ADRs) with context, options considered, and rationale.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | architecture-decision-records |
| description | Document technical decisions as Architecture Decision Records (ADRs) with context, options considered, and rationale. |
| user-invocable | true |
Document significant technical decisions so future you (and your team) understands why choices were made.
Write one when you're making a decision that:
Examples: choosing a database, adopting a framework, changing auth strategy, restructuring the API, adding a build tool.
Create files in docs/decisions/ (or adr/) with sequential numbering:
# ADR-001: Use PostgreSQL for primary database
## Status
Accepted | Proposed | Deprecated | Superseded by ADR-XXX
## Date
2026-04-10
## Context
What is the problem or situation that requires a decision?
Include constraints, requirements, and forces at play.
## Options Considered
### Option A: PostgreSQL
- Pros: ACID compliance, JSON support, mature ecosystem, free
- Cons: Requires managing connections, vertical scaling limits
### Option B: MongoDB
- Pros: Flexible schema, horizontal scaling
- Cons: No transactions across collections, eventual consistency issues
### Option C: PlanetScale (MySQL)
- Pros: Serverless, branching, managed
- Cons: Vendor lock-in, no foreign keys in their branching model
## Decision
We chose **PostgreSQL** because:
1. Our data is relational — users, teams, projects with clear relationships
2. We need ACID transactions for billing operations
3. JSON columns give us schema flexibility where needed
4. Prisma/Drizzle have excellent Postgres support
## Consequences
- We need to manage connection pooling (use PgBouncer or Prisma's built-in pool)
- Migrations must be backwards-compatible for zero-downtime deploys
- We accept vertical scaling limits and will shard later if needed
// See ADR-001docs/decisions/
├── 001-use-postgresql.md
├── 002-adopt-trpc-over-rest.md
├── 003-switch-to-pnpm.md
└── template.md
Solve a hard problem by trying multiple approaches in parallel using isolated git worktrees. Each attempt runs in its own branch, and the best solution is selected. Use for complex refactors, tricky bugs, or architectural decisions where multiple strategies could work.
Drafts and refines product requirement documents (PRD) for software projects—problem statement, goals, personas, scope, functional/non-functional requirements, user stories, acceptance criteria, risks, and rollout. Use when the user asks for a PRD, product requirements, feature specification, scope doc, "what to build," prioritization framing, or before breaking work into implementation tasks.
Automatically persist useful context — research, decisions, learnings, templates — to workspace files so knowledge survives across conversations.
Enforce a configuration-driven design system when generating UI. Ensures consistent spacing, colors, typography, dark mode, interactions, and accessibility across all AI-generated components.