3.2 KiB
3.2 KiB
name, description, disable-model-invocation, argument-hint
| name | description | disable-model-invocation | argument-hint | |
|---|---|---|---|---|
| decide | 設計上の決定を記録する。メインドキュメントの更新・検討済み案の記録・journal作成・コミットを一度に行う。 | true |
|
決定を記録する
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-<topic>.md を作る。トピックを詰め込まない(1決定1ファイル)。
構成は上から順に:
- 結論 — 何を採用したか
- 案の比較 — 簡潔な表。メリット/デメリットを1行ずつ
- 検証ログ・根拠・捨てた案の詳細
冒頭20行で結論と選択肢が分かること。整形は最低限でよい。 他ファイルへのリンクも、他ファイルからのリンクも張らない。
4. 推測を扱う
この決定が未確認の推測に依存する場合:
- メインドキュメント本文に
[推測:P-n]を付ける - 末尾の
## 未確認事項に項目を足し、何を確認できれば事実に格上げできるかを書く
逆に、この決定で検証が済んだ推測があれば、タグを外して ## 未確認事項 から削除する。
本文タグと末尾項目は必ず対で操作する(片方だけ残さない)。
5. コミットする
メインドキュメントと journal を同じコミットに入れる。1コミット1決定。
メッセージ:
<何を変えたか(1行)>
<なぜそうしたか 数行>
Journal: journal/2026-09-16-cluster-metadata.md
「なぜ」の詳細はコミットメッセージに書ききらない。journal 側にある。
注意
- 決定が固まっていない段階では使わない。調査中は journal だけ書けばよい。
- 複数の決定をまとめてコミットしない。分ける。