mcpField
A
architecture-decision-records

architecture-decision-records

github.com/spencerpauly開発873457 回インストール13 週間前に更新
リポジトリ

architecture-decision-records について

重要な技術判断をアーキテクチャ決定記録（ADR）として残すスキルです。選択理由や代替案、後の変更を簡潔でレビューしやすい形で共有できます。

主な機能

  1. 01ADR作成時期の判断基準
  2. 02連番付きADRテンプレートと配置例
  3. 03調査からレビューまでの手順
  4. 04簡潔な記録のための指針
  5. 05置き換えられた決定へのリンク

活用シーン

  1. 01データベースやフレームワークの選定を記録
  2. 02認証方式の変更に伴うトレードオフを記述
  3. 03将来の保守担当者に判断理由を共有

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/spencerpauly/awesome-cursor-skills --skill architecture-decision-records

インストール後、Claude Code で/architecture-decision-recordsを入力して読み込まれたか確認します。

詳細

アーキテクチャ決定記録

重要な技術的決定を文書化し、将来のあなたやチームが、その選択に至った理由を理解できるようにします。

ADR を作成するタイミング

次のいずれかに当てはまる決定を行うときに作成します。

  • 後から変更するのが難しい
  • システムの複数の部分に影響する
  • 妥当な選択肢間のトレードオフを伴う
  • 6 か月後に誰かから質問されそうな内容である

例：データベースの選定、フレームワークの採用、認証方式の変更、API の再構成、ビルドツールの追加。

テンプレート

docs/decisions/（または adr/）に、連番を付けたファイルを作成します。

# 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

ワークフロー

  1. 特定：行う決定を特定します
  2. 調査：選択肢を調査します（少なくとも 2～3 個の代替案）
  3. 作成：テンプレートを使用して ADR を作成します
  4. レビュー：チームでレビューします（PR またはディスカッション）
  5. マージ：承認済みとしてマージします
  6. 参照：関連する場合は、コードコメントから参照します：// See ADR-001

ファイル名

docs/decisions/
├── 001-use-postgresql.md
├── 002-adopt-trpc-over-rest.md
├── 003-switch-to-pnpm.md
└── template.md

ヒント

  • ADR は短くまとめます。最大 1～2 ページにします
  • 現在形で書きます（「We choose X」であり、「We chose X」ではありません）
  • 決定時に書き忘れた場合は、後から ADR を作成しても問題ありません
  • 置き換えられた ADR は削除せず、置き換え先へのリンクを記載します
  • ADR は設計ドキュメントではありません。設計全体ではなく、決定を記録するものです

コメント

Markdown 対応