@k2works/claude-code-booster 6.3.1 → 6.5.0

package/lib/assets/.claude/skills/creating-development-strategy/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: creating-development-strategy
-description: 開発戦略ドキュメント（docs/development/development_strategy.md）の作成・更新を支援。イテレーション計画（planning-releases でのイテレーション作成）を前提に、イテレーション群を序盤・中盤・終盤の局面に分け、各局面で採用する TDD アプローチ（アウトサイドイン / インサイドアウト）、ウォーキングスケルトンの基盤化、イテレーションのデモ項目を受け入れ基準（E2E / 受け入れテスト）とする方針、設計ドキュメント整合方針を定義する。「開発戦略を作りたい」「開発の進め方を局面ごとに決めたい」「アウトサイドインとインサイドアウトをどう使い分けるか整理したい」「ウォーキングスケルトンの方針を文書化したい」「デモ項目を受け入れ基準にする方針を決めたい」「イテレーションと設計ドキュメントの整合方針を決めたい」といった場面で必ず発動する。リリース計画・イテレーション計画を作成した後、開発フェーズに着手する前に開発戦略を定めておくことで、局面が変わってもアーキテクチャと品質の一貫性を保った開発を進められる。特定の言語・フレームワークに依存しない汎用スキルであり、参照元・コマンド・テスト構成は対象プロジェクトの実構成に合わせて解決する。
+description: 開発戦略ドキュメント（docs/development/development_strategy.md）の作成・更新を支援。イテレーション計画（planning-releases でのイテレーション作成）を前提に、イテレーション群を序盤・中盤・終盤の局面に分け、各局面で採用する TDD アプローチ（アウトサイドイン / インサイドアウト）、ウォーキングスケルトンの基盤化、イテレーションのデモ項目を受け入れ基準（E2E / 受け入れテスト）とする方針、設計ドキュメント整合方針、Living Documentation によるドキュメントとコードの同期方針を定義する。「開発戦略を作りたい」「開発の進め方を局面ごとに決めたい」「アウトサイドインとインサイドアウトをどう使い分けるか整理したい」「ウォーキングスケルトンの方針を文書化したい」「デモ項目を受け入れ基準にする方針を決めたい」「デモ項目を BDD のシナリオにする方針を決めたい」「アウトサイドインで BDD を使うか決めたい」「イテレーションと設計ドキュメントの整合方針を決めたい」「Living Documentation を開発に組み込みたい」「ドキュメントをコードと同期させる方針を決めたい」「用語集や設計図をコードから生成する方針を決めたい」といった場面で必ず発動する。リリース計画・イテレーション計画を作成した後、開発フェーズに着手する前に開発戦略を定めておくことで、局面が変わってもアーキテクチャと品質の一貫性を保った開発を進められる。特定の言語・フレームワークに依存しない汎用スキルであり、参照元・コマンド・テスト構成は対象プロジェクトの実構成に合わせて解決する。
 ---
 
 # 開発戦略作成
@@ -19,7 +19,9 @@ description: 開発戦略ドキュメント（docs/development/development_strat
   - **イテレーション × ユーザーストーリーのマクロ配分**: `docs/development/release_plan.md`（あれば SSoT。無ければ計画済みイテレーションから局面を導く）
   - **TDD アプローチ・手順・品質基準**: 対象プロジェクトのコーディング/テストガイド（例: `docs/reference/コーディングとテストガイド.md`）
   - **テスト種別・受け入れ/E2E 方針**: 対象プロジェクトのテスト戦略（例: `docs/design/test_strategy.md`）
+  - **受け入れテストの記述形式（BDD / Gherkin）**: `docs/reference/BDD導入ガイド.md`（アウトサイドインの入口をシナリオで定義する場合）
   - **画面遷移・ナビゲーション**（UI を持つ場合）: UI 設計（例: `docs/design/ui_design.md`）
+  - **ドキュメントとコードの同期方針（Living Documentation）**: `docs/reference/LivingDocumentation導入ガイド.md`。個別の手法は `アノテーション導入ガイド.md`・`ダイナミックキュレーション導入ガイド.md`・`ガイドツアー・サイトシーイング導入ガイド.md`（いずれも `docs/reference/`）
 
 ## 前提: イテレーション計画
 
@@ -56,13 +58,67 @@ description: 開発戦略ドキュメント（docs/development/development_strat
 - **中盤・終盤**: 各 `iteration_plan-N.md` の **デモ項目をそのままパスする受け入れ/E2E テスト** を追加し、当該 IT の受け入れ基準とする。デモ項目を「操作/リクエストの系列」に翻訳してテスト化する。
 - **判定**: 当該 IT のデモ項目テストがすべて green であることを DoD に含める。green でなければイテレーションはクローズしない。追加したテストは以降も実行し、既存デモ項目の回帰を防ぐ。
 
+### アウトサイドインの入口を BDD で定義する
+
+アウトサイドインは「一番外側のテストから内へ向かう」アプローチなので、その最外殻をどう書くかで戦略の質が決まる。デモ項目を自然言語のまま人が実演するだけにせず、**BDD のシナリオ（Gherkin）として書いて実行可能にする**と、デモ項目・受け入れテスト・ドキュメントが 1 つの成果物に収束する。記法・処理系・実装手順は `docs/reference/BDD導入ガイド.md` に従う。
+
+BDD を採用するかはプロジェクトの判断だが、採用する場合は開発戦略に次を明記する。
+
+- **どの局面で使うか** — 序盤・終盤のアウトサイドイン局面で使う。中盤のインサイドアウト局面ではドメイン層の単体テストが主役になるため、BDD シナリオは既存分の回帰実行にとどめる
+- **誰が書くか** — デモ項目の元になるシナリオは、実装前にスリーアミーゴ（Biz / Dev / Tester）で合意する。AI-DLC ではこの合意が Mob Elaboration に相当し、シナリオが人と AI の契約になる
+- **記述言語** — 対象プロジェクトのユビキタス言語に合わせる。日本語で業務を語るなら `# language: ja` の日本語 Gherkin で書き、プロジェクト内で言語を混在させない
+- **処理系と配置** — 採用する Cucumber 系処理系（Cucumber-JS / Cucumber-JVM / Reqnroll など）、フィーチャーファイルとステップ定義のディレクトリ、実行コマンドを実構成に合わせて記載する
+- **ステップ定義の責務** — ステップ定義は薄く保ち、業務ロジックを持ち込まない。アウトサイドインでは、ステップ定義から呼ぶインターフェースが「まだ無い内側」の設計を駆動する
+
+BDD を使う場合、アウトサイドインの各サイクルは次の順に進む。
+
+1. デモ項目を Gherkin のシナリオに翻訳し、スリーアミーゴで合意する
+2. シナリオを実行する。ステップ定義が無いので **Undefined** になる
+3. ステップ定義を書き、まだ無い内側のインターフェースを呼ぶ。**Red** を確認する
+4. 内側へ一段下りて（UI → アプリケーション → ドメイン → データ）、各層を TDD で実装し **Green** にする
+5. リファクタリングする。シナリオは業務語彙のまま変えない
+
+BDD を採用しない場合でも、デモ項目を「操作/リクエストの系列」へ翻訳して受け入れテスト化する方針そのものは変わらない。開発戦略には、採用・不採用のどちらであるかとその理由を書く。
+
+## ドキュメントをコードと同期させる（Living Documentation・局面横断）
+
+局面が変わるたびに設計の理解がずれる最大の原因は、手書きのドキュメントがコードより遅れることである。Living Documentation は「知識の大半はすでにコード・テスト・コミット履歴にある。それを取り出し、足りない意図と根拠だけを補い、システムと同じ速さで更新する」という考え方で、局面移行時の一貫性維持を支える。原則と手法は `docs/reference/LivingDocumentation導入ガイド.md` に従う。
+
+採用するかはプロジェクトの判断だが、開発戦略には採用・不採用とその理由を書く。採用する場合は、全イテレーションに一度に広げず、**これから書くコードから適用する**（既存コードへの一括適用はしない）。
+
+### 局面ごとの重点
+
+局面のアプローチと、そこで生まれる知識の種類に合わせて重点を変える。
+
+| 局面 | 生まれる主な知識 | Living Documentation の重点 | 参照ガイド |
+| :--- | :--- | :--- | :--- |
+| 序盤（アウトサイドイン） | アーキテクチャ・レイヤー・外部アクター | アノテーション語彙（ステレオタイプ・レイヤー）を決める。レイヤー依存をアーキテクチャテストで検証し、アーキテクチャ図・コンテキスト図をコードから生成する仕組みをスケルトンに含める | アノテーション導入ガイド |
+| 中盤（インサイドアウト） | ドメインの概念・集約・業務ルール | コア概念のハイライトと、ドメインモデルから生成する用語集（Living Glossary）でユビキタス言語をコードに一本化する。判断の根拠は ADR に残す。模範となる集約を示す | ダイナミックキュレーション導入ガイド |
+| 終盤（アウトサイドイン） | 業務シナリオ・処理の流れ | デモ項目の処理チェーンをガイドツアーとして案内し、見どころをサイトシーイング・マップにまとめる。BDD を採用していればタグでシナリオダイジェストを作る | ガイドツアー・サイトシーイング導入ガイド |
+
+### 開発戦略に明記すること
+
+- **何をコードに持たせ、何を文書に残すか** — コードで表せる知識（構造・用語・依存関係）は生成し、`docs/design/` に手で複製しない。`docs/design/` にはコードから読み取れない意図・判断・却下した代替案を残す。「イテレーションごとの設計ドキュメント整合」の方針と矛盾しないよう、生成物と手書きの境界を書く
+- **重複させた知識の検証方法** — やむを得ず重複する知識（公開 API の契約、シナリオとコードなど）は、不一致を検出するテストで守る。どのテストが整合性検証を担うかを書く
+- **アノテーション語彙** — 採用する語彙（例: `ValueObject`・`CoreConcept`・`GuidedTour`）と置き場所。言語に合わせてアノテーション・属性・デコレータ・命名規約のいずれで表すかを決め、本質的な知識だけを付ける
+- **生成と公開の自動化** — 用語集・図・ツアーの生成を、ビルドまたは CI のどの段階で実行し、どこに公開するか（対象プロジェクトの実構成に合わせる）。手作業で更新する一覧は作らない
+- **根拠の記録先** — 設計判断は ADR（`creating-adr`）、変更ごとの意図はコミットメッセージ（`git-commit`）に残す
+
+### 完了条件への組み込み
+
+採用する場合、各イテレーションの完了条件に次を加える。
+
+- 生成するドキュメント（用語集・図・ツアーなど）の生成がビルドまたは CI で成功している
+- その IT で下した設計判断が ADR に記録され、コードで表せない根拠だけが `docs/design/` に反映されている
+- 手書きでコードの内容を複製した一覧・図が新たに増えていない
+
 ## 作成の進め方
 
 1. **参照元を読む**: コーディング/テストガイド（アプローチのシーケンス・品質基準・コミット規約）、計画済みの各 `iteration_plan-N.md`（対象 US・デモ項目）、あれば `release_plan.md`（マクロ配分）を読み込む。
 2. **局面を割り当てる**: 計画済みイテレーションを局面へ振り分ける。基盤・入口の IT を序盤、複雑ドメイン中核の IT を中盤、例外・仕上げの IT を終盤とする。未計画分は暫定案とする。
 3. **共通の TDD サイクル節を書く**: Red-Green-Refactor と品質チェック（対象プロジェクトの実ビルド/テストコマンド）、テスト種別とレイヤーの対応表を、実構成を確認して記載する。
-4. **各局面の節を書く**: 目的・対象ユーザーストーリー・ワークフロー（アウトサイドイン/インサイドアウトのシーケンスに基づく PlantUML/Mermaid）・手順・完了条件を記述する。完了条件には該当 IT のデモ項目受け入れテスト green を含める。
-5. **横断方針を書く**: デモ項目を受け入れ基準とする方針、局面移行時の一貫性維持、アプローチが変わっても不変な規律（サイクル 3 原則・コミット単位・品質基準・アーキテクチャテスト常時グリーン）を明記する。
+4. **各局面の節を書く**: 目的・対象ユーザーストーリー・ワークフロー（アウトサイドイン/インサイドアウトのシーケンスに基づく PlantUML/Mermaid）・手順・完了条件を記述する。完了条件には該当 IT のデモ項目受け入れテスト green を含める。アウトサイドイン局面で BDD を採用する場合は、シナリオの記述言語・処理系・配置・ステップ定義の責務を明記する（`docs/reference/BDD導入ガイド.md` 参照）。
+5. **横断方針を書く**: デモ項目を受け入れ基準とする方針、Living Documentation の採用可否と局面ごとの重点（`docs/reference/LivingDocumentation導入ガイド.md` 参照）、局面移行時の一貫性維持、アプローチが変わっても不変な規律（サイクル 3 原則・コミット単位・品質基準・アーキテクチャテスト常時グリーン）を明記する。
 6. **インデックスを同期する**: `operating-docs --update` で `docs/development/index.md` と `mkdocs.yml` に開発戦略を追加する。
 7. コミットは `git-commit`（ユーザー指示があるまでコミットしない）。
 
@@ -74,7 +130,8 @@ description: 開発戦略ドキュメント（docs/development/development_strat
 ## 概要（参照元と Single Source of Truth の明記・イテレーション計画前提）
 ## 戦略の全体像（局面 → アプローチの対応表・図）
 ## 共通の TDD サイクル（Red-Green-Refactor・テスト種別対応・品質チェック）
-## デモ項目を受け入れ基準とする（受け入れ/E2E 方針）
+## デモ項目を受け入れ基準とする（受け入れ/E2E 方針・BDD 採用可否）
+## ドキュメントをコードと同期させる（Living Documentation 採用可否・局面ごとの重点・生成と公開）
 ## 序盤: アウトサイドイン（目的 / 対象 US / ワークフロー / 手順 / 完了条件）
 ## 中盤: インサイドアウト（同上。中核が単純なら省略可）
 ## 終盤: アウトサイドイン（同上）
@@ -114,6 +171,8 @@ description: 開発戦略ドキュメント（docs/development/development_strat
 - 本スキルは **イテレーション計画を前提** とする。イテレーションが未計画なら先に `planning-releases` で計画する。少なくとも序盤の IT に対象 US とデモ項目が定義されていること。
 - アプローチ選択は必ず対象プロジェクトのコーディング/テストガイドの選択フローに理由づける。「なぜこの局面でこのアプローチか」を書かないと、単なる区切り表になり戦略の価値が失われる。
 - `ALWAYS`/`MUST` の羅列でなく、各局面の狙い（why）を説明する文体にする。局面が変わっても不変な規律（Red-Green-Refactor 3 原則・1 コミット 1 変更・品質基準・アーキテクチャテスト常時グリーン）は明記する。
+- BDD を採用する場合、シナリオの記述形式・処理系・実装手順は `docs/reference/BDD導入ガイド.md` を正とし、本スキルでは「どの局面でどう使うか」という戦略判断だけを書く。記法の解説を開発戦略ドキュメントに複製しない。
+- Living Documentation を採用する場合も同様に、手法の解説は `docs/reference/LivingDocumentation導入ガイド.md` と個別の導入ガイドを正とし、開発戦略には「どの局面で何を生成・記録するか」という判断だけを書く。開発戦略ドキュメント自体も、イテレーション計画や設計ドキュメントの内容を複製せず参照する。
 - 品質チェックコマンド・テスト構成は対象プロジェクトの実構成を確認して合わせる（憶測で書かない。ビルド設定ファイル・テストディレクトリ・タスクランナー設定を実際に確認する）。
 - 新規作成後は `docs/development/index.md` と `mkdocs.yml` を必ず同期する。ユーザーの指示があるまでコミットしない。
 
@@ -123,5 +182,6 @@ description: 開発戦略ドキュメント（docs/development/development_strat
 - `orchestrating-development` — 開発フェーズ全体の TDD ワークフロー（本戦略の実行フェーズ）
 - `validating-iteration-plan` — イテレーション計画と設計ドキュメントの整合検証
 - `developing-backend` / `developing-frontend` — 各局面での TDD 実装
+- `creating-adr` — 局面ごとの設計判断の根拠の記録（Living Documentation の根拠の記録先）
 - `operating-docs` — インデックス同期（`--update`）
 - `git-commit` — 作成後のコミット

package/lib/assets/.claude/skills/developing-backend/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: developing-backend
-description: バックエンド開発の TDD ワークフローを支援。Red-Green-Refactor サイクルとインサイドアウトアプローチで品質の高いバックエンドを実装する。「バックエンドを実装したい」「API を作りたい」「サーバーサイドの機能を追加したい」「バックエンドのテストを書きたい」といった場面で発動する。TDD で開発することで、リファクタリングの安全網を確保し、変更を楽に安全にできるコードを維持する。
+description: バックエンド開発の TDD ワークフローを支援。Red-Green-Refactor サイクルとインサイドアウトアプローチで品質の高いバックエンドを実装する。「バックエンドを実装したい」「API を作りたい」「サーバーサイドの機能を追加したい」「バックエンドのテストを書きたい」「ドメインモデルに役割や根拠を残したい」「API ドキュメントや用語集をコードから生成したい」といった場面で発動する。層ごとの知識を Living Documentation としてコードに持たせる実践も案内する。TDD で開発することで、リファクタリングの安全網を確保し、変更を楽に安全にできるコードを維持する。
 ---
 
 # バックエンド開発
@@ -19,6 +19,8 @@ TDD サイクルに従いバックエンドを開発する。インサイドア
 | ドメインモデル | @docs/design/domain-model.md |
 | 技術スタック | @docs/design/tech_stack.md |
 | テスト戦略 | @docs/design/test_strategy.md |
+| 開発戦略 | @docs/development/development_strategy.md（Living Documentation の採用可否・語彙・局面ごとの重点） |
+| Living Documentation | @docs/reference/LivingDocumentation導入ガイド.md、@docs/reference/アノテーション導入ガイド.md |
 
 ## TDD サイクル
 
@@ -33,6 +35,35 @@ TDD サイクルに従いバックエンドを開発する。インサイドア
 - **インサイドアウト**（推奨）: データ層から開始し上位層へ展開する
 - **アウトサイドイン**: API から開始しドメインロジックを段階的に実装する
 
+## Living Documentation の実践
+
+バックエンドの知識の大半は、スキーマ・ドメインモデル・API 定義・テストの中にある。それを設計ドキュメントに書き写すのではなく、**権威ある情報源をコードに置き、そこから生成し、足りない意図と根拠だけを補う**。採用するかどうかとアノテーションの語彙は開発戦略に従う。ここではインサイドアウトの層ごとに、何をどこに持たせるかを示す。
+
+### 層ごとの知識の持たせ方
+
+| 層 | 権威ある情報源 | 生成・検証するもの | 補う知識 |
+| :--- | :--- | :--- | :--- |
+| データ層 | マイグレーション・スキーマ定義 | ER 図・テーブル定義をスキーマから生成する。`docs/design/` のデータモデルに列定義を手で複製しない | 正規化を崩した理由などの判断は ADR に残す |
+| ドメイン層 | エンティティ・値オブジェクト・集約のコード | ドメインのクラス名・メソッド名・列挙型から用語集（Living Glossary）を生成する | 役割（`@Entity`・`@ValueObject`・`@DomainService` など）とコア概念（`@CoreConcept`）をアノテーションで補う |
+| API 層 | コントローラとリクエスト/レスポンスの型 | OpenAPI をコードから生成して公開する。外部に公開した契約は、変更を検出するテストで守る | 外部システムとの境界（連携先・方向）を宣言し、コンテキスト図の元にする |
+| 層をまたぐ構造 | パッケージ構成・レイヤー宣言 | 層の依存方向をアーキテクチャテスト（ArchUnit など）で検証し、アーキテクチャ図をコードから生成する | パッケージ単位の宣言（`package-info.java` のレイヤー・境界づけられたコンテキスト）で補う |
+
+### ドメイン層で守ること
+
+インサイドアウトで最初に固めるドメイン層は、用語集と図の出来を左右する。
+
+- **宣言的に書く**: クラス名・メソッド名・列挙型の定数名をドメインの用語にする。生成した用語集が読みにくければ、用語集ではなく名前を直す
+- **本質的な知識だけを付ける**: 不変である、副作用がない、値で同一性を判定するといった、要素を消せば一緒に消える性質だけをアノテーションにする。所有者や使われ方などの外在的な知識は付けない
+- **デフォルトを決めて例外に付ける**: 値オブジェクトを不変とする方針なら、全クラスに `@Immutable` を付けず、可変なものだけを明示する
+- **フレームワークの注釈を流用しない**: JPA の `@Entity` などの技術的な注釈はドメインの意味を表さない。ドメインの役割は独自の語彙で表す
+- **テストをシナリオとして読めるようにする**: テスト名は業務の言葉で書く。イベントソーシングを使う場合は「Given 過去のイベント / When コマンド / Then 新しいイベント」の形にし、コマンドは命令形、イベントは過去形で命名する
+
+### TDD サイクルでのタイミング
+
+- **Red**: テスト名とテストデータにドメインの用語を使う
+- **Refactor**: 名前を用語に揃え、役割と性質のアノテーションを付ける。付ける数は最小にする
+- **コミット**: 変更の意図を書く（`git-commit`）。代替案を比べて選んだ設計判断は ADR に残す（`creating-adr`）
+
 ## テストコマンド
 
 ```bash
@@ -55,6 +86,8 @@ cd apps/backend && ./gradlew bootRun
 # OpenAPI JSON: http://localhost:8080/v3/api-docs
 ```
 
+API ドキュメントはコードから生成されるので、別文書に API 仕様を手で書かない。エンドポイントの意図や制約など、コードに無い説明はアノテーションの説明文に書き、生成物に含める。
+
 ## 品質チェックリスト
 
 コミット前に必ず確認する。
@@ -64,6 +97,8 @@ cd apps/backend && ./gradlew bootRun
 - [ ] テストカバレッジが目標を満たしている
 - [ ] 単一の論理的作業単位を表現
 - [ ] コミットメッセージが変更内容を明確に説明
+- [ ] （Living Documentation 採用時）ドメインの名前が用語に揃い、開発戦略で決めたアノテーションが付いている
+- [ ] （Living Documentation 採用時）アーキテクチャテストと公開契約のテストがパスし、生成するドキュメントがビルドで生成できる
 
 ## 途中から再開
 
@@ -92,9 +127,12 @@ cd apps/backend && ./gradlew bootRun
 - コミット前に必ず品質チェックリストを実行する
 - 作業完了後に対象の @docs/development/iteration_plan-N.md の進捗を更新する
 - TODO 駆動開発でタスクを細かく分割し、Rule of Three で 3 回同じコードが現れたらリファクタリングする
+- スキーマ・クラス一覧・API 仕様など、コードから取り出せる知識を `docs/design/` に手で書き写さない。書くのはコードに無い意図と根拠だけにする
 
 ## 関連スキル
 
 - `developing-frontend` — フロントエンド TDD 開発
 - `orchestrating-development` — 開発フェーズ全体のワークフロー
 - `git-commit` — Conventional Commits 準拠のコミット
+- `creating-adr` — 設計判断の根拠の記録
+- `creating-development-strategy` — Living Documentation の採用可否・語彙・局面ごとの重点

package/lib/assets/.claude/skills/developing-frontend/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: developing-frontend
-description: フロントエンド開発の TDD ワークフローを支援。Red-Green-Refactor サイクルとアウトサイドインアプローチで品質の高い UI を実装する。「フロントエンドを実装したい」「画面を作りたい」「コンポーネントを追加したい」「フロントエンドのテストを書きたい」といった場面で発動する。TDD で開発することで、UI の振る舞いを自動テストで保証し、安全なリファクタリングを可能にする。
+description: フロントエンド開発の TDD ワークフローを支援。Red-Green-Refactor サイクルとアウトサイドインアプローチで品質の高い UI を実装する。「フロントエンドを実装したい」「画面を作りたい」「コンポーネントを追加したい」「フロントエンドのテストを書きたい」「画面遷移やコンポーネントの一覧をコードと同期させたい」「API の型をバックエンドと揃えたい」といった場面で発動する。画面とシナリオの知識を Living Documentation としてコードに持たせる実践も案内する。TDD で開発することで、UI の振る舞いを自動テストで保証し、安全なリファクタリングを可能にする。
 ---
 
 # フロントエンド開発
@@ -18,6 +18,9 @@ TDD サイクルに従いフロントエンドを開発する。アウトサイ
 | UI 設計 | @docs/design/ui-design.md |
 | 技術スタック | @docs/design/tech_stack.md |
 | テスト戦略 | @docs/design/test_strategy.md |
+| 開発戦略 | @docs/development/development_strategy.md（Living Documentation の採用可否・語彙・局面ごとの重点） |
+| Living Documentation | @docs/reference/LivingDocumentation導入ガイド.md、@docs/reference/ダイナミックキュレーション導入ガイド.md |
+| 受け入れシナリオ（BDD 採用時） | @docs/reference/BDD導入ガイド.md |
 
 ## TDD サイクル
 
@@ -32,6 +35,35 @@ TDD サイクルに従いフロントエンドを開発する。アウトサイ
 - **アウトサイドイン**（推奨）: UI から開始しロジックを段階的に実装する
 - **インサイドアウト**: ユーティリティ/hooks から開始し上位層へ展開する
 
+## Living Documentation の実践
+
+フロントエンドの知識は、ルート定義・コンポーネント・API の型・E2E テストの中にある。画面一覧や遷移図、API の型を別文書に書き写すと、画面を 1 つ足すたびに古くなる。**権威ある情報源をコードに置き、そこから生成し、足りない意図だけを補う**。採用するかどうかと語彙は開発戦略に従う。
+
+### 層ごとの知識の持たせ方
+
+アウトサイドインで外側から下りる順に並べる。
+
+| 層 | 権威ある情報源 | 生成・検証するもの | 補う知識 |
+| :--- | :--- | :--- | :--- |
+| 受け入れ（最外殻） | E2E テスト・BDD シナリオ | デモ項目をシナリオとして実行し、そのまま振る舞いの仕様として公開する | シナリオの意図（誰が何のために操作するか）をシナリオの冒頭に書く |
+| 画面・ルーティング | ルート定義 | 画面一覧と画面遷移図をルート定義から生成する。`docs/design/` の UI 設計にルート一覧を手で複製しない | 遷移の理由やロールによる制御の意図を UI 設計に残す |
+| コンポーネント | コンポーネントとその使用例 | コンポーネントカタログ（Storybook など、採用している場合）を使用例から生成する | 模範とするコンポーネントを JSDoc タグ（例: `@exemplar`）や命名規約で示す |
+| ロジック・データ | API クライアントと型 | API の型はバックエンドが公開する OpenAPI から生成し、手で書かない。生成した型とのずれは型チェックで検出する | 画面固有の状態の持ち方など、型に表れない判断を ADR に残す |
+
+### フロントエンドで守ること
+
+- **ユビキタス言語を画面に通す**: コンポーネント名・画面の文言・テスト名をバックエンドのドメイン用語と揃える。同じ概念を画面ごとに別の名前で呼ばない
+- **テストを利用者の言葉で書く**: テスト名とテスト内の操作は「ユーザーが何をするか」で書く。実装の詳細（DOM 構造やクラス名）に依存したテストは、仕様として読めない
+- **注釈は軽く保つ**: TypeScript/JavaScript は実行時に読めるアノテーションが一般にないため、JSDoc のタグ・フォルダ構成・命名規約で役割を表す。付けるのは例外と本質的な知識だけにする
+- **重複させた知識には検証を付ける**: バックエンドと共有する型・定数・ルートの権限設定は、生成するか、不一致を検出するテストで守る
+- **画面キャプチャは生成する**: マニュアル用の画面キャプチャは E2E ツールで再生成する（`creating-manual`）。手で撮り直す運用にすると画面の変更に追従しなくなる
+
+### TDD サイクルでのタイミング
+
+- **Red**: 最外殻のテスト（E2E・シナリオ）を業務の言葉で書き、そこから内側のテストへ下りる
+- **Refactor**: コンポーネント名と文言を用語に揃える。模範例や見どころの印は、付ける数を最小にする
+- **コミット**: 変更の意図を書く（`git-commit`）。状態管理やルーティングの方式など、代替案を比べて選んだ判断は ADR に残す（`creating-adr`）
+
 ## テストコマンド
 
 ```bash
@@ -57,6 +89,8 @@ cd apps/frontend && npm run test:e2e
 - [ ] テストカバレッジが目標を満たしている
 - [ ] 単一の論理的作業単位を表現
 - [ ] コミットメッセージが変更内容を明確に説明
+- [ ] （Living Documentation 採用時）コンポーネント名・文言・テスト名がドメインの用語に揃っている
+- [ ] （Living Documentation 採用時）API の型が生成物と一致し、画面一覧・遷移図などの生成物がビルドで生成できる
 
 ## 途中から再開
 
@@ -85,9 +119,13 @@ cd apps/frontend && npm run test:e2e
 - コミット前に必ず品質チェックリストを実行する
 - 作業完了後に対象の @docs/development/iteration_plan-N.md の進捗を更新する
 - コンポーネントは単一責任の原則に従い小さく保つ。TODO 駆動で分割し、Rule of Three でリファクタリングする
+- ルート一覧・コンポーネント一覧・API の型など、コードから取り出せる知識を `docs/design/` に手で書き写さない。書くのはコードに無い意図と根拠だけにする
 
 ## 関連スキル
 
 - `developing-backend` — バックエンド TDD 開発
 - `orchestrating-development` — 開発フェーズ全体のワークフロー
 - `git-commit` — Conventional Commits 準拠のコミット
+- `creating-adr` — 設計判断の根拠の記録
+- `creating-manual` — E2E ツールによる画面キャプチャの再生成
+- `creating-development-strategy` — Living Documentation の採用可否・語彙・局面ごとの重点

package/lib/assets/.claude/skills/orchestrating-development/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: orchestrating-development
-description: 開発フェーズ全体の TDD ワークフローをオーケストレーション。バックエンド・フロントエンドの開発順序と TDD サイクルの実践方法を案内し、Codex 分業体制もサポートする。「開発を始めたい」「TDD の進め方を知りたい」「Codex と分業で開発したい」「開発フェーズの全体像を把握したい」といった場面で発動する。開発フローを標準化することで、品質のブレを防ぎチーム全体の生産性を底上げする。
+description: 開発フェーズ全体の TDD ワークフローをオーケストレーション。バックエンド・フロントエンドの開発順序と TDD サイクルの実践方法を案内し、Codex 分業体制もサポートする。開発中に生まれる知識を Living Documentation としてコードと同期させる実践も案内する。「開発を始めたい」「TDD の進め方を知りたい」「Codex と分業で開発したい」「開発フェーズの全体像を把握したい」「開発しながらドキュメントをコードと同期させたい」といった場面で発動する。開発フローを標準化することで、品質のブレを防ぎチーム全体の生産性を底上げする。
 ---
 
 # 開発フェーズオーケストレーション
@@ -32,6 +32,8 @@ description: 開発フェーズ全体の TDD ワークフローをオーケス
 | イテレーション完了時（ユーザーレビュー） | `analyzing-review` | 受け入れフェーズでユーザー視点・プロダクト視点からの成果物レビュー |
 | 設計ドキュメント新規作成の直前 | `apply-docs-structure` | 開発中に設計ドキュメント・ADR を新規に書く前に配置先（プロジェクト別カテゴリの `<project>/` 配下）を判断する。配置を誤ると docs と apps のトレーサビリティが壊れ、後からの移動は索引・リンク・来歴すべての修正になる |
 | 設計ドキュメント更新時 | `apply-okf` | 開発中に `docs/design/` や ADR を更新したら OKF フロントマター（`generated`）と `log.md` を追従させる。実装で設計が変わったのに文書の来歴が古いままだと、次のイテレーションで古い設計を信頼してしまう |
+| 設計判断を下したとき | `creating-adr` | 代替案を比較して選んだ判断は、その場で文脈・理由・却下した代替案を ADR に残す。後から思い出して書くと根拠が失われる |
+| イテレーション完了時（生きたドキュメントの確認） | — | Living Documentation を採用している場合、生成するドキュメント（用語集・図・ガイドツアー）がビルドで生成できること、手書きでコードを複製した一覧・図が増えていないことを確認する（下記「Living Documentation の実践」） |
 
 ## TDD サイクル
 
@@ -42,10 +44,38 @@ TDD は「テストを書いてからコードを書く」手順ではなく、
 3. **Refactor**: 重複を除去し設計を改善する
 4. @docs/reference/コーディングとテストガイド.md のワークフローに従う
 
+## Living Documentation の実践
+
+開発中に生まれる知識（用語・構造・判断の理由）を、別文書に書き写すのではなくコードとテストに持たせ、足りない意図と根拠だけを補う。採用するかどうかと局面ごとの重点は開発戦略（@docs/development/development_strategy.md、`creating-development-strategy`）で決まっているので、ここではそれを TDD サイクルの中で実行する。原則と手法は @docs/reference/LivingDocumentation導入ガイド.md を参照する。
+
+### TDD サイクルへの組み込み
+
+新しい作業は増やさず、既存のステップの中で知識を残す。
+
+| ステップ | 知識の残し方 |
+| :--- | :--- |
+| Red | テスト名とシナリオをユビキタス言語で書く。テストは「振る舞いの仕様」として読まれるドキュメントになる |
+| Green | 最小限の実装に集中する。この段階ではドキュメントのことは考えない |
+| Refactor | 名前をドメインの用語に揃える（用語集の元になる）。開発戦略で決めた語彙に従い、役割・性質などの本質的な知識だけをアノテーション（言語によっては属性・デコレータ・命名規約）で補う |
+| コミット | 変更の意図をコミットメッセージに書く（`git-commit`）。コードの差分から読み取れる「何を」ではなく「なぜ」を書く |
+| 設計判断 | 代替案を比較した判断は ADR に残す（`creating-adr`） |
+
+アノテーションの付け方は @docs/reference/アノテーション導入ガイド.md、コア概念・模範例の選び方は @docs/reference/ダイナミックキュレーション導入ガイド.md、処理の流れの案内は @docs/reference/ガイドツアー・サイトシーイング導入ガイド.md に従う。
+
+### 守ること
+
+- **書く前に探す**: 知識がすでにコード・テスト・ADR・コミット履歴にあれば、ドキュメントに書き写さずリンクするか生成する
+- **手で複製しない**: クラス一覧・依存関係図・用語一覧など、コードから取り出せるものを `docs/design/` に手で書き写さない。`docs/design/` にはコードから読み取れない意図・判断・却下した代替案を書く
+- **重複には検証を付ける**: やむを得ず重複させた知識（公開 API の契約、シナリオとコード）は、不一致を検出するテストで守る
+- **付けすぎない**: アノテーションは例外と本質的な知識にだけ付ける。すべてのクラスに同じアノテーションを付けるとノイズになる
+- **書きにくさを設計のシグナルにする**: 名前が決まらない、図が交差だらけになるといった場合は、ドキュメントではなく設計を直す
+
 ## 参照ドキュメント
 
 - @docs/reference/コーディングとテストガイド.md — TDD ワークフロー詳細
 - @docs/reference/CodexCLIMCPアプリケーション開発フロー.md — Codex 連携フロー
+- @docs/reference/LivingDocumentation導入ガイド.md — 開発中の知識をコードと同期させる原則と手法
+- @docs/development/development_strategy.md — 局面ごとの TDD アプローチと Living Documentation の重点（あれば）
 - @docs/design/architecture.md, @docs/design/architecture_backend.md, @docs/design/architecture_frontend.md
 - @docs/design/data-model.md, @docs/design/domain-model.md, @docs/design/tech_stack.md
 - @docs/design/ui-design.md, @docs/design/test_strategy.md
@@ -98,6 +128,7 @@ graph LR
 2. **コード全文を渡す**: 自然言語の説明より、作成すべきファイルの完全なコードを指示に含める
 3. **「既存コードは変更しないでください」を明記**: 追記指示時に Codex が他の箇所を無断で書き換えるのを防ぐ
 4. **`--write` フラグを含める**: 書き込みが必要な場合は prompt 冒頭に `--write` を付ける
+5. **知識の残し方も指示に含める**: Living Documentation を採用している場合、渡すコード全文に規定のアノテーションとユビキタス言語の命名を含める。Codex に任せると語彙が揺れ、生成する用語集や図が崩れる
 
 ### Codex への指示例
 
@@ -116,6 +147,7 @@ codex:codex-rescue に以下を委譲:
 - [ ] 既存テストが壊れていない（Codex の変更で `localStorage` → `sessionStorage` 等の無断変更がないか）
 - [ ] E2E テストがすべてパス
 - [ ] ESLint / Prettier / 品質チェックがパス
+- [ ] （Living Documentation 採用時）規定のアノテーションと命名が守られ、生成するドキュメントがビルドで生成できる
 
 ### Codex の既知の問題と対策
 
@@ -159,9 +191,11 @@ codex:codex-rescue に以下を委譲:
 - コミット前に必ず品質チェックリストを実行する
 - TODO 駆動開発でタスクを細かく分割してから実装を開始する
 - Rule of Three: 同じコードが 3 回現れたらリファクタリングする
+- コードから取り出せる知識を設計ドキュメントに手で書き写さない。書くのはコードに無い意図と根拠だけにする
 
 ## 関連スキル
 
+- `creating-development-strategy` — 局面ごとの TDD アプローチと Living Documentation の重点を定める開発戦略
 - `developing-backend` — バックエンド TDD 開発
 - `developing-frontend` — フロントエンド TDD 開発
 - `developing-review` — 開発成果物のマルチパースペクティブレビュー（TODO 完了時のコードレビュー）
@@ -170,3 +204,5 @@ codex:codex-rescue に以下を委譲:
 - `developing-release` — リリースワークフロー（品質ゲート・バージョン管理・CHANGELOG）
 - `apply-docs-structure` — 設計ドキュメント・ADR を新規に書く直前の配置先判断（プロジェクト別カテゴリ）
 - `apply-okf` — 開発中に更新した設計ドキュメント・ADR への OKF 規約適用
+- `creating-adr` — 開発中に下した設計判断の根拠の記録
+- `git-commit` — 変更の意図を残すコミット

package/lib/assets/docs/article/index.md

@@ -13,5 +13,6 @@
 | [Grokking Concurrency](https://k2works.github.io/grokking-concurrency-exercise/) | 並行処理プログラミング | スレッド、同期、非同期、ノンブロッキング I/O、分散並列処理を多言語で比較できます。 |
 | [Grokking Machine Learning](https://k2works.github.io/grokking-machine-learning-excersice/) | 機械学習 | 線形回帰から決定木、ニューラルネットワーク、SVM、アンサンブル学習まで、機械学習アルゴリズムを Python・Kotlin・F# で自前実装しながら学べます。 |
 | [関数型デザイン - 原則、パターン、実践](https://k2works.github.io/functional-desgin-ppp/) | 関数型デザインパターン | OOP のデザインパターンを関数型パラダイムでどう表現するかを実践的に学べます。 |
+| [From Objects to Functions 演習](https://k2works.github.io/from-objects-to-functions-excersice/) | 関数型アーキテクチャ | To-Do アプリ Zettai を題材に、HTTP、ドメインモデリング、イベントソーシング、関数型エラーハンドリング、ファンクタ・モナドによる射影と永続化までを Kotlin・なでしこ3・Rust で実装しながら学べます。 |
 | [実践データベース設計：基幹業務システム編](https://k2works.github.io/practical-database-design/) | データベース設計 | 販売管理・財務会計・生産管理の基幹業務システムを題材に、業務フローとデータモデルを体系的に学べます。 |
 | [Docker/Kubernetes 実践コンテナ解説](https://k2works.github.io/getting-started-docker-kubernetes/) | コンテナ・オーケストレーション | コンテナの基礎から複数コンテナ構成、Kubernetes、継続的デリバリー、ケーススタディまで実践的に学べます。 |

package/lib/assets/docs/index.md

@@ -1,37 +1,37 @@
----
-okf_version: "0.2"
----
-
-# プロジェクトドキュメント
-
-プロジェクトで管理しているドキュメントの入口です。
-
-## まずこれを読もうリスト
-
-- [戦略](./strategy/index.md) - ビジネス構造やプロジェクトの方向性を整理します。
-- [要件](./requirements/index.md) - RDRA 2.0 ベースで要件を定義します。
-- [設計](./design/index.md) - アーキテクチャ、モデル、品質方針を整理します。
-- [開発](./development/index.md) - リリース計画とイテレーション管理の入口です。
-- [運用](./operation/index.md) - 環境構築、デプロイ、運用関連の入口です。
-- [記事](./article/index.md) - 学習用の記事シリーズの入口です。
-
-## ドキュメント構成
-
-| カテゴリ | 概要                                  | 状況 |
-| :--- |:------------------------------------| :--- |
-| [戦略](./strategy/index.md) | 企業分析、経営戦略、ビジネスアーキテクチャ、インセプションデッキの整理 | `index.md` を整備済み |
-| [要件](./requirements/index.md) | RDRA 2.0 とユースケース整理の入口               | `index.md` を整備済み |
-| [設計](./design/index.md) | アーキテクチャ、モデル、テスト、非機能の整理              | `index.md` を整備済み |
-| [開発](./development/index.md) | リリース計画、イテレーション計画、進捗管理               | `index.md` を整備済み |
-| [運用](./operation/index.md) | 環境構築、デプロイ、運用手順の整理                   | `index.md` を整備済み |
-| [レビュー](./review/index.md) | 分析・開発レビュー結果の記録                      | `index.md` を整備済み |
-| [ADR](./adr/index.md) | Architecture Decision Records の管理   | `index.md` を整備済み |
-| [記事](./article/index.md) | 学習用の記事シリーズ一覧                        | 公開サイトへのリンク集 |
-| [リファレンス](./reference/index.md) | 開発ガイドラインやベストプラクティス                  | 38 件のドキュメントを配置 |
-| [テンプレート](./template/index.md) | 各種ドキュメントの作成テンプレート                   | 18 件のテンプレートを配置 |
-
-## 補足
-
-- `strategy/`、`requirements/`、`design/`、`development/`、`operation/` は現時点ではカテゴリ索引が中心です。
-- `journal/` は作業ログ用の予約ディレクトリです。
-- `assets/` は MkDocs 用のスタイル・スクリプトを格納しています。
+---
+okf_version: "0.2"
+---
+
+# プロジェクトドキュメント
+
+プロジェクトで管理しているドキュメントの入口です。
+
+## まずこれを読もうリスト
+
+- [戦略](./strategy/index.md) - ビジネス構造やプロジェクトの方向性を整理します。
+- [要件](./requirements/index.md) - RDRA 2.0 ベースで要件を定義します。
+- [設計](./design/index.md) - アーキテクチャ、モデル、品質方針を整理します。
+- [開発](./development/index.md) - リリース計画とイテレーション管理の入口です。
+- [運用](./operation/index.md) - 環境構築、デプロイ、運用関連の入口です。
+- [記事](./article/index.md) - 学習用の記事シリーズの入口です。
+
+## ドキュメント構成
+
+| カテゴリ | 概要                                  | 状況 |
+| :--- |:------------------------------------| :--- |
+| [戦略](./strategy/index.md) | 企業分析、経営戦略、ビジネスアーキテクチャ、インセプションデッキの整理 | `index.md` を整備済み |
+| [要件](./requirements/index.md) | RDRA 2.0 とユースケース整理の入口               | `index.md` を整備済み |
+| [設計](./design/index.md) | アーキテクチャ、モデル、テスト、非機能の整理              | `index.md` を整備済み |
+| [開発](./development/index.md) | リリース計画、イテレーション計画、進捗管理               | `index.md` を整備済み |
+| [運用](./operation/index.md) | 環境構築、デプロイ、運用手順の整理                   | `index.md` を整備済み |
+| [レビュー](./review/index.md) | 分析・開発レビュー結果の記録                      | `index.md` を整備済み |
+| [ADR](./adr/index.md) | Architecture Decision Records の管理   | `index.md` を整備済み |
+| [記事](./article/index.md) | 学習用の記事シリーズ一覧                        | 公開サイトへのリンク集 |
+| [リファレンス](./reference/index.md) | 開発ガイドラインやベストプラクティス                  | 39 件のドキュメントを配置 |
+| [テンプレート](./template/index.md) | 各種ドキュメントの作成テンプレート                   | 18 件のテンプレートを配置 |
+
+## 補足
+
+- `strategy/`、`requirements/`、`design/`、`development/`、`operation/` は現時点ではカテゴリ索引が中心です。
+- `journal/` は作業ログ用の予約ディレクトリです。
+- `assets/` は MkDocs 用のスタイル・スクリプトを格納しています。

package/lib/assets/docs/log.md

@@ -1,25 +1,28 @@
-# Docs Update Log
-
-## 2026-09-12
-* **Verification**: [AI-DLC用語集](/reference/AI-DLC用語集.md) を human:kakimomokuri が検証
-* **Verification**: [コーディングとテストガイド_AI-DLC版](/reference/コーディングとテストガイド_AI-DLC版.md) を human:kakimomokuri が検証
-* **Verification**: [ユースケース作成ガイド_AI-DLC版](/reference/ユースケース作成ガイド_AI-DLC版.md) を human:kakimomokuri が検証
-* **Verification**: [リリース・イテレーション計画ガイド_AI-DLC版](/reference/リリース・イテレーション計画ガイド_AI-DLC版.md) を human:kakimomokuri が検証
-* **Verification**: [開発ガイド_AI-DLC版](/reference/開発ガイド_AI-DLC版.md) を human:kakimomokuri が検証
-* **Verification**: [AI-DLC導入ガイド](/reference/AI-DLC導入ガイド.md) を human:kakimomokuri が検証
-* **Creation**: [AI-DLC 用語集](/reference/AI-DLC用語集.md) を新規作成。論文・参照実装・本プロジェクトの AI-DLC 版ガイドの用語を 6 区分で定義し、XP・Scrum との対応表と参照先を追加。`CLAUDE.md` の参照表にも登録。
-* **Creation**: [開発ガイド（AI-DLC 版）](/reference/開発ガイド_AI-DLC版.md) を新規作成。XP 版の開発ライフサイクル（分析・開発・運用・構築・配置）を AI-DLC の 3 フェーズで読み替え、各活動で AI が生成し人が検証するものを定義。AI-DLC 版ガイド 4 本と XP 版ガイドの対応表を追加。あわせて `CLAUDE.md` に AI-DLC を採用する旨と守るべき 6 原則を明記し、ペルソナの参照先を開発ガイド（AI-DLC 版）に変更。
-* **Creation**: [コーディングとテストガイド（AI-DLC 版）](/reference/コーディングとテストガイド_AI-DLC版.md) を新規作成。XP 版の章構成を保ちながら、TDD の三原則を AI に守らせる Bolt 開発フロー、承認ゲートの密度選択、AI 向けのアプローチ指示、ステップ計画、Red/Green/Refactor 各フェーズの人の検証観点、AI 生成コード固有の品質観点、ソース束縛レビュー、テスト戦略の水準、ガードレール化、quick-cement としての技術的負債、開発スキルの読み替え表を定義。
-* **Creation**: [ユースケース作成ガイド（AI-DLC 版）](/reference/ユースケース作成ガイド_AI-DLC版.md) を新規作成。XP 版の章構成を保ちながら、Mob Elaboration によるユースケース作成手順、12 ステップの AI と人の分担、トレーサビリティ項目を加えたテンプレート、セマンティクス密度、AI 生成ユースケースの検証観点、ブラウンフィールドのリバースエンジニアリング、プロンプトパターン、分析スキルの読み替え表を定義。
-* **Creation**: [リリース・イテレーション計画ガイド（AI-DLC 版）](/reference/リリース・イテレーション計画ガイド_AI-DLC版.md) を新規作成。XP 版の章構成を保ちながら、Intent → Unit → Bolt の計画階層、承認駆動の Bolt 計画、エントロピー評価による見積もり、完了 Unit 数・ゲート通過数・リードタイムによる進捗管理、リスク台帳、Bolt 終了報告テンプレート、計画スキルの読み替え表を定義。
-* **Update**: [AI-DLC 導入ガイド](/reference/AI-DLC導入ガイド.md) を一次情報（Method Definition Paper・aidlc-workflows ユーザーガイド）で精査し拡充。10 の基本原則、成果物定義（Intent・Unit・Bolt・Domain/Logical Design・Deployment Unit）、Inception の 6 成果物、グリーンフィールド／ブラウンフィールド実践例、付録 A のプロンプトパターン、参照実装の 5 フェーズ 33 ステージ・スコープ・エージェント・承認ゲート・監査ログ、33 ステージと Skills の対応表を追加。
-* **Creation**: [AI-DLC 導入ガイド](/reference/AI-DLC導入ガイド.md) を新規作成。AI-DLC の概要・コア原則・3 フェーズ・ベストプラクティスを整理し、XP と Skills 体系への対応表と段階的な導入ステップを定義。
-
-## 2026-08-26
-* **Verification**: [ドキュメント構成ガイド](/reference/ドキュメント構成ガイド.md) を human:kakimomokuri が検証
-* **Update**: ドキュメント構成ガイドを更新。docs/review を共通からプロジェクト別カテゴリに変更（プロジェクト別は 7 カテゴリに）。
-* **Creation**: ドキュメント構成ガイドを新規作成。単一企業・統合戦略・複数プロジェクトのコンセプトと apps/ との対応規約を定義。
-
-## 2026-08-25
-* **Update**: リンク切れ 53 件を修正。`grokking-concurrency` のサンプルコード参照をインラインコード表記に統一、`functional-desgin-ppp/elixir` の目次 6〜10 章を実際の章構成に合わせて書き直し、[Codex CLI MCP アプリケーション開発フロー](/reference/CodexCLIMCPアプリケーション開発フロー.md) の関連ドキュメントを実在ガイドに付け替え、未執筆の付録は「未作成」と明記。`template/まずこれを読もうリスト.md` の 10 件はコピー先基準のパスのため据え置き。
-* **Migration**: `docs/` を OKF v0.2 の知識バンドルに移行。601 件のコンセプト（Article 552 件・Reference 31 件・Template 18 件）に `type`・`title`・`description`・`tags`・`generated` を付与し、ルート `index.md` に `okf_version: "0.2"` を宣言。本文は変更していない。Wiki.js 由来のフロントマターは OKF 形式に併合した。
+# Docs Update Log
+
+## 2026-09-26
+* **Creation**: [BDD導入ガイド](/reference/BDD導入ガイド.md) を作成（claude-code/claude-opus-5）
+
+## 2026-09-12
+* **Verification**: [AI-DLC用語集](/reference/AI-DLC用語集.md) を human:kakimomokuri が検証
+* **Verification**: [コーディングとテストガイド_AI-DLC版](/reference/コーディングとテストガイド_AI-DLC版.md) を human:kakimomokuri が検証
+* **Verification**: [ユースケース作成ガイド_AI-DLC版](/reference/ユースケース作成ガイド_AI-DLC版.md) を human:kakimomokuri が検証
+* **Verification**: [リリース・イテレーション計画ガイド_AI-DLC版](/reference/リリース・イテレーション計画ガイド_AI-DLC版.md) を human:kakimomokuri が検証
+* **Verification**: [開発ガイド_AI-DLC版](/reference/開発ガイド_AI-DLC版.md) を human:kakimomokuri が検証
+* **Verification**: [AI-DLC導入ガイド](/reference/AI-DLC導入ガイド.md) を human:kakimomokuri が検証
+* **Creation**: [AI-DLC 用語集](/reference/AI-DLC用語集.md) を新規作成。論文・参照実装・本プロジェクトの AI-DLC 版ガイドの用語を 6 区分で定義し、XP・Scrum との対応表と参照先を追加。`CLAUDE.md` の参照表にも登録。
+* **Creation**: [開発ガイド（AI-DLC 版）](/reference/開発ガイド_AI-DLC版.md) を新規作成。XP 版の開発ライフサイクル（分析・開発・運用・構築・配置）を AI-DLC の 3 フェーズで読み替え、各活動で AI が生成し人が検証するものを定義。AI-DLC 版ガイド 4 本と XP 版ガイドの対応表を追加。あわせて `CLAUDE.md` に AI-DLC を採用する旨と守るべき 6 原則を明記し、ペルソナの参照先を開発ガイド（AI-DLC 版）に変更。
+* **Creation**: [コーディングとテストガイド（AI-DLC 版）](/reference/コーディングとテストガイド_AI-DLC版.md) を新規作成。XP 版の章構成を保ちながら、TDD の三原則を AI に守らせる Bolt 開発フロー、承認ゲートの密度選択、AI 向けのアプローチ指示、ステップ計画、Red/Green/Refactor 各フェーズの人の検証観点、AI 生成コード固有の品質観点、ソース束縛レビュー、テスト戦略の水準、ガードレール化、quick-cement としての技術的負債、開発スキルの読み替え表を定義。
+* **Creation**: [ユースケース作成ガイド（AI-DLC 版）](/reference/ユースケース作成ガイド_AI-DLC版.md) を新規作成。XP 版の章構成を保ちながら、Mob Elaboration によるユースケース作成手順、12 ステップの AI と人の分担、トレーサビリティ項目を加えたテンプレート、セマンティクス密度、AI 生成ユースケースの検証観点、ブラウンフィールドのリバースエンジニアリング、プロンプトパターン、分析スキルの読み替え表を定義。
+* **Creation**: [リリース・イテレーション計画ガイド（AI-DLC 版）](/reference/リリース・イテレーション計画ガイド_AI-DLC版.md) を新規作成。XP 版の章構成を保ちながら、Intent → Unit → Bolt の計画階層、承認駆動の Bolt 計画、エントロピー評価による見積もり、完了 Unit 数・ゲート通過数・リードタイムによる進捗管理、リスク台帳、Bolt 終了報告テンプレート、計画スキルの読み替え表を定義。
+* **Update**: [AI-DLC 導入ガイド](/reference/AI-DLC導入ガイド.md) を一次情報（Method Definition Paper・aidlc-workflows ユーザーガイド）で精査し拡充。10 の基本原則、成果物定義（Intent・Unit・Bolt・Domain/Logical Design・Deployment Unit）、Inception の 6 成果物、グリーンフィールド／ブラウンフィールド実践例、付録 A のプロンプトパターン、参照実装の 5 フェーズ 33 ステージ・スコープ・エージェント・承認ゲート・監査ログ、33 ステージと Skills の対応表を追加。
+* **Creation**: [AI-DLC 導入ガイド](/reference/AI-DLC導入ガイド.md) を新規作成。AI-DLC の概要・コア原則・3 フェーズ・ベストプラクティスを整理し、XP と Skills 体系への対応表と段階的な導入ステップを定義。
+
+## 2026-08-26
+* **Verification**: [ドキュメント構成ガイド](/reference/ドキュメント構成ガイド.md) を human:kakimomokuri が検証
+* **Update**: ドキュメント構成ガイドを更新。docs/review を共通からプロジェクト別カテゴリに変更（プロジェクト別は 7 カテゴリに）。
+* **Creation**: ドキュメント構成ガイドを新規作成。単一企業・統合戦略・複数プロジェクトのコンセプトと apps/ との対応規約を定義。
+
+## 2026-08-25
+* **Update**: リンク切れ 53 件を修正。`grokking-concurrency` のサンプルコード参照をインラインコード表記に統一、`functional-desgin-ppp/elixir` の目次 6〜10 章を実際の章構成に合わせて書き直し、[Codex CLI MCP アプリケーション開発フロー](/reference/CodexCLIMCPアプリケーション開発フロー.md) の関連ドキュメントを実在ガイドに付け替え、未執筆の付録は「未作成」と明記。`template/まずこれを読もうリスト.md` の 10 件はコピー先基準のパスのため据え置き。
+* **Migration**: `docs/` を OKF v0.2 の知識バンドルに移行。601 件のコンセプト（Article 552 件・Reference 31 件・Template 18 件）に `type`・`title`・`description`・`tags`・`generated` を付与し、ルート `index.md` に `okf_version: "0.2"` を宣言。本文は変更していない。Wiki.js 由来のフロントマターは OKF 形式に併合した。