kudo-shared-storage-protocol v1.4¶

§1 目的・核心思想¶

工藤拓真の Chat / Cowork / Code の 3 環境が共通参照・書き込み可能な SSOT ストレージを確立する。これにより:

ユーザーが Chat 出力ファイルを毎回手動 DL する手間を削減
Cowork / Code が前のセッションの出力を直接参照できる
マスター名簿・HANDOFF・完了報告等を一元管理
バージョン管理を Drive のネイティブ機能で行う
(v1.3 新規) KUDO-Vault プロジェクトでの GitHub private repo git-backup 経路と整合
(v1.4 新規) _claude_workspace_global/ の生成物を Z Fold 7 から PWA で自動閲覧する経路を確立(§10)

核心思想:「ファイルは Drive にあれば 3 環境すべてが見れる」。Chat の present_files は引き続き工藤さんに即時提示する手段として残しつつ、永続的なファイルは Drive _claude_workspace_global/ に集約する。

1.1 階層的依存(v1.3 新規)¶

~/KUDO-Vault/CLAUDE.md §8.4(機密情報 SSOT・上位)
  ↓
本スキル(集中原則ガバナンス + 3 環境共通ストレージ SSOT)
  ├─→ kudo-context-routing v1.3(案件 _claude_workspace/ の正規特例・並走)
  ├─→ kudo-cowork-code-handoff-protocol §16-3(環境間作業分担・相補)
  └─→ 個人設定 項目12(GitHub Secret Gist・相補)

機密情報の扱いの最終 SSOT は CLAUDE.md §8.4。本スキルはストレージ層の集中原則を担い、機密判断は CLAUDE.md §8.4 を参照する(§7 で詳述)。

§2 起動トリガー¶

直接トリガー¶

「DL したくない」「毎回 DL するのは面倒」
「3環境共通で見たい」「Chat / Cowork / Code 共通参照」
「Drive を SSOT に」「マスター名簿を Drive 配置」
「HANDOFF を Drive 経由で」
「ファイル共有環境を作りたい」
(v1.3 新規) 「機密どこに置く」「クライアント機密の扱い」「GitHub backup」「KUDO-Vault バックアップ」
(v1.4 新規) 「スマホで読みたい」「Z Fold 7 で見たい」「PWA」「Cloudflare Pages」「launchd 自動デプロイ」「mkdocs material」「workspace 自動公開」

状況トリガー¶

マスター名簿・大型ファイルの共有が必要な時
セッションをまたぐ作業の永続化が必要な時
latest symlink パターンが必要だが Chat MCP で実装できない時(Drive MCP の制約)
(v1.3 新規) KUDO-Vault プロジェクトで Vault バックアップ経路の議論が出た時
(v1.4 新規) _claude_workspace_global/ の生成物をモバイルから閲覧したい時

§3 フォルダ構造(_claude_workspace_global/)¶

3-1. 標準構造¶

Google Drive/My Drive/working/_claude_workspace_global/    (ID: 1EXyQOuWn2tvaBqBnhyeIhAH7Gox3jMsF)
├── README.md                              ← 運用ルール SSOT
├── master-lists/                          ← マスター名簿等の正本データ
│   ├── naming-master-list-v0.5.xlsx
│   ├── naming-master-list-v0.6.xlsx       ← 最新版(命名規則による)
│   └── ...
├── handoffs/                              ← Code/Cowork 宛 HANDOFF.md
│   ├── HANDOFF-code-finalize-v3.md
│   ├── COWORK-workflowy-rename-v8.md
│   └── ...
├── reports/                               ← 完了報告・検出レポート
│   ├── 2026-05-15-cowork-v7-completion.md
│   ├── 2026-05-15-code-v3-completion.md
│   └── ...
└── outputs/                               ← 中間成果物・セッション間共有

3-2. フォルダ ID マップ(2026-05-15 確定)¶

フォルダ	ID
`_claude_workspace_global/`(ルート)	`1EXyQOuWn2tvaBqBnhyeIhAH7Gox3jMsF`
`master-lists/`	`1irZqzLOSCoD78l_6CcMMgDwsvAULztzK`
`handoffs/`	`1b5fcUPrwIKFBFTRlpBU5y3landeNW3EZ`
`reports/`	`1kUc2RFvUCldEM2X7hfc-sfTqzc0yhL96`
`outputs/`	`188f0YJTT6MsI89NXPieF9Z1V9nHBNTnK`
`README.md`	`1fEWvAannFWImP3IzJLr4-20O2qmYXPQa`

これらの ID は Chat / Cowork から parentId 指定で使う。

3-3. ID 一覧の永続化¶

ID は memory_user_edits に追加するか、本 SKILL の §3-2 を SSOT とする。本 SKILL §3-2 を SSOT とし、変更があれば本 SKILL を更新する運用を採用。

§4 各環境からのアクセス方法¶

4-1. Chat(claude.ai)¶

読み取り:

Google Drive:search_files(query="parentId = '1EXyQOuWn2tvaBqBnhyeIhAH7Gox3jMsF'")
Google Drive:read_file_content(fileId="<ID>")
Google Drive:download_file_content(fileId="<ID>")
Google Drive:get_file_metadata(fileId="<ID>")

書き込み(新規作成):

# テキストファイル
Google Drive:create_file(
    parentId="1b5fcUPrwIKFBFTRlpBU5y3landeNW3EZ",  # handoffs/
    title="HANDOFF-something.md",
    contentMimeType="text/markdown",
    textContent="...",
    disableConversionToGoogleType=True
)

# バイナリファイル
Google Drive:create_file(
    parentId="1irZqzLOSCoD78l_6CcMMgDwsvAULztzK",  # master-lists/
    title="naming-master-list-v0.7.xlsx",
    contentMimeType="application/vnd.openxmlformats-officedocument.spreadsheetml.sheet",
    base64Content="<base64 string>"
)

書き込み(既存上書き):❌ Drive MCP では不可(kudo-ai-error-watchlist Entry #10)→ 新規バージョン主義で運用

4-2. Code(ローカル Mac)¶

パス:

~/Library/CloudStorage/GoogleDrive-kudotakuma421@gmail.com/My Drive/working/_claude_workspace_global/

フルアクセス:読み書き・既存上書き OK。Drive for desktop が自動同期する。

シンボリックリンクは Code でしか作れない:

ln -sfn ~/Library/CloudStorage/GoogleDrive-kudotakuma421@gmail.com/My\ Drive/working/_claude_workspace_global/master-lists/naming-master-list-v0.6.xlsx \
        ~/Library/CloudStorage/GoogleDrive-kudotakuma421@gmail.com/My\ Drive/working/_claude_workspace_global/master-lists/LATEST.xlsx

ただし Drive 側ではシンボリックリンクではなく実体コピーになる。代替案:ファイル名のバージョン比較で最新を判定(§5 参照)。

4-3. Cowork¶

★仮説:Cowork に Drive MCP が稼働している可能性が高い。要 tool_search で確認:

tool_search(query="google drive search create file")

Drive MCP があれば Chat と同じ手順でアクセス可能。なければ: - 工藤さん経由でファイルを Cowork に提供 - Cowork サンドボックスから手動で ~/working/_claude_workspace/03_output/ へ移動

§5 新規バージョン主義とバージョン管理¶

5-1. 原則¶

Drive MCP の制約により、Chat / Cowork からは既存ファイルの上書きができない。これを新規バージョン主義で吸収する:

❌ naming-master-list.xlsx を上書き
✅ naming-master-list-v0.6.xlsx を新規作成(v0.5 は残す)

5-2. 最新版の判定¶

「最新」はファイル名のバージョン番号で判定。各環境のスクリプトは以下のロジックで最新を取得:

import re
from pathlib import Path

def latest_version(folder_path: Path, prefix: str) -> Path:
    """{prefix}-v{X}.{Y}.{ext} のうち最大の vX.Y を返す"""
    pattern = re.compile(rf"^{re.escape(prefix)}-v(\d+)\.(\d+)\.[^.]+$")
    candidates = []
    for f in folder_path.iterdir():
        m = pattern.match(f.name)
        if m:
            candidates.append((int(m.group(1)), int(m.group(2)), f))
    if not candidates:
        raise FileNotFoundError(f"No {prefix}-vX.Y file in {folder_path}")
    return max(candidates)[2]

5-3. LATEST.txt(オプション)¶

複雑なバージョン管理が必要な場合、master-lists/LATEST.txt に最新ファイル名だけを書く:

naming-master-list-v0.6.xlsx

これも上書き不可なので、毎回新規作成・古いものは削除する運用(または LATEST-vN.txt として保持)。

5-4. シンプル運用(推奨)¶

★私見:5-1 + 5-2 の組み合わせで十分。LATEST.txt は不要。スクリプトは「最大バージョン番号」を最新として扱う。

§5.5 集中原則ガバナンス(v1.2 新設・v1.3 で参照階層更新)¶

5.5-1. 集中原則の宣言¶

すべての Claude 関連生成物の格納先は、原則として ~/working/_claude_workspace_global/ 配下を第一選択とする。 これは個人設定 v5.1 項目15・memory #19・本 SKILL §5.5・(v1.3 新規) KUDO-Vault CLAUDE.md §3.1 の四層 SSOT で永続化される。

5.5-2. 対象となる生成物¶

カテゴリ	サブフォルダ	例
マスター名簿	`master-lists/`	naming-master-list-v*.xlsx
HANDOFF 文書	`handoffs/`	HANDOFF-code-.md, COWORK-.md
完了報告・検出レポート	`reports/`	各プロジェクト完了サマリー / validate ログ / Cowork 完了報告 / Code 完了報告
中間成果物・セッション間共有	`outputs/`	一時的なスクラッチ・分析メモ・PoC 検証データ

5.5-3. 例外(特例配置)と相談プロトコル¶

以下のケースは「特例配置」として扱い、作業開始前に工藤さんに相談する:

クライアント固有の制作物:提案資料 PPTX・ロゴ SVG・KV・各クライアント独自のリサーチ等
→ 各案件直下 working/顧客ビジネス/{クライアント名}/_claude_workspace/(kudo-context-routing v1.3 §6.2 既定)
相談不要(明示的に既定ルールに則る)
即時 DL のみで永続化不要なもの:proposal preview HTML / 一回限りのテンプレ生成等
→ present_files で /mnt/user-data/outputs/ のみ
相談不要(明示的に「永続化しない」と分かるもののみ)
(v1.3 新規) Obsidian Vault 配置物:ADR・insight・スキル本体・横断知見
→ ~/KUDO-Vault/ 配下(CLAUDE.md §2 ボルト構造に従う)
相談不要(Vault は本スキル _claude_workspace_global/ の正規特例として明示済み)
その他:上記以外の理由で _claude_workspace_global/ 外に置きたい場合
必ず作業開始前に「これは _claude_workspace_global ではなく ___ に置きます。理由:___」と工藤さんに確認
例:~/Desktop/ / ~/Downloads/ / Drive ルート直下 / 各種一時ディレクトリ等

5.5-4. 違反禁止リスト¶

以下は絶対禁止(過去の失敗事例から):

パターン	禁止理由	教訓
Drive ルート直下に Claude 関連フォルダ作成	Drive 乱雑化	2026-05-15 私が `_claude_shared/` を作ったケース(kudo-ai-error-watchlist 候補)
`~/Downloads/` への永続化前提配置	DL フォルダは消える前提・整理対象	Code v3 で v0.5 マスター名簿が `~/Downloads/` ではなく `~/Desktop/` にあった事案(Entry #14)
`/tmp/` への永続化前提配置	再起動で消える	(事故未然防止)
`/mnt/user-data/outputs/` だけで present_files 完結	永続化されない・工藤さん DL 必須	永続化必要なものは Drive 経由が原則
各案件 `_claude_workspace/` への横断的ファイル混入	案件のスコープを超える	命名統一マスター名簿を Mizkan 案件下に置く等は NG
(v1.3 新規) KUDO-Vault `01-Projects/` への横断的ファイル混入	Vault スコープ違反	Vault は「意思の居場所」、横断作業ログは `_claude_workspace_global/`
(v1.4 新規) `_claude_workspace_global/` 自体を git 化	Drive 同期と `.git/` が競合・複数 PC で破綻	kudo-ai-error-watchlist Entry #29(workspace 自動公開設計時に回避)

5.5-5. 既存 SKILL 群への波及(移行計画)¶

本ガバナンス導入により、以下の SKILL は順次見直しが必要(v1.3 で進捗反映):

kudo-context-routing v1.3:✅ 完了(Stage 1-C-2 #3 で正規特例関係を明文化)
kudo-workflowy-double-save v3.3:✅ 完了(Stage 1-C-2 #2 で三重保存と本スキルの役割分担明示)
kudo-cowork-code-handoff-protocol v1.12 §13:HANDOFF 配置先 SSOT を本 SKILL handoffs/ に変更(未着手・Stage 1-C-3 候補)
kudo-naming-unification-protocol v2.3:マスター名簿配置先を本 SKILL master-lists/ に変更(未着手・Stage 1-C-3 候補)
kudo-persist-settings:設定ファイル所在マップに本 SKILL を追加(未着手・Stage 1-C-3 候補)
kudo-proposal-deck / kudo-html-publish / kudo-client-template-factory:クライアント案件物として例外1扱い(変更不要)
その他全 SKILL:Code 連携で機械的に grep 走査して影響箇所をリスト化(Stage 1-C-3 47件健全性レビューで実施)

5.5-6. 違反検出の自動化候補(将来)¶

validate_naming_consistency.py v3 で軸6 として「Claude 関連管理ファイルが _claude_workspace_global/ 外にないか」走査
月曜 4:00 cron に組み込み
(v1.3 新規) Stage 1-C-3 47件健全性スキャナの腐敗パターン検出ロジックに統合検討

5.5-7. 工藤さんへの相談時のテンプレ¶

これは _claude_workspace_global ではなく ___ に置きます。
理由:___
影響範囲:___
よろしいですか?(同意なら 1 文字 OK で進めます)

§6 各環境の権限非対称性(Entry #10 と整合)¶

環境	新規作成	既存上書き	既存削除	既存リネーム	既存移動
Chat	✅	❌	🟡 確認要	❌	❌
Cowork	🟡 要確認	🟡 要確認	🟡 要確認	🟡 要確認	🟡 要確認
Code	✅	✅	✅	✅	✅

重要:Chat / Cowork は新規作成系のみ確実。既存ファイルの更新・削除・移動を伴う作業は Code に振る(kudo-cowork-code-handoff-protocol §16-3 v1.12 と整合)。

§7 機密の扱い¶

7.1 機密判断の上位 SSOT(v1.3 新規)¶

機密情報の扱いの最終 SSOT は ~/KUDO-Vault/CLAUDE.md §8.4。本スキルはストレージ層の運用を担い、「何が機密か」の判断は CLAUDE.md §8.4 を一次ソースとする:

CLAUDE.md §8.4 の機密判断要約: - ✅ OK:意思決定・メタ情報・公開可能な戦略メモ・方法論・取引先名・案件名(工藤氏が外部公開している関係) - ❌ NG:契約書本文・未公開財務数値・パスワード/API Key/PAT/TLS 秘密鍵・NDA 厳格相手の未公開戦略

7.2 本スキルのストレージ層運用¶

Drive はデフォルトで工藤さん個人のみアクセス可。共有設定は変更しないこと。

クライアント機密情報(NDA 対象)のストレージ配置: - 真に機密な情報は本フォルダにも置かない(CLAUDE.md §8.4 と整合) - 内部運用ファイル(提案下書き等)は OK - GitHub Secret Gist との使い分け: - 本フォルダ(_claude_workspace_global):機密含まない内部運用ファイル - Secret Gist(個人設定項目12):raw URL で AI エージェント参照が必要な参照HTML/データセット - 真に機密なクライアント情報の正本:各案件 _claude_workspace/(Vault 外・本スキル集中原則の対象外)に置く

7.3 認証情報の取り扱い(v1.3 新規)¶

PAT・API Key・パスワード・SSH 鍵などの認証情報は: - 本フォルダに永続化しない(原則) - macOS Keychain(osxkeychain)や 1Password 等の専用パスワードマネージャに保管 - 画像経由のリーク(スクリーンショット内に credentials が映る)も警戒(kudo-ai-error-watchlist Entry 参照) - credentials を含む画面のスクショは AI セッションに渡さない

§8 GitHub git-backup 経路(v1.3 新規)¶

8.1 KUDO-Vault の遠隔バックアップ¶

KUDO-Vault プロジェクト(2026 年〜)では、ボルト全体を GitHub private repo kudotakuma/KUDO-Vault で遠隔バックアップする。これは Stage 1-B3(2026-05-20)で確立した:

項目	値
repo URL	`https://github.com/kudotakuma/KUDO-Vault`(private)
方式	git-backup(rsync 廃止、Stage 1-B3 判定 B 起点)
認証	GitHub PAT(macOS Keychain 保存)+ 2FA(Authenticator アプリ)
コミット頻度	主要な変更ごとに即時 commit + push、自動 commit は LaunchAgent で日次
対象範囲	KUDO-Vault 全体(.git, .obsidian は除外、`.gitignore` 規律あり)
非対象	`_claude_workspace_global/`(本スキル管轄・Drive 同期で十分)

8.2 本スキル `_claude_workspace_global/` との関係¶

_claude_workspace_global/ 自体は GitHub backup 対象外: - Drive for desktop による自動同期があるため遠隔バックアップは確保済み - 作業中のスクラッチ・中間成果物が多く、git 履歴には過剰 - 機密度の低い内容(機密判断は CLAUDE.md §8.4 + 本スキル §7.2 で別途管理) - (v1.4 新規) git 化自体が Drive 同期と競合するため不可(kudo-ai-error-watchlist Entry #29)

ただし、本スキル _claude_workspace_global/reports/ の重要な完了報告で永続価値があるものは、必要に応じて Vault 03-Resources/research/ 等にコピー配置することで GitHub backup 対象にできる(任意・工藤氏判断)。

8.3 個人設定項目 12(GitHub Secret Gist)との関係¶

用途	配置
AI エージェントが raw URL 経由で参照する公開可能な参照データ	GitHub Secret Gist(個人設定項目 12)
Vault 本体(機密含む知識アーカイブ)	GitHub private repo `KUDO-Vault`
3 環境共通作業ストレージ(機密含まない運用ファイル)	Drive `_claude_workspace_global/`(本スキル)
真に機密な情報(契約書・未公開数値・credentials)	どこにも置かない(CLAUDE.md §8.4)

§9 移行プロセス(命名統一プロジェクトでの実証)¶

Phase 1: フォルダ構造作成(完了・2026-05-15)¶

Chat MCP で _claude_workspace_global/ 階層作成 ✅
README.md 配置 ✅

Phase 2: 既存ファイルの Drive 移行(完了・2026-05-15)¶

✅ v0.5 / v0.6 マスター名簿を _claude_workspace_global/master-lists/ に配置
✅ HANDOFF-code-finalize-v3 等を _claude_workspace_global/handoffs/ に配置
✅ Code v3 / Cowork v7 完了報告を _claude_workspace_global/reports/ に配置

Phase 3: 運用への組み込み(進行中・2026-05-21〜)¶

✅ 新規 HANDOFF は Drive _claude_workspace_global/handoffs/ 経由で渡す
✅ マスター名簿は Drive 一元管理
⏳ Code 側 validate スクリプトの参照パスを CloudStorage 経由に変更(未完了)
(v1.3 新規) ✅ KUDO-Vault プロジェクトの完了報告・HANDOFF・設計書を本スキルに集約済(Stage 1-C-1 / 1-C-2 で実証)

Phase 4: latest 機構の確立(進行中)¶

Code が _claude_workspace_global/master-lists/ を走査して最新版を判定(§5-2)
LaunchAgent スクリプトを CloudStorage パス対応に更新(未完了)

Phase 5: 47件健全性スキャナ統合(将来・Stage 1-C-3)¶

集中原則違反を腐敗パターンとして検出するロジックを 47件健全性スキャナに統合
月曜 cron で週次走査

§10 workspace 自動公開プロトコル(v1.4 新規)¶

_claude_workspace_global/ の Markdown / HTML を、保存アクションなしで Z Fold 7(Android)の PWA から閲覧できる状態を恒久維持する自動公開インフラ。2026-05-28 確立。

10.1 アーキテクチャ¶

~/working/_claude_workspace_global/   ← ソース(Drive同期・既存集中原則)
        ↓ launchd + fswatch(30秒デバウンス) → rsync
~/claude-workspace-site/docs/         ← MkDocsソース(git管理外)
        ↓ mkdocs build
~/claude-workspace-site/site/         ← ビルド結果
        ↓ wrangler pages deploy
Cloudflare Pages(Access認証付き)      ← kudo-workspace.pages.dev
        ↓
Z Fold 7 PWA(ホーム画面アプリ)

★重要な設計判断:_claude_workspace_global/ 自体は git 化しない(Drive 同期と .git/ が競合するため・kudo-ai-error-watchlist Entry #29 既知リスク)。代わりに launchd が rsync で MkDocs プロジェクトへ内容を複製する。

10.2 構成要素¶

レイヤー	実体	役割
ソース	`~/working/_claude_workspace_global/`	集中原則 §5.5 で全 Claude 生成物が集まる場所
監視	`~/claude-workspace-site/fswatch-watcher.sh` + launchd `com.kudo.workspace-autodeploy`	30 秒デバウンスで変更検知
同期	rsync(`backups/` `.DS_Store` `.git` 除外・Markdown/HTML のみ)	機密判定なし(Access 認証で保護)
ビルド	mkdocs-material(Japanese 検索・dark mode・awesome-pages)	`.md` をテーマ整形・`.html` は素のまま
デプロイ	wrangler pages deploy(無料枠)	全帯域無制限・500 ビルド/月
認証	Cloudflare Access(kudotakuma421@gmail.com のみ Allow)	URL 知っていても不可視
閲覧	Z Fold 7 / PWA(manifest.webmanifest + overrides/main.html)	ホーム画面アプリ化

10.3 集中原則との整合¶

工藤さんが触れるのは両端のみ: 1. 「Claude に生成を頼む」(成果物が _claude_workspace_global/ に書き込まれる ← 集中原則 §5.5 で既に確立) 2. 「Z Fold 7 でアプリを開く」(PWA をタップ)

中間(rsync → build → deploy)は launchd による全自動。集中原則の「すべての Claude 生成物は _claude_workspace_global/ 配下」が、本プロトコルの「閲覧自動化」と直結している。

10.4 機密判定の階層¶

本スキル §7 機密の扱いが優先(CLAUDE.md §8.4 が上位 SSOT)
機密ファイルは _claude_workspace_global/ ではなく KUDO-Vault に配置(集中原則の正規特例)
そのため自動公開対象から除外される
追加で rsync の --exclude パターンで特定フォルダを除外する選択肢もあり(backups/ は既定で除外済み)
万一の流出に備え Cloudflare Access で Email 一致のみ許可

10.5 リッチ HTML と Markdown の両対応¶

.md は MkDocs Material テーマで整形(統一感)
.html(Plus-Sum マニュアル等の self-contained HTML)はそのまま site/ に配信(素のレンダリング保持)
mkdocs.yml の use_directory_urls: true で直リンク対応

10.6 運用上の制約¶

Mac が起動していることが前提(launchd は Mac で動く・出先で生成された WorkFlowy/Drive ファイルは Mac 起動後に同期)
Cloudflare Pages 無料枠:500 ビルド/月。30 秒デバウンス + 多重起動 LOCK で抑制しているが、過剰な書き込みが続く時は方式 B(15 分定期実行)に切替検討
Drive 同期遅延:Mac の Drive クライアント同期遅延がある時は fswatch 検知も遅れる(これは前提と割り切る)

10.7 関連ファイル¶

~/claude-workspace-site/auto-deploy.sh — rsync → mkdocs build → wrangler deploy
~/claude-workspace-site/fswatch-watcher.sh — 30 秒デバウンス監視
~/Library/LaunchAgents/com.kudo.workspace-autodeploy.plist — launchd 設定
~/claude-workspace-site/mkdocs.yml — MkDocs Material 設定
~/claude-workspace-site/overrides/main.html — PWA head 注入(manifest / theme-color / apple-touch-icon)
~/claude-workspace-site/docs/manifest.webmanifest — PWA マニフェスト
~/claude-workspace-site/docs/assets/icons/*.png — PWA アイコン(192/512 + maskable)
~/claude-workspace-site/logs/ — auto-deploy / fswatch-watcher / launchd のログ

10.8 関連 HANDOFF¶

~/working/_claude_workspace_global/handoffs/HANDOFF_workspace_auto_publish_infra_2026-05-28.md — Chat → Code への構築指示
~/working/_claude_workspace_global/handoffs/HANDOFF_cloudflare_access_setup_2026-05-28.md — 工藤さんへの Access 設定手順
~/working/_claude_workspace_global/handoffs/HANDOFF_zfold7_pwa_install_2026-05-28.md — 工藤さんへの PWA インストール手順

§11 関連スキル¶

kudo-context-routing v1.3:案件 _claude_workspace/ と本スキル _claude_workspace_global/ の正規特例関係(並走・相補)
kudo-cowork-code-handoff-protocol §16-3:環境間の作業分担マトリクス(本スキルと相補)
kudo-ai-error-watchlist Entry #10:Drive MCP に書き込み系(rename/update/move)が存在しない事実
kudo-ai-error-watchlist Entry #14:Chat 出力ファイル保存先 = Desktop(本スキルで Drive に変更)
(v1.4 新規) kudo-ai-error-watchlist Entry #29:Drive 同期フォルダ git 化リスク(本スキル §10 の回避設計根拠)
kudo-naming-unification-protocol §6:文字正規化(Drive 上でも全角カッコ統一)
(v1.3 新規) ~/KUDO-Vault/CLAUDE.md §8.4:機密情報判断の上位 SSOT
(v1.3 新規) kudo-workflowy-double-save v3.3:三重保存の WorkFlowy サブ層実装(永続アーカイブ層の片方)
(v1.3 新規) kudo-triple-store-write v1.0:三重保存プロトコル定義(本スキルとの関係:本スキルは「3 環境共通ストレージ」、向こうは「会話の三重保存」を扱う別レイヤー)
個人設定項目12:GitHub Secret Gist 運用ルール(本スキルと相補)

§12 改訂履歴¶

v1.4(2026-05-28・workspace 自動公開プロトコル新設):工藤さんの要望「Code/Cowork が作った資料・メモ・HTML を保存アクションなしで Z Fold 7 から見やすく閲覧したい」を起点に:
§10 workspace 自動公開プロトコルを新設(launchd + fswatch + rsync + MkDocs Material + Cloudflare Pages/Access + PWA の恒久インフラ)
既存 §10 関連スキル → §11、§11 改訂履歴 → §12 にシフト
frontmatter anchors に workspace-auto-publish 追加・version 1.3 → 1.4
description に新トリガー追記(「スマホで読みたい」「Z Fold 7 で見たい」「PWA」「Cloudflare Pages」「launchd 自動デプロイ」「mkdocs material」「workspace 自動公開」)
§5.5-4 違反禁止リストに「_claude_workspace_global/ 自体を git 化」を追加
§8.2 に git 化不可の根拠を追記
kudo-ai-error-watchlist Entry #29(Drive 同期 + git 化リスク)と双方向参照
実装ファイル: HANDOFF_workspace_auto_publish_infra_2026-05-28.md / HANDOFF_cloudflare_access_setup_2026-05-28.md / HANDOFF_zfold7_pwa_install_2026-05-28.md
v1.3(2026-05-21・KUDO-Vault 統合 + 版番ドリフト解消):ADR 2026-05-21-stage-1c-2-redesign 系列の Stage 1-C-2 #4/5 として改訂:
版番ドリフト解消:ヘッダー版番 v1.0 → v1.3 に統一(description は v1.2、§11 改訂履歴は v1.2 まで進んでいた旧 schema の不整合を解消)
frontmatter フル整備:version: 1.3 / anchors: キーを §10 から昇格し本文の {#anchor} 形式と対応・13 件定義 / naming_aliases: [] 追加。既存の verb_group: 5 旧 schema は保持(他スキルとの整合確認待ち・Stage 1-C-3 で一括 schema 統一候補)
§1.1 階層的依存を新規追加:CLAUDE.md §8.4 が上位 SSOT、本スキルはストレージ層、kudo-context-routing v1.3 が並走の構造を明示
§5.5-3 特例配置に Obsidian Vault 配置物を追加:Vault は本スキル _claude_workspace_global/ の正規特例として明示(相談不要)
§5.5-4 違反禁止リストに Vault スコープ違反を追加
§5.5-5 既存 SKILL 群への波及:Stage 1-C-2 #2 (kudo-workflowy-double-save v3.3) / #3 (kudo-context-routing v1.3) の完了を反映、残り波及対象は Stage 1-C-3 候補と明示
§7 機密の扱いを階層化:7.1 で CLAUDE.md §8.4 を上位 SSOT として明示、7.2 本スキルのストレージ層運用、7.3 認証情報の取り扱い(PAT 漏洩 Entry 反映)を分離
§8 GitHub git-backup 経路を新規章として独立:Stage 1-B3 で確立した KUDO-Vault git-backup 経路を本スキルから明示参照、本スキル _claude_workspace_global/ との関係(本スキルは git-backup 対象外・Drive 同期で代替)を整理
§9 移行プロセスの進捗反映:Phase 2 / 3 の Stage 1-C-1・1-C-2 までの進捗を ✅ で更新、Phase 5(47件健全性スキャナ統合)を新規追加
§10 関連スキルに CLAUDE.md §8.4・kudo-workflowy-double-save v3.3・kudo-triple-store-write v1.0 への参照を追加
v1.2(2026-05-15・集中原則ガバナンス強化):工藤さん指示「あらゆる作業で生成物の格納先を極力 _claude_workspace_global に集中・特例は都度相談」を受け、§5.5 集中原則ガバナンスを新設:
§5.5-1 集中原則の宣言(個人設定 v5.1 項目15・memory #19 と三層 SSOT)
§5.5-2 対象生成物のカテゴリ別配置マップ
§5.5-3 特例配置の3パターンと相談プロトコル
§5.5-4 違反禁止リスト(過去の失敗事例から)
§5.5-5 既存 SKILL 群への波及(移行計画)— Code 連携で機械的 grep 走査(Phase 2)
§5.5-6 違反検出の自動化候補
§5.5-7 工藤さん相談時のテンプレ
v1.1(2026-05-15・配置場所修正):工藤さんからの指摘「Google Drive 内がゴチャゴチャするのが嫌・working/ 配下に Claude 関連の生成物を一元的に納品するフォルダを作ろう」を受け、配置場所を全面修正:
旧:My Drive/_claude_shared/(ルート直下・Drive 乱雑化)
新:My Drive/working/_claude_workspace_global/(既存 working 配下に集約)
命名整合:案件直下「_claude_workspace」(kudo-context-routing v1.2)との対称命名で _claude_workspace_global を採用
旧フォルダ(Drive ルート直下 _claude_shared/)は Code 側で削除(HANDOFF 経由)
フォルダ ID マップを全面更新(§3-2)
命名統一プロジェクト最終総括ドキュメント(D)を新配置 reports/ に配置済(ID: 1AMO5z_qe7YKyKhBuxGNAOtNRYKxUU_yf)
v1.0(2026-05-15):新規スキル作成。命名統一プロジェクト完走時、工藤さんの「DL しなくても 3 環境共通参照できる構造はないか」の問いを起点に:
Drive _claude_shared/(旧名)フォルダ階層を Chat MCP で実機作成
各環境のアクセス方法・権限非対称性を明文化
新規バージョン主義によるバージョン管理を確立
kudo-cowork-code-handoff-protocol §16-3 v1.12 と相補的関係を明示
移行プロセス Phase 1(フォルダ階層作成)まで実証完了。Phase 2-4 は今後実装