--- name: decide description: 設計上の決定を記録する。メインドキュメントの更新・検討済み案の記録・journal作成・コミットを一度に行う。 disable-model-invocation: true argument-hint: [決定の要旨] --- # 決定を記録する AGENTS.md のルール1〜4に従い、決定を4箇所に分散して記録する。 どれか1つでも欠けると後から追えなくなるので、全部やる。 ## 手順 ### 0. 決定内容を確認する 以下が揃っているか確認し、足りなければユーザーに聞く。推測で埋めない。 - 採用した案は何か - それによって**今後効く制約**は何か(却下理由ではなく、現在の状態として書ける文) - 落とした案があるか - この決定が未確認の推測に依存していないか ### 1. メインドキュメントを更新する 該当する直下の `*.md` を更新する。 - 採用した案・現在の設定を書く。「なぜAなのか」は1〜3行まで。 - 「なぜBではないのか」は書かない。代わりに**制約文**として書く。 - ✗ `B案はKLEパーサーが壊れるので却下した` - ○ `クラスター情報はKLE JSONに出力しない(KLE互換性の制約)` - 比較表・検討過程・ベンチマーク結果をここに書かない。 ### 2. 落とした案を1行残す メインドキュメント末尾の `## 検討済み・非採用` に追記する。 ``` - labels[9] へのID埋め込み (journal/2026-09-16-cluster-metadata.md) ``` - 理由は書かない。journalファイル名だけ。 - セクションが5行を超えたら、古いものから落とす。長くなるのは書きすぎのサイン。 ### 3. journal を書く `journal/YYYY-MM-DD-.md` を作る。トピックを詰め込まない(1決定1ファイル)。 構成は上から順に: 1. **結論** — 何を採用したか 2. **案の比較** — 簡潔な表。メリット/デメリットを1行ずつ 3. 検証ログ・根拠・捨てた案の詳細 冒頭20行で結論と選択肢が分かること。整形は最低限でよい。 他ファイルへのリンクも、他ファイルからのリンクも張らない。 ### 4. 推測を扱う この決定が未確認の推測に依存する場合: - メインドキュメント本文に `[推測:P-n]` を付ける - 末尾の `## 未確認事項` に項目を足し、**何を確認できれば事実に格上げできるか**を書く 逆に、この決定で検証が済んだ推測があれば、タグを外して `## 未確認事項` から削除する。 本文タグと末尾項目は必ず対で操作する(片方だけ残さない)。 ### 5. コミットする メインドキュメントと journal を**同じコミット**に入れる。1コミット1決定。 メッセージ: ``` <何を変えたか(1行)> <なぜそうしたか 数行> Journal: journal/2026-09-16-cluster-metadata.md ``` 「なぜ」の詳細はコミットメッセージに書ききらない。journal 側にある。 ## 注意 - 決定が固まっていない段階では使わない。調査中は journal だけ書けばよい。 - 複数の決定をまとめてコミットしない。分ける。