@k2works/claude-code-booster 5.0.0 → 5.1.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

@@ -110,6 +110,7 @@
 | `creating-iteration-report` | イテレーション完了報告書作成 |
 | `migrating-okf` | プロジェクトドキュメントの OKF 知識バンドルへの移行・仕様バージョンアップ・適合性検証 |
 | `apply-okf` | 文書の作成・更新・レビュー・廃止時に OKF 規約（フロントマター・verified・index/log）を適用 |
+| `apply-docs-structure` | ドキュメント構成ガイド（単一企業・統合戦略・複数プロジェクト）に基づく配置判断・新プロジェクトのディレクトリ一式作成・構成検証 |
 
 ### 学習
 

package/lib/assets/docs/index.md

@@ -27,7 +27,7 @@ okf_version: "0.2"
 | [レビュー](./review/index.md) | 分析・開発レビュー結果の記録                      | `index.md` を整備済み |
 | [ADR](./adr/index.md) | Architecture Decision Records の管理   | `index.md` を整備済み |
 | [記事](./article/index.md) | 学習用の記事シリーズ一覧                        | `index.md` を整備済み |
-| [リファレンス](./reference/index.md) | 開発ガイドラインやベストプラクティス                  | 30 件のドキュメントを配置 |
+| [リファレンス](./reference/index.md) | 開発ガイドラインやベストプラクティス                  | 31 件のドキュメントを配置 |
 | [テンプレート](./template/index.md) | 各種ドキュメントの作成テンプレート                   | 18 件のテンプレートを配置 |
 
 ## 補足

package/lib/assets/docs/log.md

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

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

@@ -10,6 +10,7 @@
 - [ロジカルシンキング](./ロジカルシンキング.md)
 - [開発ガイド](./開発ガイド.md)
 - [エクストリームプログラミング](./エクストリームプログラミング.md)
+- [ドキュメント構成ガイド](./ドキュメント構成ガイド.md) - 単一企業・統合戦略・複数プロジェクトのコンセプトに基づく docs/ と apps/ の構成規約
 
 ### 経営・ビジネス
 

package/lib/assets/docs/reference//343/203/211/343/202/255/343/203/245/343/203/241/343/203/263/343/203/210/346/247/213/346/210/220/343/202/254/343/202/244/343/203/211.md

@@ -0,0 +1,143 @@
+---
+type: Reference
+title: "ドキュメント構成ガイド"
+description: "docs/ 配下のディレクトリ構成規約。単一企業・統合戦略・複数プロジェクトのコンセプトに基づき、strategy は単一、requirements/design/development/operation/adr/journal/review はプロジェクト別サブディレクトリで区切り、apps/ と同一のプロジェクト識別子で対応付ける。"
+tags: [reference]
+status: stable
+generated: { by: claude-code/claude-fable-5, at: 2026-08-26T06:00:05Z }
+verified:
+  - { by: human:kakimomokuri, at: 2026-08-26T06:13:18Z }
+---
+
+# ドキュメント構成ガイド
+
+`docs/` 配下のディレクトリ構成と、アプリケーション本体（`apps/`）との対応関係を定義します。
+
+## コンセプト：単一企業・統合戦略・複数プロジェクト
+
+本ドキュメントバンドルは、次の 3 つを前提に構成します。
+
+1. **単一企業** — ドキュメントの主体となる企業（事業主体）は 1 つです。
+2. **統合戦略** — 企業分析・経営戦略・ビジネスアーキテクチャは企業全体で 1 つに統合し、プロジェクトごとに分割しません。すべてのプロジェクトは同じ戦略を参照します。
+3. **複数プロジェクト** — 統合戦略の下で複数のプロジェクト（アプリケーション）が並行して進みます。要件定義以降の成果物はプロジェクト別に管理し、戦略とのトレーサビリティを保ちます。
+
+```plantuml
+@startuml
+folder "企業（単一）" {
+  folder "統合戦略\ndocs/strategy" as strategy
+  folder "プロジェクト A" as pa {
+    rectangle "要件・設計・開発\n運用・ADR・ジャーナル" as da
+    rectangle "apps/project-a" as aa
+  }
+  folder "プロジェクト B" as pb {
+    rectangle "要件・設計・開発\n運用・ADR・ジャーナル" as db
+    rectangle "apps/project-b" as ab
+  }
+}
+strategy --> pa
+strategy --> pb
+da --> aa
+db --> ab
+@enduml
+```
+
+## 全体構成
+
+```text
+docs/
+├── index.md              # バンドル全体の入口
+├── log.md                # ドキュメント更新ログ
+├── strategy/             # 【単一】企業戦略・ビジネスアーキテクチャ
+├── requirements/         # 【プロジェクト別】要件定義（RDRA 2.0）
+├── design/               # 【プロジェクト別】アーキテクチャ・モデル・品質方針
+├── development/          # 【プロジェクト別】リリース計画・イテレーション管理
+├── operation/            # 【プロジェクト別】環境構築・デプロイ・運用手順
+├── adr/                  # 【プロジェクト別】Architecture Decision Records
+├── journal/              # 【プロジェクト別】開発ジャーナル
+├── review/               # 【プロジェクト別】分析・開発レビュー結果の記録
+├── article/              # 【共通】学習用の記事シリーズ
+├── reference/            # 【共通】開発ガイドライン・ベストプラクティス
+├── template/             # 【共通】各種ドキュメントのテンプレート
+└── assets/               # 【共通】MkDocs 用スタイル・スクリプト
+apps/
+├── project-a/            # プロジェクト A のアプリケーション本体
+└── project-b/            # プロジェクト B のアプリケーション本体
+```
+
+## 単一（企業共通）のディレクトリ
+
+### docs/strategy
+
+企業分析、経営戦略、ビジネスアーキテクチャ、インセプションデッキを置きます。企業で 1 つの統合戦略として管理するため、**プロジェクト別のサブディレクトリは作りません**。
+
+- 各プロジェクトの要件定義は、この統合戦略を上流として参照します。
+- プロジェクト固有の判断が必要になった場合も、戦略文書自体は分割せず、プロジェクト別カテゴリ（要件定義・ADR）側に記録します。
+
+### docs/reference・docs/template・docs/article・docs/assets
+
+企業・プロジェクトを問わず共有するリソースです。プロジェクト別のサブディレクトリは作りません。
+
+## プロジェクト別のディレクトリ
+
+次の 7 カテゴリは、**プロジェクト単位のサブディレクトリ**で区切ります。
+
+| カテゴリ | 内容 |
+| :--- | :--- |
+| `docs/requirements/` | 要件定義書、ユースケース、ユーザーストーリー |
+| `docs/design/` | アーキテクチャ設計、データモデル、ドメインモデル、UI 設計、テスト戦略、非機能要件 |
+| `docs/development/` | リリース計画、イテレーション計画、開発戦略、進捗レポート |
+| `docs/operation/` | 環境セットアップ手順書、コマンドリファレンス、デプロイ手順 |
+| `docs/adr/` | アーキテクチャ上の意思決定記録 |
+| `docs/journal/` | 開発ジャーナル（判断と学びの記録） |
+| `docs/review/` | 分析・開発・UI/UX・運用レビュー結果の記録 |
+
+### ディレクトリ構造の規約
+
+```text
+docs/<category>/
+├── index.md              # カテゴリ索引：プロジェクト一覧へのリンク
+├── project-a/
+│   ├── index.md          # プロジェクト A のカテゴリ内の入口
+│   └── *.md              # 実ドキュメント
+└── project-b/
+    ├── index.md
+    └── *.md
+```
+
+- カテゴリ直下の `index.md` は**プロジェクト一覧の索引**とし、実ドキュメントはプロジェクトのサブディレクトリに置きます。
+- プロジェクトのサブディレクトリには必ず `index.md` を置き、そのプロジェクトのドキュメント一覧を管理します。
+
+## apps との対応
+
+アプリケーション本体は `apps/` 配下に、**ドキュメントと同じプロジェクト識別子**でディレクトリを区切って配置します。
+
+| ドキュメント | アプリケーション |
+| :--- | :--- |
+| `docs/requirements/project-a/` | `apps/project-a/` |
+| `docs/design/project-a/` | `apps/project-a/` |
+| `docs/development/project-a/` | `apps/project-a/` |
+| `docs/operation/project-a/` | `apps/project-a/` |
+| `docs/adr/project-a/` | `apps/project-a/` |
+| `docs/journal/project-a/` | `apps/project-a/` |
+| `docs/review/project-a/` | `apps/project-a/` |
+
+プロジェクト識別子が一致していることで、ドキュメントからコードへ（またはその逆へ）迷わず辿れます。
+
+### プロジェクト識別子の命名規約
+
+- 英小文字とハイフンのケバブケース（例：`inventory-service`、`sales-portal`）とします。
+- `docs/` 配下のサブディレクトリ名と `apps/` 配下のディレクトリ名は**完全一致**させます。
+- 一度決めた識別子は変更しません。やむを得ず変更する場合は `docs/` と `apps/` を同時に改名し、`docs/log.md` に理由を記録します。
+
+## 新しいプロジェクトを追加する手順
+
+1. プロジェクト識別子を決めます（命名規約に従う）。
+2. `apps/<project>/` を作成し、アプリケーションの雛形を配置します。
+3. プロジェクト別 7 カテゴリに `<project>/index.md` を作成します（最初は空の索引で構いません。`journal/`・`review/` は最初のドキュメント作成時でも可）。
+4. 各カテゴリ直下の `index.md` にプロジェクトのエントリを追加します。
+5. `apply-okf` スキルでフロントマター付与・`docs/log.md` への記録・適合性検証を行います。
+
+## 補足
+
+- 戦略に対する変更は全プロジェクトに影響します。`docs/strategy` を更新した際は、各プロジェクトの要件定義との整合を確認してください。
+- 本ガイドと実際の構成が食い違った場合は、構成を直すか本ガイドを更新し、放置しないでください。

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@k2works/claude-code-booster",
-  "version": "5.0.0",
+  "version": "5.1.0",
   "description": "AI Agent Development Support Tool",
   "main": "main.js",
   "bin": {