@k2works/claude-code-booster 4.17.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/apply-okf/SKILL.md

@@ -0,0 +1,88 @@
+---
+name: apply-okf
+description: OKF（Open Knowledge Format）知識バンドル内で文書を新規作成・更新・レビュー・廃止したときに、OKF の規約（フロントマターの type/title/description/generated、verified、status、stale_after、index.md・log.md の更新、適合性検証）を適用する日常運用スキル。「この設計書に OKF のフロントマターを付けて」「作った ADR をバンドルに登録して」「レビューしたので verified を付けて」「古い手順書を deprecated にして」「index.md と log.md を更新して」「OKF に適合しているか確認して」といった場面で発動する。他のスキル（creating-adr・analyzing-*・planning-releases・creating-journal など）が docs/ 配下に Markdown を書いた直後や、エージェントが生成した知識を人が確認した場面では、明示的な依頼が無くても積極的に使うこと。既存文書の一括移行や仕様バージョンアップは migrating-okf の担当。
+---
+
+# OKF 適用
+
+OKF 知識バンドル（既定 `docs/`）に対する**日常の変更**に規約を適用する。一括移行は `migrating-okf`、本スキルは「1 つ書いた／直した／確認した／捨てた」たびに呼ぶ仕上げ工程。
+
+仕様の日本語リファレンスは `docs/reference/OKF導入ガイド_V0.2.md`。§5（来歴・信頼・ライフサイクル）と §7（アクター規約）が本スキルの根拠。同じディレクトリに `PROJECT.md` があれば必ず読む（バンドルの場所・type 対応表・既定アクターはそこにある）。
+
+## なぜ毎回適用するのか
+
+バンドルの価値は「各文書が信頼してよい根拠を持っている」ことにある。1 つでもフロントマターの無い文書が混ざると `type` 必須の適合性が壊れ、`generated` が更新されない文書は「誰がいつ書いたか」を偽る。規約は移行時に一度守れば済むものではなく、書くたびに守って初めて意味を持つ。
+
+## 4 つの操作
+
+| 操作 | いつ | 何をするか |
+| :--- | :--- | :--- |
+| **apply** | 文書を新規作成・更新した直後 | フロントマター付与／`generated` 更新、`index.md` にエントリ追加、`log.md` に記録。エージェントが書いた新規文書は `status: draft`（未レビュー）、人が書いたものは `stable` |
+| **verify** | 人またはプロセスが内容を確認した | `verified` に `{ by, at }` を追記。`draft` なら `stable` に昇格 |
+| **deprecate** | 文書を置き換えた・不要になった | `status: deprecated`（後継があれば `replaced_by`）、`index.md` の該当エントリに「（廃止 → 後継）」を付記。削除はしない |
+| **check** | 上記の後、コミット前 | `gulp okf:check`（または `migrating-okf/scripts/okf_check.py --check`）で ERROR 0 を確認 |
+
+すべて同梱スクリプトで行う。手でフロントマターを書かない（タイムスタンプの形式や `verified` のリスト化などの細部を間違えやすい）。
+
+```bash
+S=.claude/skills/apply-okf/scripts/okf_apply.py
+python $S apply     docs docs/adr/007-cache-strategy.md --by claude-code/claude-fable-5
+python $S apply     docs --changed --by claude-code/claude-fable-5      # git で変更された .md をまとめて
+python $S verify    docs docs/design/data-model.md --by human:alice
+python $S deprecate docs docs/operation/old-deploy.md --replaced-by /operation/deploy.md
+python $S status    docs docs/design/*.md
+```
+
+`--replaced-by` はバンドル相対パス。Git Bash（Windows）は `/operation/deploy.md` のような先頭 `/` を `C:/Program Files/Git/...` に変換してしまうので、先頭 `/` を付けずに `operation/deploy.md` と書く（スクリプトが `/` を補う）。
+
+## 判断すべきこと（スクリプトは判断しない）
+
+### 誰が書いたか（`--by`）
+
+`generated.by` は「今の本文を書いた者」。自分（エージェント）が本文を書いた・書き換えたなら `claude-code/<model>` のような `<producer>/<version>`。人が書いた文書にフロントマターを付けるだけなら `human:<id>`（git の著者から）。スクリプトは本文が git HEAD から変わっていなければ `generated` を触らないので、フロントマターだけ直す作業で来歴が上書きされる心配はない。
+
+### `verified` を付けてよいか
+
+内容を人が読んで「正しい」と判断したとき、または自動プロセスが照合したときだけ。自分が書いた直後に自分で `verified` を付けない（信頼ティアが `human-reviewed` と `unverified` を区別できなくなる）。ユーザーから「確認した」「レビュー済み」「OK」と言われたら、そのユーザーのアクター（`human:<id>`）で `verify` する。
+
+### `type`
+
+親ディレクトリから推定される（`adr/`→`ADR`、`design/`→`Design`、`development/`→`Plan`、`operation/`→`Playbook` など）。推定が合わない、または新しいディレクトリなら `--type` で明示する。型の数は増やさない。1 ディレクトリ 1 型が目安。
+
+### `stale_after`
+
+「一定期間で見直さないと嘘になる」文書だけに `--stale-days` を付ける。環境構築手順・技術スタック・外部サービスの設定手順が典型。設計判断や記事には付けない。
+
+### `description`
+
+`index.md` と検索結果に出る 1 文。スクリプトは冒頭段落から推定するが、精度は本文次第。推定が弱い（空・自己言及的・冒頭が図やリスト）なら `--description` で書く。
+
+## 他スキルとの連携
+
+`docs/` に文書を書くスキルの最後に本スキルを組み込む。典型的な流れ：
+
+1. `creating-adr` が `docs/adr/007-cache-strategy.md` を書く
+2. `apply docs docs/adr/007-cache-strategy.md --by claude-code/<model>` → フロントマター付与、`adr/index.md` にエントリ、`log.md` に Creation
+3. ユーザーがレビューして承認 → `verify ... --by human:<id>`
+4. 置き換えた ADR-003 があれば `deprecate docs/adr/003-*.md --replaced-by /adr/007-cache-strategy.md`
+5. `gulp okf:check` → ERROR 0 を確認してコミット
+
+`index.md` のエントリはスクリプトが末尾に追加するだけなので、セクション分けされた `index.md` では適切な見出しの下へ移動する。`log.md` のメッセージは既定の自動文で足りるが、判断を伴う変更（廃止理由、大きな書き換え）は `--log` で理由を残す。
+
+## 完了報告
+
+```markdown
+## OKF 適用結果
+
+- 対象: <ファイル>（操作: apply / verify / deprecate）
+- generated: <by, at>（更新した場合）
+- index.md / log.md: 更新の有無
+- 検証: ERROR 0 / WARN <N>
+- 要確認: <description の推定が弱い、type を仮置きした、など>
+```
+
+## 関連スキル
+
+- `migrating-okf` — 既存文書の一括移行・仕様バージョンアップ・検証スクリプト
+- `creating-adr` / `creating-journal` / `analyzing-*` / `planning-releases` — 文書を生む側。書いた直後に本スキル
+- `git-commit` — 検証後のコミット

package/lib/assets/.claude/skills/apply-okf/evals/evals.json

@@ -0,0 +1,8 @@
+{
+  "skill_name": "apply-okf",
+  "evals": [
+    {"id": 1, "prompt": "docs/adr/002-cache-strategy.md を書いたので OKF バンドルに登録して。docs/ は OKF v0.2 バンドル。", "expected_output": "フロントマター（type: ADR、generated はエージェント）付与、adr/index.md にエントリ、log.md に Creation、検証 ERROR 0", "files": []},
+    {"id": 2, "prompt": "docs/design/data-model.md をレビューして問題なかった。OKF 的に確認済みにしておいて。私は human:kakimomokuri。", "expected_output": "verified に human:kakimomokuri を追記、generated は変更しない、log.md に Verification", "files": []},
+    {"id": 3, "prompt": "docs/operation/deploy-old.md は deploy.md に置き換えたからもう使わない。バンドル上で整理して。", "expected_output": "status: deprecated + replaced_by、ファイルは削除しない、log.md に Deprecation", "files": []}
+  ]
+}