LLM 支援開発で生成される文書に、位置づけ・出所・依存・現行性を与えて追跡可能にするための情報統治体系である。仕様を Markdown で公開し、MIT ライセンスで提供する。使い方は二通り。仕様を LLM に渡して各プロジェクトで実装させるか、同梱の参照実装プラグインをそのまま導入するか、プロジェクトに合う方を選ぶ。
このリポジトリは、情報統治の単一仕様（spec/doctrine.ja.md、文書 ID DOCTRINE-001）を公開する。仕様は、文書の位置づけ（現行・廃止・未決・根拠）を構造に書き込み、人間と LLM の双方が追跡できる状態を作る方法を、番号付き要求 R1〜R10 として定義する。文書型のテンプレートは、仕様の付録 A・B に含む。
利用者は仕様を LLM（主に Claude）に渡し、自分のプロジェクトに合う形で実装するよう依頼する。実装形態はプロジェクトが選ぶ。プレーンな doctrine_docs/ でも、CLAUDE.md / AGENTS.md の規約でも、Claude Code の Skills と Hooks でもよい。
LLM 支援開発では、仕様・実装・調査・判断・廃止・未決が、同じ粒度と同じ見た目で並ぶ。後から読むと、どれが現行で、何に依存し、なぜそこにあるかが分からない。LLM 自身も、廃止や古いログを現行として再採用する。
対策として常時投入を増やすと、コーディングエージェントの成功率はむしろ下がり、推論コストは増える（入力が長いほどモデルの成功率が下がるという知見。出典は下記）。本体系は、量を増やすのではなく、各情報片に位置づけ・出所・依存・現行性を付与して追跡可能にする。
- 文書は資産ではなく負債である。生成はほぼ無料になったが、読む・保守する・内容を信頼してよいか見極めるコストは人間に残る。少なく書き、積極的に消し、各事実の正本を一つだけ保つ。
- LLM の典型的失敗（廃止方針の復活・未決の既決化・仕様と実装の取り違え）は、情報の位置づけが文書構造に書かれていないことに起因する。位置づけ・出所・依存・現行性を構造化して追跡可能にする。
- 渡す情報は多いほど良いのではない。常時投入は最小の非自明な事実に絞り、CLAUDE.md / AGENTS.md は知識の集積ではなく、入口だけを示す最小限の案内にする。
二通りある。仕様が正本で、プラグインはその参照実装である。
- 仕様（spec/doctrine.ja.md）の全文をコピーする。
- LLM に貼り付け、下のプロンプトを添えて実装を依頼する。
- LLM が提案した実装方針を確認し、プロジェクトに合わせて調整する。
コピー用プロンプト（例）:
添付の仕様（LLM 開発のための情報統治）を読み、このリポジトリに合う形で
情報統治を実装してください。
- 実装形態は問わない。プレーンな doctrine_docs/、CLAUDE.md / AGENTS.md の規約、
または Claude Code の Skills + Hooks のうち、このプロジェクトに最も
使いやすい形を選んでください。
- 最小構成から始める。空のフォルダ群を先に作らない。
- まず実装方針を提案し、私の承認を得てから着手してください。
実装形態は問わない。プレーンな doctrine_docs/ でも、CLAUDE.md / AGENTS.md の規約でも、Skills と Hooks でもよい。文書を一つずつ手で作る場合は、仕様の付録 A・B にある文書型テンプレートをコピーして使う。
決められた形（Skill・Hook・スクリプト・テンプレート）でよければ、同梱の参照実装プラグインをそのまま導入できる。
/plugin marketplace add Forest-Project-Lab/doctrine
/plugin install doctrine@forest-project-lab
導入後、Skill docs-system-init を起動すると、_system の最小配置とルートの案内を置く。詳細は plugin/README.md にある。
doctrine/
├── README.md # このファイル（入口）
├── LICENSE # MIT
├── CONTRIBUTING.md # 寄稿の方針と文章規範
├── spec/
│ └── doctrine.ja.md # 単一仕様 DOCTRINE-001（正本。付録に文書型テンプレート）
├── plugin/ # 参照実装プラグイン（Skill 7・Hook 4イベント・スクリプト・テンプレート）
├── .claude-plugin/
│ └── marketplace.json # /plugin install で導入するための marketplace 登録
├── doctrine_docs/ # プラグイン自身の設計を統治した設計コーパス（dogfood）
├── CLAUDE.md # 投影：Claude 向けの最小の入口
└── AGENTS.md # 投影：エージェント向けの最小の入口
本体系の効果は、適切に運用された場合に、特定の失敗類型を検出・早期発見できることに限定される。100% の予防は構造上できない。参照実装プラグインは、これに加えて一部の違反（ドメイン外依存・不変物の改変・依存が残る削除）を実行前に拒否する『予防』も行う。詳細は plugin/README.md の保証限界にある。
検出・早期発見できるもの（構造で対処）:
- 必須メタデータの欠落、ステータス語彙の逸脱、ID とファイル名の不一致、型とフォルダの不整合。
- 無効な参照（dead link）と依存グラフの破れ。
- 廃止・未決・禁止事項の常時不在による退行と既決化。
- 現行文書の陳腐化の疑い（レビュー期限の超過）。
人間レビューとテストに委ねるもの（構造だけでは閉じない）:
- 仕様が実装どおりに動くかの最終検証。これはテストの責務である。
- 抽象的なビジネス要求が、真に満たすべきものを満たすかの判断。
- 暗黙の前提の記述漏れ。人間が書き忘れた前提は、構造では補完できない。
- LLM の確率的逸脱と、外部依存（API 仕様・価格・法令）の予告なき変更。
仕様を Markdown で配ると、各プロジェクトが自分に合う形で実装できる。プレーンな doctrine_docs/ で足りるプロジェクトもあれば、Skills と Hooks まで必要なプロジェクトもある。固定したプラグインだけを配ると、この選択肢を奪う。だから正本は仕様に置き、プラグインは任意の参照実装として同梱する（方法B）。
Markdown は依存関係を持たず、どの LLM・どの環境でも読める。仕様を貼って依頼するだけで実装に入れる。これが「一枚を渡せばどこでも使い回せる」の意味である。
MIT License。LICENSE を参照。商用利用・改変・再配布を許可する。
仕様の基盤となる出典は、spec/doctrine.ja.md の付録C に示す（ASD-STE100・S1000D・DO-178C・MBSE/SysML・c-TF-IDF・JTCA ほか）。常時投入を最小に保つ根拠は、入力が長いほどモデルの成功率が下がるという知見（ETH Zürich & LogicStar.ai, arXiv:2602.11988, 2026）に基づく。あわせて本 README は、記録管理（ISO 15489）、要求工学（ISO/IEC/IEEE 29148）、ADR（Michael Nygard）、Diátaxis、C4 モデルも参照する。