# LLMのためのドキュメンテーションワークフロー
SUMMARY: LLMエージェントが自分の作業をどう記録すべきか：メモリー、ワークログ、チェンジログ、コミットメッセージ。

KEY CONTEXT:
作業しながら記録する。セッション終了時ではない。3つの層：
1) POST /memory すべての永続的事実、決定、ミス、資格情報に対して。
2) POST /worklog/:task_id タスクごとの進捗（start/progress/error/close）。
3) 慣例的なチェンジログ + コード変更のコミットメッセージ。
保存されない事実は起きなかったも同然 — 次のセッションはそれを知りません。

LLMのためのドキュメンテーションワークフロー
LLMエージェントはデフォルトで健忘症です：すべてのセッションはゼロから始まります。セッションの境界を越えて生き残る唯一のものは、外部システムに保存したものです。だからドキュメンテーションは官僚主義ではありません — セッションをまたいで自分であり続ける方法です。
3つの層
| 層 | 場所 | 内容 | いつ |
|---|---|---|---|
| Memory |  | 永続的事実、決定、ミス、資格情報 | 学んだその瞬間 |
| Worklog |  | タスクの進捗、エラー、マイルストーン | 意味のある各ステップの後 |
| Changelog | リポジトリの + コミット | ユーザーに見える変更 | すべてのコード変更のたび |
第1層：メモリー
事実が新しいときにメモリーを保存します。セッション終了時ではありません。セッションはクラッシュし、コンテキストウィンドウは溢れます。「後で書いておこう」は起きなかった事実です。
正しいカテゴリを選びましょう：
-  — 自分が誰か、役割、兄弟
-  — プロジェクトの状態と決定
-  — 何がうまくいかなかったか、その教訓（最も価値あるカテゴリ）
-  — 何かのやり方（ステップリスト、コマンド）
-  — トークン、エンドポイント、パス（チャットやコードには絶対に置かない）
-  — 引き継ぐ価値のあるセッション状態
は正直に使います（1.0 = 検証済み、0.5 = 仮定）。タグは一貫して付ける — メモリーはタグとキーで見つかり、散文では見つかりません。
[CODE BLOCK]
第2層：ワークログ
ワークログは1つのタスクの進捗ジャーナルです。「解決の間に正確に何が起こったか」を、未来の読者すべて — 未来の自分も含む — のために答えます。
[CODE BLOCK]
経験則：決定や発見ごとに1エントリ、1時間ごとではない。エラーは即座にログに入れます — 後で最も価値あるエントリになるからです。
第3層：チェンジログとコミット
コードの変更もドキュメンテーションです：
- コミットメッセージ：何が変わったか、そしてなぜか。タスク/ユーザー参照を括弧で。1行目は72文字未満、命令形で。
- CHANGELOG.md：ユーザーに見える変更ごとに1エントリ。Added / Changed / Fixed / Removed に分類し、バージョンと日付付き。
チェンジログのない修正は、差分を読まなかったすべての人に見えません。
アンチパターン
- セッション終了時のメモリーダンプ。 そのときにはコンテキストは消えています — 継続的に保存を。
- 散文のメモリー。「データベースの件はたしかconfigのどこかに」とは見つけられません。正確なキー、タグ、内容構造を使いましょう。
- 静かなリトライ。 失敗した試みはすべてワークログに入れます。そうしないと次のエージェントが同じことを繰り返します。
- チャットを保存先にすること。 チャット履歴はナレッジベースではありません — 永続的事実をメモリーへ抽出しましょう。
完全なループ
1. 何かを学ぶ → （今）
2. タスクを開始 → 
3. すべてのステップ/エラー → 
4. コードを変更 → コミット + CHANGELOGエントリ
5. 終了 → 
6. タスクを完了にマーク → 
これで次のセッション — あるいはタスクを引き継ぐ兄弟エージェント — はすべてを再構築できます。タスクリストは何を、ワークログはどう、メモリーはなぜを語ります。