@k2works/claude-code-booster 5.0.0 → 6.0.0

package/lib/assets/.claude/skills/apply-docs-structure/SKILL.md

@@ -0,0 +1,88 @@
+---
+name: apply-docs-structure
+description: ドキュメント構成ガイド（単一企業・統合戦略・複数プロジェクト）に従って docs/ と apps/ の配置を適用する日常運用スキル。文書をどのディレクトリに置くか判断する、新しいプロジェクトのディレクトリ一式（apps/<project>/ とプロジェクト別 7 カテゴリの <project>/index.md）を作る、既存構成がガイドに適合しているか検証する、といった操作を行う。「この設計書はどこに置く？」「新しいプロジェクトを始めるのでディレクトリを用意して」「docs の構成が正しいか確認して」「ドキュメントをプロジェクト別に整理して」「apps とドキュメントの対応を確認して」といった場面で発動する。analyzing-*・planning-releases・creating-adr・creating-journal・operating-setup などが docs/ 配下に文書を新規作成する直前には、明示的な依頼が無くても配置先の判断に積極的に使うこと。フロントマター・index/log の OKF 規約は apply-okf、既存文書の一括移行は migrating-okf の担当。
+---
+
+# ドキュメント構成適用
+
+`docs/` と `apps/` の配置規約を**日常の変更**に適用する。規約の正は `docs/reference/ドキュメント構成ガイド.md`。本スキルは「文書を 1 つ置く／プロジェクトを 1 つ増やす／構成を確かめる」たびに呼ぶ判断と仕上げの工程。同じディレクトリに `PROJECT.md` があれば必ず読む（バンドルの場所・プロジェクト一覧・カテゴリの追加定義はそこにある）。
+
+## なぜ毎回適用するのか
+
+構成の価値は「プロジェクト識別子で docs と apps を双方向に辿れる」ことにある。1 つでもカテゴリ直下に実ドキュメントが直置きされたり、docs と apps で識別子がずれたりすると、トレーサビリティが壊れ、後から誰も直せない「なんとなくの配置」が増殖する。規約は移行時に一度守れば済むものではなく、置くたびに守って初めて意味を持つ。
+
+## 構成の要点
+
+| 区分 | ディレクトリ | 規約 |
+| :--- | :--- | :--- |
+| 単一（企業共通） | `strategy/` | 統合戦略。プロジェクト別サブディレクトリを**作らない** |
+| 単一（共有リソース） | `reference/` `template/` `article/` `assets/` | プロジェクト別サブディレクトリを作らない |
+| プロジェクト別 | `requirements/` `design/` `development/` `operation/` `adr/` `journal/` `review/` | `<category>/<project>/` に置く。カテゴリ直下は索引 `index.md` のみ |
+| アプリケーション | `apps/<project>/` | docs 側と**同一のケバブケース識別子** |
+
+## 3 つの操作
+
+| 操作 | いつ | 何をするか |
+| :--- | :--- | :--- |
+| **place** | 文書を新規作成する直前 | 配置判断フローで置き場所を決める。プロジェクト別カテゴリなら `<category>/<project>/` 配下に置き、プロジェクトの `index.md` にエントリを追加 |
+| **add-project** | 新しいプロジェクトを始める | `apps/<project>/` とプロジェクト別 7 カテゴリの `<project>/index.md` を一括作成し、各カテゴリ索引に登録 |
+| **check** | 上記の後、コミット前 | 構成がガイドに適合しているか検証し ERROR 0 を確認 |
+
+add-project と check は同梱スクリプトで行う。手で 7 カテゴリを掘らない（作成漏れ・識別子の揺れ・索引の登録漏れを起こしやすい）。
+
+```bash
+S=.claude/skills/apply-docs-structure/scripts/docs_structure.py
+python $S add-project inventory-service                # docs/ と apps/ に一式作成
+python $S add-project sales-portal --skip apps         # apps を別管理している場合
+python $S check                                        # 検証（ERROR/WARN を列挙）
+python $S check --check                                # ERROR があれば exit 1（CI・コミット前）
+```
+
+## 判断すべきこと（スクリプトは判断しない）
+
+### place：文書をどこに置くか
+
+1. **戦略文書か？**（企業分析・経営戦略・ビジネスアーキテクチャ・インセプションデッキ）→ `docs/strategy/` 直下。プロジェクト名でサブディレクトリを掘りたくなったら、それは戦略ではなくプロジェクトの要件か ADR。プロジェクト別カテゴリ側に置く
+2. **特定プロジェクトの成果物か？** → 該当カテゴリの `<category>/<project>/` に置く。プロジェクトのディレクトリがまだ無ければ先に add-project
+3. **どのプロジェクトにも属さない共有知識か？**（ガイドライン・テンプレート・記事）→ `reference/` `template/` `article/`
+4. どれにも当てはまらない・複数プロジェクトにまたがる → 安易に新カテゴリを作らず、ガイドの更新が必要かをユーザーに確認する
+
+### add-project：識別子
+
+英小文字とハイフンのケバブケース（例：`inventory-service`）。docs と apps で完全一致させ、一度決めたら変更しない。ユーザーの呼び名が日本語・大文字混じりなら、識別子への変換案を提示して合意してから作成する。
+
+### check の結果への対応
+
+- **ERROR**（識別子が規約違反、docs と apps の不一致）→ その場で直す。放置してコミットしない
+- **WARN**（カテゴリ直下への直置き、`index.md` 欠落、apps 側に対応ディレクトリ無し）→ 移行途中の状態でも出る。直せるものは直し、意図的な据え置きは理由をユーザーに報告する
+
+## 他スキルとの連携
+
+`docs/` に文書を書くスキルの**最初**に本スキル（place）、**最後**に `apply-okf` を組み込む。典型的な流れ：
+
+1. `analyzing-data-model` が inventory-service のデータモデル設計書を書こうとする
+2. place 判断 → `docs/design/inventory-service/データモデル設計書.md` に決定（ディレクトリが無ければ `add-project inventory-service`）
+3. 文書を作成し、`docs/design/inventory-service/index.md` にエントリを追加
+4. `apply-okf` でフロントマター付与・`log.md` 記録
+5. `python $S check --check` と `gulp okf:check` で ERROR 0 を確認してコミット
+
+構成（どこに置くか）は本スキル、来歴・信頼（フロントマター・verified・log）は `apply-okf`。両者は重ならない。
+
+## 完了報告
+
+```markdown
+## ドキュメント構成適用結果
+
+- 操作: place / add-project / check
+- 対象: <プロジェクト識別子・配置したファイル>
+- 作成・更新: <ディレクトリ・index.md の一覧>
+- 検証: ERROR 0 / WARN <N>
+- 要確認: <識別子の変換案、意図的に据え置いた WARN、など>
+```
+
+## 関連スキル
+
+- `apply-okf` — フロントマター・index/log・適合性検証。文書を置いた直後に呼ぶ
+- `migrating-okf` — 既存文書の一括移行
+- `analyzing-*` / `planning-releases` / `creating-adr` / `creating-journal` — 文書を生む側。書く直前に本スキルで配置を判断する
+- `git-commit` — 検証後のコミット

package/lib/assets/.claude/skills/apply-docs-structure/evals/evals.json

@@ -0,0 +1,40 @@
+{
+  "skill_name": "apply-docs-structure",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "新しいプロジェクト inventory-service を始める。ドキュメント構成ガイドに沿って docs/ と apps/ のディレクトリ一式を用意して。",
+      "expected_output": "apps/inventory-service/ とプロジェクト別 7 カテゴリ（requirements/design/development/operation/adr/journal/review）の inventory-service/index.md が作成され、各カテゴリ索引に登録、check で ERROR 0",
+      "assertions": [
+        "apps/inventory-service/ ディレクトリが作成されている",
+        "プロジェクト別 7 カテゴリすべてに inventory-service/index.md が存在する",
+        "各カテゴリの index.md に inventory-service へのリンクが登録されている",
+        "strategy/ にプロジェクト別サブディレクトリが作られていない"
+      ],
+      "files": []
+    },
+    {
+      "id": 2,
+      "prompt": "inventory-service のデータモデル設計書を書きたい。どこに置くべきか判断して配置して。",
+      "expected_output": "docs/design/inventory-service/ 配下に配置(docs/design/ 直下ではない)、プロジェクトの index.md にエントリ追加",
+      "assertions": [
+        "設計書が docs/design/inventory-service/ 配下に配置されている",
+        "docs/design/ 直下に index.md 以外の .md が置かれていない",
+        "docs/design/inventory-service/index.md に設計書のエントリがある"
+      ],
+      "files": []
+    },
+    {
+      "id": 3,
+      "prompt": "docs/ の構成がドキュメント構成ガイドに適合しているか確認して。直せる違反があれば直して。",
+      "expected_output": "check スクリプトで検証し ERROR/WARN を報告、カテゴリ直下への直置きや識別子違反を修正、意図的な据え置きは理由を報告",
+      "assertions": [
+        "プロジェクト別カテゴリ配下に非ケバブケースのディレクトリが残っていない",
+        "カテゴリ直下に index.md 以外の .md が残っていない",
+        "移動・改名されたファイルの本文が失われていない",
+        "docs 側にディレクトリが無い apps プロジェクトへの言及がある"
+      ],
+      "files": []
+    }
+  ]
+}

package/lib/assets/.claude/skills/apply-docs-structure/scripts/docs_structure.py

@@ -0,0 +1,207 @@
+#!/usr/bin/env python3
+"""ドキュメント構成ガイド（単一企業・統合戦略・複数プロジェクト）の適用スクリプト。
+
+サブコマンド:
+  add-project <project>  apps/<project>/ とプロジェクト別カテゴリの <project>/index.md を一括作成
+  check                  docs/ と apps/ の構成がガイドに適合しているか検証
+
+規約の正: docs/reference/ドキュメント構成ガイド.md
+"""
+import argparse
+import re
+import sys
+from pathlib import Path
+
+if hasattr(sys.stdout, "reconfigure"):
+    sys.stdout.reconfigure(encoding="utf-8")
+
+PER_PROJECT_CATEGORIES = {
+    "requirements": "要件",
+    "design": "設計",
+    "development": "開発",
+    "operation": "運用",
+    "adr": "ADR",
+    "journal": "ジャーナル",
+    "review": "レビュー",
+}
+SINGLE_CATEGORIES = ["strategy", "reference", "template", "article", "assets"]
+PROJECT_ID_RE = re.compile(r"^[a-z0-9]+(-[a-z0-9]+)*$")
+
+PROJECT_INDEX_TEMPLATE = """# {project} — {label}
+
+{project} プロジェクトの{label}ドキュメントです。
+
+## ドキュメント一覧
+
+（未作成）
+
+## 補足
+
+- 実ドキュメントを追加したら、この一覧を更新します。
+"""
+
+
+def project_dirs(category_dir: Path):
+    """カテゴリ直下のサブディレクトリ（= プロジェクトディレクトリ扱い）を返す。"""
+    if not category_dir.is_dir():
+        return []
+    return sorted(p for p in category_dir.iterdir() if p.is_dir())
+
+
+def cmd_add_project(args) -> int:
+    docs = Path(args.docs)
+    apps = Path(args.apps)
+    project = args.project
+
+    if not PROJECT_ID_RE.match(project):
+        print(f"ERROR: プロジェクト識別子 '{project}' がケバブケース（英小文字とハイフン）ではない")
+        return 1
+    if not docs.is_dir():
+        print(f"ERROR: docs ディレクトリが見つからない: {docs}")
+        return 1
+
+    created, skipped = [], []
+
+    if "apps" not in args.skip:
+        app_dir = apps / project
+        if app_dir.exists():
+            skipped.append(str(app_dir))
+        else:
+            app_dir.mkdir(parents=True)
+            (app_dir / ".gitkeep").write_text("", encoding="utf-8")
+            created.append(str(app_dir))
+
+    for category, label in PER_PROJECT_CATEGORIES.items():
+        if category in args.skip:
+            continue
+        cat_dir = docs / category
+        proj_dir = cat_dir / project
+        proj_index = proj_dir / "index.md"
+        if proj_index.exists():
+            skipped.append(str(proj_index))
+        else:
+            proj_dir.mkdir(parents=True, exist_ok=True)
+            proj_index.write_text(
+                PROJECT_INDEX_TEMPLATE.format(project=project, label=label),
+                encoding="utf-8",
+            )
+            created.append(str(proj_index))
+
+        # カテゴリ索引にエントリを追加（末尾追記。セクション位置の調整は呼び出し側で行う）
+        cat_index = cat_dir / "index.md"
+        entry = f"- [{project}](./{project}/index.md)"
+        if cat_index.exists():
+            body = cat_index.read_text(encoding="utf-8")
+            if entry not in body:
+                if not body.endswith("\n"):
+                    body += "\n"
+                cat_index.write_text(body + entry + "\n", encoding="utf-8")
+                created.append(f"{cat_index}（エントリ追加）")
+        else:
+            cat_index.write_text(
+                f"# {label}\n\n## プロジェクト一覧\n\n{entry}\n", encoding="utf-8"
+            )
+            created.append(str(cat_index))
+
+    for path in created:
+        print(f"作成: {path}")
+    for path in skipped:
+        print(f"既存のためスキップ: {path}")
+    print("次: 各カテゴリ index.md のエントリ位置を確認し、check で検証する")
+    return 0
+
+
+def cmd_check(args) -> int:
+    docs = Path(args.docs)
+    apps = Path(args.apps)
+    errors, warns = [], []
+
+    if not docs.is_dir():
+        print(f"ERROR: docs ディレクトリが見つからない: {docs}")
+        return 1
+
+    apps_projects = (
+        {p.name for p in apps.iterdir() if p.is_dir()} if apps.is_dir() else None
+    )
+    docs_projects = set()
+
+    for category in PER_PROJECT_CATEGORIES:
+        cat_dir = docs / category
+        if not cat_dir.is_dir():
+            continue
+        # カテゴリ直下は索引 index.md のみ。実ドキュメントの直置きは規約違反
+        for f in sorted(cat_dir.glob("*.md")):
+            if f.name != "index.md":
+                warns.append(
+                    f"{category}/{f.name}: カテゴリ直下に直置き（{category}/<project>/ 配下に置く）"
+                )
+        for proj_dir in project_dirs(cat_dir):
+            name = proj_dir.name
+            docs_projects.add(name)
+            if not PROJECT_ID_RE.match(name):
+                errors.append(
+                    f"{category}/{name}/: 識別子がケバブケース（英小文字とハイフン）ではない"
+                )
+            if not (proj_dir / "index.md").exists():
+                warns.append(f"{category}/{name}/: index.md が無い")
+            if apps_projects is not None and name not in apps_projects:
+                warns.append(f"{category}/{name}/: 対応する apps/{name}/ が無い")
+
+    # strategy は単一管理。プロジェクト名のサブディレクトリは分割の兆候
+    strategy = docs / "strategy"
+    if strategy.is_dir():
+        for sub in project_dirs(strategy):
+            if sub.name in docs_projects or (
+                apps_projects is not None and sub.name in apps_projects
+            ):
+                warns.append(
+                    f"strategy/{sub.name}/: strategy は統合戦略として単一管理（プロジェクト別に分割しない）"
+                )
+
+    # apps 側にだけ存在するプロジェクト
+    if apps_projects:
+        for name in sorted(apps_projects - docs_projects):
+            warns.append(
+                f"apps/{name}/: docs 側にプロジェクトディレクトリが無い（add-project で作成する）"
+            )
+
+    for msg in errors:
+        print(f"ERROR {msg}")
+    for msg in warns:
+        print(f"WARN  {msg}")
+    print(f"\nERROR {len(errors)} / WARN {len(warns)}")
+    if args.check and errors:
+        return 1
+    return 0
+
+
+def main() -> int:
+    parser = argparse.ArgumentParser(description=__doc__)
+    sub = parser.add_subparsers(dest="command", required=True)
+
+    p_add = sub.add_parser("add-project", help="新プロジェクトのディレクトリ一式を作成")
+    p_add.add_argument("project", help="プロジェクト識別子（ケバブケース）")
+    p_add.add_argument("--docs", default="docs", help="docs ディレクトリ（既定: docs）")
+    p_add.add_argument("--apps", default="apps", help="apps ディレクトリ（既定: apps）")
+    p_add.add_argument(
+        "--skip",
+        nargs="*",
+        default=[],
+        help="スキップする対象（apps または カテゴリ名）",
+    )
+    p_add.set_defaults(func=cmd_add_project)
+
+    p_check = sub.add_parser("check", help="構成の適合性を検証")
+    p_check.add_argument("--docs", default="docs", help="docs ディレクトリ（既定: docs）")
+    p_check.add_argument("--apps", default="apps", help="apps ディレクトリ（既定: apps）")
+    p_check.add_argument(
+        "--check", action="store_true", help="ERROR があれば exit 1 で終了"
+    )
+    p_check.set_defaults(func=cmd_check)
+
+    args = parser.parse_args()
+    return args.func(args)
+
+
+if __name__ == "__main__":
+    sys.exit(main())

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

@@ -60,8 +60,11 @@ description: 分析フェーズ全体のワークフローをオーケストレ
 |------|--------|--------|
 | 技術スタック選定 | `analyzing-tech-stack` | 技術選定・評価結果 |
 | ADR 作成 | `creating-adr` | Architecture Decision Record |
+| 構成適用 | `apply-docs-structure` | 各工程の成果物の配置先判断（戦略は `strategy/` 単一、要件以降はプロジェクト別 `<category>/<project>/`） |
 | OKF 適用 | `apply-okf` | 各工程の成果物へのフロントマター付与・`index.md`/`log.md` 更新 |
 
+`docs/` がドキュメント構成ガイド（単一企業・統合戦略・複数プロジェクト）を採用しているなら、各工程で成果物を書く**直前**に `apply-docs-structure` で配置先を判断する。戦略工程（企業分析・経営戦略・ビジネスアーキテクチャ・インセプションデッキ）の成果物は `docs/strategy/` に単一管理、要件定義以降の成果物はプロジェクト別カテゴリの `<category>/<project>/` 配下に置く。配置を書いた後に直すと索引・リンク・OKF の来歴すべての修正が必要になるため、判断は必ず書く前に行う。
+
 `docs/` が OKF 知識バンドル（ルート `index.md` に `okf_version` がある）なら、各工程で設計ドキュメントを作成・更新するたびに `apply-okf` を実行する。分析の成果物はエージェントが書き、人がレビューして確定する流れなので、作成時は `status: draft`、レビュー後に `verify --by human:<id>` で `stable` に昇格させる。工程ごとにこれを行えば、分析フェーズの終わりには「どの文書が誰に確認済みか」がフロントマターから読める状態になる。
 
 ## 進め方
@@ -103,5 +106,5 @@ description: 分析フェーズ全体のワークフローをオーケストレ
 ## 注意事項
 
 - 分析結果は開発フェーズで継続的に見直す。完璧を目指して分析を長引かせるより、十分な品質で開発に進み、フィードバックで改善する方が効果的
-- 各工程の成果物は `docs/` 配下に Markdown + PlantUML で文書化する。OKF バンドルなら作成・更新のたびに `apply-okf` で規約を適用し、`gulp okf:check` が ERROR 0 の状態でコミットする
+- 各工程の成果物は `docs/` 配下に Markdown + PlantUML で文書化する。配置先は書く前に `apply-docs-structure` で判断し、OKF バンドルなら作成・更新のたびに `apply-okf` で規約を適用し、`gulp okf:check` が ERROR 0 の状態でコミットする
 - リリース計画（`planning-releases`）は分析フェーズの最後に、技術スタック選定後に実施する

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

@@ -30,6 +30,7 @@ description: 開発フェーズ全体の TDD ワークフローをオーケス
 | TODO 完了時（コードレビュー） | `developing-review` | TDD サイクルで TODO を完了するたびにコード品質・テスト品質・設計整合性をレビュー |
 | 受け入れ前（品質チェック） | `operating-qt` | SonarQube によるコード品質分析・Quality Gate 確認を実施し、品質基準を満たしていることを検証 |
 | イテレーション完了時（ユーザーレビュー） | `analyzing-review` | 受け入れフェーズでユーザー視点・プロダクト視点からの成果物レビュー |
+| 設計ドキュメント新規作成の直前 | `apply-docs-structure` | 開発中に設計ドキュメント・ADR を新規に書く前に配置先（プロジェクト別カテゴリの `<project>/` 配下）を判断する。配置を誤ると docs と apps のトレーサビリティが壊れ、後からの移動は索引・リンク・来歴すべての修正になる |
 | 設計ドキュメント更新時 | `apply-okf` | 開発中に `docs/design/` や ADR を更新したら OKF フロントマター（`generated`）と `log.md` を追従させる。実装で設計が変わったのに文書の来歴が古いままだと、次のイテレーションで古い設計を信頼してしまう |
 
 ## TDD サイクル
@@ -167,4 +168,5 @@ codex:codex-rescue に以下を委譲:
 - `analyzing-review` — 分析成果物のマルチパースペクティブレビュー（イテレーション完了時のユーザーレビュー）
 - `operating-qt` — コード品質管理（受け入れ前の SonarQube 品質チェック）
 - `developing-release` — リリースワークフロー（品質ゲート・バージョン管理・CHANGELOG）
+- `apply-docs-structure` — 設計ドキュメント・ADR を新規に書く直前の配置先判断（プロジェクト別カテゴリ）
 - `apply-okf` — 開発中に更新した設計ドキュメント・ADR への OKF 規約適用

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

@@ -110,7 +110,7 @@ IaC（Infrastructure as Code）によるインフラ管理を行います。
 
 1. **現状確認**: 既存の環境・インフラ・ドキュメントを確認
 2. **環境計画**: 必要な環境と構築順序を決定
-3. **手順書作成**: テンプレートを基に環境ごとの手順書を作成
+3. **手順書作成**: テンプレートを基に環境ごとの手順書を作成。書く前に `apply-docs-structure` で配置先を判断する（プロジェクト別構成なら `docs/operation/<project>/` 配下。Skill: `apply-docs-structure`）
 4. **環境構築**: 手順書に従い段階的に環境を構築（Skill: `managing-operations`）
 5. **CI/CD 構築**: パイプラインの設計と実装
 6. **運用スクリプト**: タスクランナー・自動化スクリプトの作成
@@ -157,4 +157,5 @@ IaC（Infrastructure as Code）によるインフラ管理を行います。
 - `operating-deploy` : デプロイ・ロールバック
 - `operating-backup` : バックアップ・リストア
 - `analyzing-operation` : 運用要件の定義
+- `apply-docs-structure` : 手順書の配置先判断（プロジェクト別 `docs/operation/<project>/`）
 - `apply-okf` : 手順書への OKF 規約適用（`stale_after`・`deprecate`）

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

@@ -73,7 +73,8 @@ graph TD
 3. `planning-releases --report` で完了報告書を作成する
 4. `syncing-github-project --sync` で GitHub に最終同期する
 5. `operating-docs --update` で `docs/index.md` と `mkdocs.yml` を同期する
-6. `apply-okf` で、このイテレーションで作成・更新した計画・報告書・設計ドキュメントに OKF 規約を適用する（`apply docs --changed --by <agent>`）。イテレーション計画は完了したら `verify` ではなく実績を記した報告書が後継になるので、計画側は `stable` のまま残し、報告書を新規登録する
+6. `apply-docs-structure` の check で、作成した計画・報告書がプロジェクト別カテゴリ（`docs/development/<project>/` など）に正しく配置されているか検証する
+7. `apply-okf` で、このイテレーションで作成・更新した計画・報告書・設計ドキュメントに OKF 規約を適用する（`apply docs --changed --by <agent>`）。イテレーション計画は完了したら `verify` ではなく実績を記した報告書が後継になるので、計画側は `stable` のまま残し、報告書を新規登録する
 
 ## GitHub 同期フロー（--sync）
 
@@ -81,7 +82,7 @@ graph TD
 
 1. `syncing-github-project` で GitHub Issue / Milestone / Label を同期する
 2. `operating-docs --update` で `docs/index.md`、`mkdocs.yml`、各ディレクトリの `index.md` を現在のドキュメント構成に同期する
-3. `docs/` が OKF バンドルなら `apply-okf` で変更分に規約を適用し、`gulp okf:check` で ERROR 0 を確認する
+3. `docs/` が OKF バンドルなら `apply-okf` で変更分に規約を適用し、`apply-docs-structure` の check と `gulp okf:check` で ERROR 0 を確認する
 4. 変更があればコミットする
 
 ## 途中から再開
@@ -142,6 +143,7 @@ GitHub Project
 - `syncing-github-project` — GitHub Project への同期と一元管理
 - `tracking-progress` — 進捗分析・レポート生成
 - `operating-docs` — ドキュメントインデックス更新・Lint（`--sync` 時に自動実行）
+- `apply-docs-structure` — 計画・報告書の配置先判断と構成検証（イテレーション終了時・`--sync` 時）
 - `apply-okf` — 計画・報告書への OKF 規約適用（イテレーション終了時・`--sync` 時）
 - `orchestrating-analysis` — 分析フェーズのオーケストレーション
 - `orchestrating-development` — 開発フェーズのオーケストレーション

package/lib/assets/CLAUDE.md

@@ -12,10 +12,31 @@
 
 あなたは @docs/reference/ロジカルシンキング.md に従い論理的に考え、問題を分析し、解決策を構築します。
 
-あなたは @docs/reference/開発ガイド.md に従いソフトウェア開発を手段として問題解決に取り組みます。
+あなたは @docs/reference/開発ガイド_AI-DLC版.md に従いソフトウェア開発を手段として問題解決に取り組みます。
 
 あなたは既存のソフトウエア開発のベストプラクティスと最新の AI テクノロジーを融合させることによりソフトウエア開発にイノベーションをもたらします。
 
+## 開発方法論：AI-DLC を採用する
+
+本プロジェクトは **AI-DLC（AI-Driven Development Lifecycle）** を採用します。XP の規律（TDD・リファクタリング・シンプルな設計・小さなリリース）はそのまま残し、その上で「AI が実行し、人が監督する」構図で開発を進めます。原則と用語は `docs/reference/AI-DLC導入ガイド.md` を、各活動のガイドは次を参照してください。
+
+| 活動 | ガイド |
+| :--- | :--- |
+| 開発ライフサイクル全体 | `docs/reference/開発ガイド_AI-DLC版.md` |
+| 計画（リリース・Bolt） | `docs/reference/リリース・イテレーション計画ガイド_AI-DLC版.md` |
+| ユースケース・ユーザーストーリー | `docs/reference/ユースケース作成ガイド_AI-DLC版.md` |
+| コーディングとテスト | `docs/reference/コーディングとテストガイド_AI-DLC版.md` |
+| 用語集 | `docs/reference/AI-DLC用語集.md` |
+
+AI-DLC で守ること：
+
+- **AI が計画し、人が検証する** — 作業の前にチェックボックス付きの計画を書き、人の承認を得てから 1 ステップずつ実行する。重要な判断は勝手にしない。情報が足りなければ仮定で埋めずに質問する
+- **単位は Intent → Unit → Bolt** — Intent を疎結合な Unit に分解し、時間〜日単位の Bolt で実装する。最初の Bolt はウォーキングスケルトンにする
+- **承認ゲートは損失関数** — 「確認必須」の操作（新規ファイル作成・構造変更・外部連携・セキュリティ・データベース・本番環境）は承認ゲートとして必ず人の判断を仰ぐ
+- **TDD の三原則を変えない** — テストを書き、失敗を確認してから最小限を実装する。先回りして実装しない
+- **成果物は契約であり、コンテキストである** — ユーザーストーリーと受入条件は人と AI の契約。生成した成果物は `docs/` に永続化し、次のステップのコンテキストにする
+- **修正はガードレールにする** — 人に修正された振る舞いは `CLAUDE.md`・`PROJECT.md`・スキルに反映し、同じ修正を繰り返さない
+
 ## Skills 体系
 
 `.claude/skills/` に定義された Skills がタスクに応じて自動発動します。詳細な指示は各スキルの SKILL.md を参照してください。
@@ -110,6 +131,7 @@
 | `creating-iteration-report` | イテレーション完了報告書作成 |
 | `migrating-okf` | プロジェクトドキュメントの OKF 知識バンドルへの移行・仕様バージョンアップ・適合性検証 |
 | `apply-okf` | 文書の作成・更新・レビュー・廃止時に OKF 規約（フロントマター・verified・index/log）を適用 |
+| `apply-docs-structure` | ドキュメント構成ガイド（単一企業・統合戦略・複数プロジェクト）に基づく配置判断・新プロジェクトのディレクトリ一式作成・構成検証 |
 
 ### 学習
 

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) | 学習用の記事シリーズ一覧                        | `index.md` を整備済み |
-| [リファレンス](./reference/index.md) | 開発ガイドラインやベストプラクティス                  | 30 件のドキュメントを配置 |
-| [テンプレート](./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) | 学習用の記事シリーズ一覧                        | `index.md` を整備済み |
+| [リファレンス](./reference/index.md) | 開発ガイドラインやベストプラクティス                  | 38 件のドキュメントを配置 |
+| [テンプレート](./template/index.md) | 各種ドキュメントの作成テンプレート                   | 18 件のテンプレートを配置 |
+
+## 補足
+
+- `strategy/`、`requirements/`、`design/`、`development/`、`operation/` は現時点ではカテゴリ索引が中心です。
+- `journal/` は作業ログ用の予約ディレクトリです。
+- `assets/` は MkDocs 用のスタイル・スクリプトを格納しています。

package/lib/assets/docs/log.md

@@ -1,5 +1,25 @@
 # 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 形式に併合した。