writing-adrs について
writing-adrsは、重要なアーキテクチャ上の決定とその背景・結果を記録するためのスキルです。ADRの構成やステータス、作成時の指針を示します。
主な機能
- 01ADRに適した決定の例
- 02タイトルとステータスの構成
- 03背景・決定・理由・結果の記録
- 04簡潔な記述と採番の指針
活用シーン
- 01フレームワークやデータベースの選定記録
- 02APIパターンやコーディング規約の文書化
- 03インフラの選択肢とトレードオフの記録
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/インストール後、Claude Code で/writing-adrsを入力して読み込まれたか確認します。
詳細
アーキテクチャ決定記録の作成
ADR とは？
アーキテクチャ決定記録には、重要なアーキテクチャ上の決定と、その背景や結果を記録します。
ADR を作成するタイミング
- フレームワークやライブラリを選択するとき
- データベースやストレージソリューションを選定するとき
- API のパターンを定義するとき
- コーディング規約を定めるとき
- インフラストラクチャに関する決定をするとき
- 複数のコンポーネントに影響するあらゆる決定
ADR の構成
タイトル
決定の内容を表す短いフレーズです。
ステータス
- Proposed：検討中
- Accepted：決定済み
- Rejected：検討したものの採用せず
- Deprecated：無効
- Superseded：別の ADR に置き換え済み
背景
どのような状況でしょうか？どのような要因が関係していますか？
決定
どのような変更を行うのでしょうか？
根拠
なぜこれが最適な選択なのでしょうか？
結果
どのようなトレードオフがあるでしょうか？良い面と悪い面の両方を記載します。
ADR の例
# 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
ベストプラクティス
- 簡潔にまとめる：最大 1～2 ページにします
- 決定するときに書く：決定後ではなく、その時点で作成します
- 代替案を含める：検討した内容を示します
- ステータスを更新する：非推奨または置き換え済みの ADR を明記します
- 連番を付ける：
ADR-001、ADR-002など
コメント
Markdown 対応