mcpField
A
architecture-decision-records

architecture-decision-records

github.com/revitalb-port開発071 回インストール11 週間前に更新
リポジトリ

architecture-decision-records について

architecture-decision-recordsは、重要な技術的選択とその理由を記録するスキルです。チームや将来の保守担当者向けに、作成基準、簡潔なADRテンプレート、命名規則、レビュー手順を示します。

主な機能

  1. 01ADR作成の判断基準
  2. 02連番付きADRファイル
  3. 03状態と日付を含む決定テンプレート
  4. 04調査とレビューの手順
  5. 05コードから決定を参照する指針

活用シーン

  1. 01データベースやフレームワークの選択記録
  2. 02選択肢間のトレードオフの文書化
  3. 03複数領域に関わる決定の記録
  4. 04将来の保守担当者への判断理由の保存

インストール

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

$npx skills add https://github.com/revitalb-port/skills-registry-demo --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 対応