rebrgen-adr

name	rebrgen-adr
description	設計判断が発生したとき、ADR (Architecture Decision Record) として記録を促す。設計方針の議論、「なぜこうしたか」「どっちにするか」系の会話、新しいアーキテクチャ判断が出たときに参照する。
autoTrigger	true

いつ使うか

以下のような場面で、ユーザーに ADR を書くか提案すること:

• 設計方針について議論して結論が出たとき
• 「なぜこうしたか」「こっちにした理由は」といった判断の理由が会話に出たとき
• 複数の選択肢から1つを選んだとき
• 既存の設計判断を変更・撤回したとき

ただし押しつけないこと。 軽く「ADR に残しますか？」と聞く程度にする。ユーザーが不要と言えばそれで良い。

brgen の 3 つの基本目標

設計判断の動機を記録する際の基準軸:

1. enough to represent formats — 世の中のバイナリフォーマットを表現するのに十分な表現力
2. easy to write and read — 簡単に書ける/読める
3. write once generate any language code — 一回書けば様々な言語で生成

すべての判断がこの3つに紐づくわけではない。「技術的に面白い」「モチベーション維持」も正当な理由として記録する。

ADR の書き方

テンプレート: docs/decisions/TEMPLATE.md

ファイル名: docs/decisions/NNNN-短い説明.md（番号は連番）

テンプレート構成

# タイトル

## 日付

YYYY-MM-DD これは記録した時点の日付であっても、判断が行われた日付であっても良い。明確なルールはない。

## 判断

何を決めたかを 1-2 文で。

## 動機

- 3 目標のどれに紐づくか（複数可）
- 技術的な面白さや個人的な動機も素直に

## 具体例

この判断が実際にどう適用されたか。

## これは X を意味しない

誤解されやすいポイント、境界線。

## 代替案（あれば）

検討して却下したもの、その理由。

注意

• 「これは X を意味しない」セクションは特に重要。AI が誤解しやすいポイントを明示する。
• 動機が混在していても正直に書く。「原則 X に基づく + 面白かったから」で良い。
• 完璧に書こうとしないこと。後から追記・修正できる。
• 既存の ADR と矛盾する判断をした場合、古い ADR を更新または廃止する。