Stage 1-C-2 prep 完了報告¶

結論¶

✅ Task A：4 スキルすべての SKILL.md を verbatim 取得（合計 78100 bytes / 1271 行）
✅ Task B：4 件の被参照マップ作成（参照ファイル合計 53 件・参照行合計 163 行）
✅ Task C-1：00-Inbox/workflowy-import/ 存在確認（空ディレクトリ）
⚠️ Task C-2：Cowork scheduled-tasks は Code 範囲外（Stage 1-C 着手準備 §A-6 と同じ申し送り）
✅ Task C-3：Git 状態（working tree clean、push 待ち 7 commits、remote 設定済み）
⚠️ Task D-2：Chat 起草方針への矛盾指摘 3 件（後述）
Stage 1-C-2 改訂着手は本 HANDOFF 範囲外。Chat 起草を待機。

Task A：4 スキルの現状 verbatim¶

各スキルについて、メタ情報 → frontmatter → セクション構造 → 全文の順で記載。

A-1. `kudo-workflowy-double-save`¶

役割：WorkFlowy 統合 SSOT・三重保存（リネーム＋全面改訂対象）

メタ情報¶

パス：~/KUDO-Vault/.claude/skills/kudo/kudo-workflowy-double-save/SKILL.md
サイズ：31908 bytes / 496 行
frontmatter 行数：4 行
本文セクション数（## / ###）：60
同梱ファイル：なし（SKILL.md 単一構成）

frontmatter 抜粋¶

---
name: kudo-workflowy-double-save
description: "工藤拓真のChat活動を三重保存（Claudeメモリ・プロジェクトファイル・WorkFlowy）で自動アーカイブする統合運用スキル＋WorkFlowy統合運用ルールの一次ソース（SSOT）。動詞群5（Skillを管理する）所属。v3.0で個人設定からプロトコル本体を完全移植しSSOTに昇格、v3.1で§1.1〜§1.3を新設し書込先4カテゴリ分類（A.当日フロー系／B.案件横断・システムログ系／C.案件別蓄積系／D.中長期ストック系）と命名規則・complete扱いを完全規定。「議事録残して」「WorkFlowyに書いて」「ダイジェスト作って」「タスク失敗してる」「daily-chat-digest失敗」「失敗検知」「親IDロック」「noteフィールド禁止」「読込先優先順位」「書込み前チェックリスト」「重複セクション防止」「Cowork記録ルーティン」「同期」「キャッチアップ」「引き継ぎメモ」「これまでの話まとめ」「夜間バッチ動いてない」「書込先カテゴリ」「書込先統一」「4カテゴリ分類」「ストック系どこに書く」などでトリガー。kudo-project-state-recovery／kudo-context-routingと連携、状態再構成時はWorkFlowyダイジェストを最優先参照。WorkFlowy書込・読込ルールの実体は本スキル§運用ルールSSOTが正本。v3.2（2026-05-15・集中原則）§7 保存先表に _claude_workspace_global/ を最上位カテゴリとして追記、基本思想表も二層化対応。"
---

本文セクション構造¶

L   8: ## 目的
L  16: ## §運用ルール SSOT（一次ソース・WorkFlowy統合の正本）
L  22: ### §運用ルール SSOT §1 親IDロック
L  30: ### §運用ルール SSOT §1.1 書込先4カテゴリ分類（v3.1新設）
L  49: ### §運用ルール SSOT §1.2 命名規則（v3.1新設）
L  60: ### §運用ルール SSOT §1.3 完了マーク（complete）の取り扱い（v3.1新設）
L  71: ### §運用ルール SSOT §2 noteフィールド禁止
L  79: ### §運用ルール SSOT §3 読込先優先順位
L  91: ### §運用ルール SSOT §4 書込み前チェックリスト（毎回実行）
L 101: ### §運用ルール SSOT §5 失敗検知プロトコル
L 109: ### §運用ルール SSOT §6 重複セクション防止プロトコル（§1.3 連動）
L 117: ### §運用ルール SSOT §7 Cowork/Codeセッション終了時の記録ルーティン（必須）
L 131: ### §運用ルール SSOT §8 SKILL.md側のルール
L 137: ## 基本思想：三重保存アーキテクチャ
L 139: ### 保存先の役割分担
L 154: ### Chat環境 vs Cowork環境の役割分担（重要）
L 169: ## 三重保存の具体的な動作
L 171: ### 自動モード（通常運用）
L 177: ### 手動モード（緊急時・明示指示時）
L 188: ## 議事録・ダイジェストの標準フォーマット
L 190: ### 4項目構造（共通）
L 201: ### WorkFlowy上の階層構造
L 230: ## 案件キーワードリスト（分類用・動的）
L 234: ### 現状のクライアント案件
L 252: ### 継続プロジェクト
L 260: ### スキル・システム開発
L 266: ### 理論・フレームワーク
L 272: ### 分類不能時
L 276: ### リスト更新ルール
L 285: ## 冪等性・重複防止
L 287: ### WorkFlowy側の重複チェック
L 293: ### バックアップタスクの役割
L 300: ### セクション重複防止
L 306: ## 失敗検知プロトコル詳細（v2.1新設・v3.0で SSOT §5 と統合）
L 308: ### なぜ必要か
L 314: ### 失敗検知の自動化フロー
L 353: ### 故障再発防止のチェックリスト
L 359: ### 違反時の挙動
L 365: ## 関連スキル・タスクとの関係
L 367: ### kudo-project-state-recovery との連携
L 373: ### kudo-context-routing との連携
L 379: ### kudo-naming-unification-protocol との連携
L 383: ### kudo-sync-cycle の扱い
L 387: ### Coworkタスク群との連携（v3.1で§1.1カテゴリ表示追加）
L 401: ## Chat側スキル起動時の挙動
L 403: ### トリガー時の確認事項
L 412: ### 議事録生成の手順
L 424: ### 出力フォーマット例
L 429: ## 要点
L 432: ## 議論トピック
L 436: ## 決定事項
L 439: ## 未決事項
L 442: ## 次のアクション
L 445: ## 詳細
L 451: ## 禁止事項
L 461: ## 運用上の原則
L 463: ### 「任せる」設計
L 473: ### 情報量の調整
L 479: ### 案件分類の継続改善
L 487: ## 更新履歴

SKILL.md 全文（verbatim）¶

---
name: kudo-workflowy-double-save
description: "工藤拓真のChat活動を三重保存（Claudeメモリ・プロジェクトファイル・WorkFlowy）で自動アーカイブする統合運用スキル＋WorkFlowy統合運用ルールの一次ソース（SSOT）。動詞群5（Skillを管理する）所属。v3.0で個人設定からプロトコル本体を完全移植しSSOTに昇格、v3.1で§1.1〜§1.3を新設し書込先4カテゴリ分類（A.当日フロー系／B.案件横断・システムログ系／C.案件別蓄積系／D.中長期ストック系）と命名規則・complete扱いを完全規定。「議事録残して」「WorkFlowyに書いて」「ダイジェスト作って」「タスク失敗してる」「daily-chat-digest失敗」「失敗検知」「親IDロック」「noteフィールド禁止」「読込先優先順位」「書込み前チェックリスト」「重複セクション防止」「Cowork記録ルーティン」「同期」「キャッチアップ」「引き継ぎメモ」「これまでの話まとめ」「夜間バッチ動いてない」「書込先カテゴリ」「書込先統一」「4カテゴリ分類」「ストック系どこに書く」などでトリガー。kudo-project-state-recovery／kudo-context-routingと連携、状態再構成時はWorkFlowyダイジェストを最優先参照。WorkFlowy書込・読込ルールの実体は本スキル§運用ルールSSOTが正本。v3.2（2026-05-15・集中原則）§7 保存先表に _claude_workspace_global/ を最上位カテゴリとして追記、基本思想表も二層化対応。"
---

# kudo-workflowy-double-save v3.2

## 目的

工藤拓真のChatでのあらゆる活動（壁打ち・戦略議論・コピー開発・スキル設計など）を、**三重保存**によって情報断絶なくアーカイブする。

**v3.1でSSOT §1を完全規定化**：v3.0で本スキルがSSOTに昇格した後、scheduled-tasks 16本の書込先実装を監査した結果、「[1日1新およびToDo]傘下のどこに置くか」のサブルールが暗黙化していた。v3.1では §1.1（書込先4カテゴリ分類）・§1.2（命名規則）・§1.3（complete扱い）を新設し、すべての書込みパターンを完全規定する。これによりscheduled-tasks／SKILL.md／PROJECT-CLAUDE.md／個人設定すべてが本セクションを単一参照点とする「完全統一」が達成される。

---

## §運用ルール SSOT（一次ソース・WorkFlowy統合の正本）

**本セクションが WorkFlowy統合の唯一の正本（Single Source of Truth）。**

すべてのスキル・scheduled tasks・補足ドキュメント・PROJECT-CLAUDE.md・個人設定は、本セクションを参照ポインタで指し、自分の中にIDやパスの実体記述を持たない。本セクションを更新すれば全システムに自動反映される。

### §運用ルール SSOT §1 親IDロック

ClaudeによるWorkFlowyへの全書き込みは、「[1日1新およびToDo]」ノード（**ID: 8cfc1d50-7222-e2ce-79d0-8fc9faf6a6c2**）の傘下に限定する。例外なし。

- `workflowy_create` の `parent` パラメータには必ずこのIDまたはこの傘下にある子孫ノードのIDを指定
- ルートおよび他のトップレベルノード（`001.MEMOる` / `02.KEEPする` / `03.何でもarchive` 等）直下への書き込みは禁止
- `workflowy_search` でヒットしたノードに書き込む場合、そのノードが「[1日1新およびToDo]」傘下にあることを `workflowy_get` の `include_ancestors` で必ず確認

### §運用ルール SSOT §1.1 書込先4カテゴリ分類（v3.1新設）

「[1日1新およびToDo]」傘下のどこに置くかを以下4カテゴリで完全規定する。新規scheduled-tasks／SKILL.md設計時は、必ず本表のいずれかに分類してから書込先を決定する。

| カテゴリ | 書込先（具体ノード） | 性質 | 該当タスク例 |
|---|---|---|---|
| **A. 当日フロー系** | 「今日1700までに絶対更新！」直下 | 当日中に参照・消化されるフロー情報 | morning-briefing-0500／daily-todo-alert-1630／idea-shuffle-mon-wed-fri／photo-memo-backlog-0200／photo-memo-backlog-0700-backup／monthly-expense-collector／branding-dictionary-daily（Step 7生成完了ログ） |
| **B. 案件横断・システムログ系** | 「[1日1新およびToDo]」直下 | 複数案件にまたがる活動記録、週次月次の蓄積、システムログ | daily-chat-digest-2330／daily-chat-digest-0800-backup／weekly-designer-trend-watch（巡回ログ）／monthly-expense-midcheck／morning-briefing-0700-backup／📛失敗ログ全般 |
| **C. 案件別蓄積系** | 各案件 `#project` ノード傘下（「[1日1新およびToDo]」直下に作成された案件ノード） | 案件単位のアーカイブ・週次レビュー | daily-chat-digest（手動モード議事録）／weekly-review-sunday-2100 |
| **D. 中長期ストック系** | 「[1日1新およびToDo]」直下に専用ストック親ノードを作りその傘下に追記 | ライブラリ／辞典／観察データベース等の永続蓄積 | branding-dictionary-daily（📚 言葉辞典v2 ストック）／weekly-designer-trend-watch（観察デザイナー層） |

**判定フロー**：

1. その書込みは「当日中に参照されるフロー情報」か？ → YES なら **A**
2. その書込みは「複数案件にまたがる横断ログ／システムログ」か？ → YES なら **B**
3. その書込みは「特定1案件の蓄積／週次レビュー」か？ → YES なら **C**
4. その書込みは「永続蓄積される辞典・ライブラリ・データベース」か？ → YES なら **D**
5. どれにも該当しない場合は工藤さんに分類確認（黙って独自パターンを作らない）

### §運用ルール SSOT §1.2 命名規則（v3.1新設）

各カテゴリの命名形式を以下に統一する。

| カテゴリ | 命名形式 | 例 |
|---|---|---|
| **A. 当日フロー系** | `絵文字 + 内容 [YYYY-MM-DD]` | `🌅 モーニングブリーフ [2026-05-07]` ／ `📋 TODO確認 [2026-05-07] 16:30` ／ `🎲 アイデアシャッフル [2026-05-07]` |
| **B. 案件横断・システムログ系** | `絵文字 + 内容 [YYYY-MM-DD or YYYY-MM] (#タグ)` | `📝 [2026-05-07] #Coworkログ` ／ `📛 daily-chat-digest-2330 失敗 2026-05-07 23:30 #システムログ` ／ `🎨 [2026-05-07] #weekly-designer-trend-watch` |
| **C. 案件別蓄積系** | `絵文字 + 日付 + #タグ` | `📝 2026-05-07 #デイリーダイジェスト` ／ `📊 2026-W19 週次レビュー` |
| **D. 中長期ストック系** | ストック親は固定名／子は連番（#NNN）+ 用語名等 | 親 `📚 言葉辞典v2 ストック` 傘下に `#042 ブランド浸透率（penetration）` ／ 親 `🎨 観察デザイナー層` 傘下に `#018 Studio Dumbar（オランダ／2026-05-07追加）` |

### §運用ルール SSOT §1.3 完了マーク（complete）の取り扱い（v3.1新設）

カテゴリ別の `workflowy_complete` 扱いを以下に統一する。

| カテゴリ | complete 扱い | 理由 |
|---|---|---|
| **A. 当日フロー系** | **翌日に前日分を `workflowy_complete`** | フロー情報は当日のみ参照される。蓄積するとノイズ化（§6 重複セクション防止プロトコルの本体） |
| **B. 案件横断・システムログ系** | **残す（complete禁止）** | システム記録・横断ログは時系列で参照される必要があるため永続蓄積 |
| **C. 案件別蓄積系** | **残す（案件アーカイブ）** | 案件ノード傘下に日付付きで蓄積、状態再構成（kudo-project-state-recovery）の最優先参照ソース |
| **D. 中長期ストック系** | **永続蓄積（complete絶対禁止）** | 辞典・ライブラリ性質のため、過去エントリも常時参照対象 |

### §運用ルール SSOT §2 noteフィールド禁止

`workflowy_create` / `workflowy_update` の `note` パラメータは一切使用しない。

- 空文字列 `""` または省略
- すべての情報は子ノードの `name` フィールドに書く
- 長い内容は段落・項目ごとに子ノードを分割して階層構造で表現

### §運用ルール SSOT §3 読込先優先順位

状態再構成・案件サマリ取得などで参照する際の優先順位：

| 順位 | 参照先 | 内容 |
|---|---|---|
| ① | 「過去生成ログ」ノード（**ID: 54f53941-7c30-350f-1845-6e5a536ad348**）配下の「📝 YYYY-MM-DD #デイリーダイジェスト」ノード群 | 最高密度・構造化済み・最優先 |
| ② | 「[1日1新およびToDo]」傘下の各案件 #project ノード（§1.1 カテゴリC） | 最新の作業メモ |
| ③ | 「今日1700までに絶対更新！」セクション（§1.1 カテゴリA） | 当日のscheduled tasks出力 |
| ④ | conversation_search / recent_chats | ダイジェスト未生成日の補完 |
| ⑤ | WorkFlowy「001.MEMOる」「02.KEEPする」 | 読込のみ・書込禁止。過去メモ・人生設計・コンテンツDBの照合源 |

### §運用ルール SSOT §4 書込み前チェックリスト（毎回実行）

1. `workflowy_create` の `parent` が `8cfc1d50-7222-e2ce-79d0-8fc9faf6a6c2` またはその子孫ノードのIDであることを確認
2. `workflowy_search` でヒットしたノードに書き込む場合、そのノードが「[1日1新およびToDo]」傘下にあることを `include_ancestors` で確認
3. **§1.1の4カテゴリのいずれかに該当することを確認**（v3.1新設・どれにも該当しない場合は工藤さんに確認）
4. **§1.2の命名規則に従っていることを確認**（v3.1新設）
5. `note` パラメータが空（`""` または未指定）であることを確認
6. 同じ内容のノードが既に存在しないか確認（重複防止）
7. 上記を満たさない場合は書き込みを中止し、正しい場所・形式を再特定

### §運用ルール SSOT §5 失敗検知プロトコル

`scheduled tasks`（特に `daily-chat-digest-2330` および `daily-chat-digest-0800-backup`）の連続失敗は状態再構成の精度を直撃する。Claudeはセッション開始時に以下を確認：

1. 「[1日1新およびToDo]」直下に「📛 daily-chat-digest-* タスク失敗レポート #システムログ」ノード（§1.1 カテゴリB）があるか確認
2. 連続2日以上の失敗が確認された場合、即座に工藤さんに報告し、当日のチャット会話を手動で議事録化する代替対応を提案
3. 失敗原因の特定・恒久対策は本スキル §失敗検知プロトコル詳細（後述）に従う

### §運用ルール SSOT §6 重複セクション防止プロトコル（§1.3 連動）

カテゴリAの当日フロー系（「📂 進行中プロジェクト」「✅ 確定TODO」等）が同名セクションを日次で新規作成して過去セクションを残すと、検索ノイズが累積し、読込先優先順位②③の精度を下げる。

- カテゴリAは新規セクション作成前に、前日の同名セクションを `workflowy_complete` でcompleteマーク（§1.3）
- カテゴリB／C／Dは§1.3に従いcompleteせず残す
- 既に蓄積した重複セクションは月次棚卸し（毎月第1日曜 9:00–9:30 JST）で一括クリーンアップ

### §運用ルール SSOT §7 Cowork/Codeセッション終了時の記録ルーティン（必須）

Cowork・Codeで作業を行った場合、セッション終了前に必ず該当案件ノード（§1.1 カテゴリC）へ以下を記録：

- **何を作ったか**：成果物のファイル名・種類
- **保存先**：以下のカテゴリから選択（集中原則ガバナンス `kudo-shared-storage-protocol v1.2 §5.5` / `CLAUDE.md §3.1` 準拠）：
  - **案件横断（global・第一選択）** → `~/working/_claude_workspace_global/{reports|outputs|handoffs|master-lists}/`
  - **クライアント案件固有（特例1）** → `~/working/顧客ビジネス/{client}/_claude_workspace/03_output/`
  - **その他（要相談・特例3）** → デスクトップ / Downloads 等は要相談・原則禁止
- **要点サマリ**：提案の核となるコピー、決定事項、未決事項など
- **次のアクション**：チャット側で続けるべきこと、クライアントへの確認事項等

**目的**：Cowork/Codeの成果物と文脈はclaude.aiチャットのプロジェクトに自動同期されないため、WorkFlowyをハブとしてチャット↔Cowork間の情報断絶を防ぐ。

### §運用ルール SSOT §8 SKILL.md側のルール

本セクションを参照する全スキル・scheduled tasks・PROJECT-CLAUDE.md・個人設定は、IDやパスを実体記述せず「`kudo-workflowy-double-save §運用ルール SSOT §X`」と書くだけにとどめる。実体記述は本セクションのみ。これを破るとSSOTが崩壊する。

---

## 基本思想：三重保存アーキテクチャ

### 保存先の役割分担

| 保存先 | 役割 | 更新タイミング | アクセス経路 |
|---|---|---|---|
| **`_claude_workspace_global/`（集中原則 SSOT・v3.2 最上位追加）** | 案件横断の Claude 作業管理ファイル（HANDOFF / マスター名簿 / 完了報告 / 監査レポート / ふりかえり議事録） | Chat/Cowork/Code いずれからも書込・3 環境共通参照 | Drive 同期で全環境 |
| **Claudeメモリ** | 要点・常時参照 | Chat会話中に自動反映 | 全Chatセッションから自動参照 |
| **プロジェクトファイル（.md）** | セッション内の生成物 | Chat会話中に明示的保存 | Chatプロジェクト内から参照 |
| **WorkFlowy** | 案件別ダイジェストの蓄積 | Cowork夜間バッチで自動書き込み | 全デバイスから人間が参照 |
| **クライアント案件直下 `_claude_workspace/`** | クライアント固有の制作物（PPTX / ロゴ / KV / リサーチ） | 案件作業中（4 区分内部構造） | `~/working/顧客ビジネス/{client}/` |

**カテゴリ判定**：
- 案件横断 or Claude エコシステム自身の作業 → `_claude_workspace_global/`
- クライアント固有の制作物 → 案件直下 `_claude_workspace/`
- 詳細は `CLAUDE.md §3.2` / `kudo-context-routing §1.3 二層ワークスペース規範`

### Chat環境 vs Cowork環境の役割分担（重要）

**Chat環境（Chrome PWA）の制約**：
- WorkFlowy MCPが接続できない（ローカルstdio型のため）
- Chat側ClaudeはWorkFlowyを直接読み書きできない
- したがってWorkFlowy書き込みはCowork夜間バッチに委託する

**Cowork環境**：
- WorkFlowy MCP（workflowy_create/workflowy_search等）が完全動作
- `daily-chat-digest-2330`タスクが毎晩走り、Chat会話を案件別にWorkFlowyへ書き込む

**結論**：工藤さんはChatで自由に会話すればよい。翌朝WorkFlowyには昨日の全活動が案件別に並んでいる。

---

## 三重保存の具体的な動作

### 自動モード（通常運用）

1. **Claudeメモリ**：Chat会話中、Claudeが重要事項を自動的にメモリに反映
2. **プロジェクトファイル**：「後から見返したい」と明示した議事録は`.md`でプロジェクトに保存
3. **WorkFlowy**：毎日23:30、Cowork側タスクが自動書き込み（工藤さんは何もしなくていい）

### 手動モード（緊急時・明示指示時）

工藤さんが「**今すぐWorkFlowyに書いて**」「**議事録を残して**」と明示指示した場合：

1. Claudeが議事録を生成（フォーマットは後述）
2. プロジェクトファイルに `.md` 保存（`minutes/YYYY-MM-DD_案件名.md`）
3. WorkFlowy貼付用ブロック（コピペ可能形式）を出力
4. 「Cowork夜間バッチが23:30に拾ってWorkFlowyへ書き込みます」と伝達

---

## 議事録・ダイジェストの標準フォーマット

### 4項目構造（共通）

```
【要点】[1行サマリ]
【議論トピック】[今日何を話したか]
【決定事項】[確定した方針・コピー・構成]
【未決事項】[保留中の論点]
【次のアクション】[次にやること]
【詳細】[長めの要約または重要なやりとり]
```

### WorkFlowy上の階層構造

書込先・親IDは **本スキル §運用ルール SSOT §1（親IDロック）** および **§1.1（書込先4カテゴリ分類）** 参照。

```
▸ [1日1新およびToDo]（親ノード／§1.1 親ID）
  ▸ [案件名]（§1.1 カテゴリC）
    ▸ 📝 YYYY-MM-DD #デイリーダイジェスト（§1.2 カテゴリC命名）
      ・【要点】[1行サマリ]
      ▸ 💡 議論トピック
        ・[トピック1]
        ・[トピック2]
      ▸ ✅ 決定事項
        ・[決定1]
      ▸ 🟡 未決事項
        ・[未決1]
      ▸ 🎯 次のアクション
        ・[アクション1]
      ▸ 📖 詳細（折りたたみ）
        ・[詳細ログ]
```

**運用ルール**：
- noteフィールド扱いは **本スキル §運用ルール SSOT §2** 参照
- 日付フォーマットは `YYYY-MM-DD`
- 案件ノードが存在しない場合は新規作成（§1.1 カテゴリC直系）

---

## 案件キーワードリスト（分類用・動的）

Cowork側の `daily-chat-digest-2330` が会話を案件別に分類するために参照するリスト。

### 現状のクライアント案件

- **ミツカン**（リブランディング）
- **SNKRDUNK**（空間デザイン・提案デッキ）
- **recri**（劇場サブスクサービス）
- **TOKYOPRIME**（10周年コピー）
- **NewsPicks**
- **資生堂マキアージュ**
- **UNIQLOスポーツ / UNIQLO**
- **三菱鉛筆uniball**
- **TAXI GO**
- **伊藤忠商事**
- **ボーダレスジャパン**
- **TOHAKU**（東京国立博物館）
- **SmartNews**
- **YAMAP**
- **Text**

### 継続プロジェクト

- **多摩美MBA / 多摩美**（レクチャー「問いと添い寝する」等）
- **Ugokasu Kotoba / 書籍執筆 / 進撃の相談室**
- **MARKET / ichiba / shijo / 写真集**
- **ふげん社写真賞**
- **Lightroom / プリセット開発**

### スキル・システム開発

- **スキル開発 / スキル / SKILL**
- **ブランディング言葉辞典**
- **WorkFlowy / 同期 / ダイジェスト**

### 理論・フレームワーク

- **ブランド理論 / 記憶の箱 / 版木**
- **Ehrenberg-Bass / 森岡毅**
- **家族的類似性 / ヴィトゲンシュタイン**

### 分類不能時

- マッチしなければ **「その他」ノード** に一括格納

### リスト更新ルール

- 新しい案件名が会話に頻出したら、Cowork側タスクが自動で追記候補を検出
- 追記は本スキルの本リスト更新として行う
- 工藤さんの明示承認を経てから追記確定
- **表記揺れの統一は `kudo-naming-unification-protocol` に委任**（責務分離）

---

## 冪等性・重複防止

### WorkFlowy側の重複チェック

`daily-chat-digest-2330` は書き込み前に以下を確認：
- 該当案件ノードに、同日の「📝 YYYY-MM-DD #デイリーダイジェスト」が既に存在するか
- 存在すればスキップ（バックアップタスク`0800`が後で走る場合も同様）

### バックアップタスクの役割

- **プライマリ**：`daily-chat-digest-2330`（毎日23:30）
- **バックアップ**：`daily-chat-digest-0800-backup`（翌朝08:00）
- プライマリが失敗した場合にバックアップが埋める
- 既にノードがあればスキップ

### セクション重複防止

詳細運用は **本スキル §運用ルール SSOT §6（重複セクション防止プロトコル）** および **§1.3（complete扱い）** を参照。カテゴリA以外はcompleteしない。

---

## 失敗検知プロトコル詳細（v2.1新設・v3.0で SSOT §5 と統合）

### なぜ必要か

`daily-chat-digest-2330` および `daily-chat-digest-0800-backup` の両方が失敗すると、その日のチャット会話がWorkFlowyに書き込まれず、`kudo-project-state-recovery` の「最優先参照ソース」が空欄のまま放置される。状態再構成精度に直撃する。

2026-04-26時点で、4/25・4/26の両日のdaily-chat-digest-2330が連続失敗し、08:00バックアップも失敗していたことが判明。失敗を即時検知できず、状態再構成時に古いダイジェストしか拾えない事態が発生した。本プロトコルはこの再発を防ぐ。

### 失敗検知の自動化フロー

**Step 1：セッション開始時の自動チェック（§運用ルール SSOT §5と連動）**

Claudeはセッション開始時、以下のいずれかが「[1日1新およびToDo]」直下（§1.1 カテゴリB）に存在するか確認：

- `📛 daily-chat-digest-* タスク失敗レポート #システムログ`
- `📛 daily-chat-digest-*-backup も失敗 #システムログ`

存在する場合は工藤さんに即報告。

**Step 2：連続失敗の判定**

- 1日の失敗：注意レベル（ログ参照を促す）
- 2日連続の失敗：警告レベル（手動議事録化を提案）
- 3日連続の失敗：緊急レベル（scheduled task の prompt／実行ログ点検を最優先タスクとして提案）

**Step 3：手動補完オプションの提示**

連続失敗が確認された場合、Claudeから以下を提案：

```
daily-chat-digest-2330 が連続失敗しています。
当日のチャット会話を手動で議事録化しますか？
- A：今のセッションだけ手動議事録化
- B：過去N日分まとめて手動議事録化
- C：scheduled task の故障原因を先に特定
```

**Step 4：故障原因の特定（半自動化）**

工藤さんが C を選んだ場合、Claudeは以下を順に確認：

1. `mcp__scheduled-tasks__list_scheduled_tasks` でlastRunAtを確認
2. lastRunAtが当日範囲内なら「実行はされたが処理失敗」、範囲外なら「実行されなかった」と判定
3. 実行されたケース → エラーログ（Cowork側）を取得
4. 実行されなかったケース → cron設定・タスクenable状態を確認
5. 結果を工藤さんに報告し、必要なら scheduled-tasks の prompt 修正案を提示

### 故障再発防止のチェックリスト

- daily-chat-digest-2330 の prompt に「失敗時にエラー詳細を `📛 ... #システムログ` ノードへ自動書き込む」処理が含まれているか
- バックアップタスク（08:00）が独立して動作するか（プライマリと同じトリガー条件で連鎖失敗していないか）
- WorkFlowy MCP接続が安定しているか（401/429エラーが頻発していないか）

### 違反時の挙動

セッション開始時に失敗検知ステップを通さず通常会話に進むのは禁止。検知結果を工藤さんに伝えてから本題に入る。

---

## 関連スキル・タスクとの関係

### kudo-project-state-recovery との連携

- `kudo-project-state-recovery` v1.4 の「状態再構成」において、**まずWorkFlowy上のダイジェストを優先参照**する
- 読込先優先順位の詳細は **本スキル §運用ルール SSOT §3** が一次ソース
- 状態再構成のたびに本スキルの失敗検知プロトコルを並走させる

### kudo-context-routing との連携

- `kudo-context-routing` v1.0 が新規案件の経路設計を担う
- 新規案件発足時、本スキル §運用ルール SSOT §1（親IDロック）＋§1.1（カテゴリC：案件別蓄積系）に従って #project ノードを作成
- 案件キーワードリストへの追記は本スキルが管理

### kudo-naming-unification-protocol との連携

- 案件キーワードリスト内の表記揺れ統一は同スキルに委任（責務分離原則）

### kudo-sync-cycle の扱い

- `kudo-sync-cycle` v1.0 は本スキルに完全吸収されており、**2026-04-26で完全削除指示**を発行済み

### Coworkタスク群との連携（v3.1で§1.1カテゴリ表示追加）

- `morning-briefing-0500`（カテゴリA）：起動時に昨日のダイジェストを読み込む
- `morning-briefing-0700-backup`（カテゴリB）：同上
- `daily-todo-alert-1630`（カテゴリA）：朝のブリーフとの差分をアラート化
- `weekly-review-sunday-2100`（カテゴリC）：ダイジェストを素材に週次総括を生成
- `idea-shuffle-mon-wed-fri`（カテゴリA）：最近の議論アイデアを優先的にシャッフル
- `daily-chat-digest-2330`（カテゴリB）／`daily-chat-digest-0800-backup`（カテゴリB）：失敗検知プロトコルの対象
- `branding-dictionary-daily`（カテゴリD本体＋カテゴリAログ）：辞典蓄積＋当日生成ログ
- `weekly-designer-trend-watch`（カテゴリB巡回ログ＋カテゴリD観察層）：巡回記録＋蓄積ライブラリ
- `monthly-expense-collector`（カテゴリA）／`monthly-expense-midcheck`（カテゴリB）：月次経費

---

## Chat側スキル起動時の挙動

### トリガー時の確認事項

工藤さんが明示的にトリガーした場合、以下を順に確認：

1. **何を残すか**：今のセッション全体の議事録か、特定トピックの議事録か
2. **どの案件に紐づくか**：自動分類か、工藤さんが指定するか
3. **どこに書くか**：プロジェクトファイルだけか、WorkFlowyにも流すか（ただしWorkFlowy書き込みはCowork経由）
4. **§1.1 のどのカテゴリか**：A／B／C／D いずれかを判定（v3.1新設）

### 議事録生成の手順

```
Step 1: 会話全体をレビューし、4項目（議論トピック・決定事項・未決事項・次のアクション）を抽出
Step 2: 案件分類（自動または工藤さん指定）
Step 3: §1.1 カテゴリ判定（基本はカテゴリC：案件別蓄積系）
Step 4: プロジェクトファイルに .md 保存：
        minutes/YYYY-MM-DD_案件名.md
Step 5: WorkFlowy貼付用ブロックを出力（コピペ可能形式、明示指示時のみ）
Step 6: 「Cowork夜間バッチ（23:30）が自動でWorkFlowyに書き込みます」と伝達
```

### 出力フォーマット例

```markdown
# 議事録: [案件名] (YYYY-MM-DD)

## 要点
[1行サマリ]

## 議論トピック
- [トピック1]
- [トピック2]

## 決定事項
- [決定1]

## 未決事項
- [未決1]

## 次のアクション
- [アクション1]

## 詳細
[詳細ログまたは長めの要約]
```

---

## 禁止事項

- **WorkFlowyの書込先・noteフィールド扱い・カテゴリ分類に関するルールは本スキル §運用ルール SSOT が一次ソース**。本スキル外のいかなる場所にも重複記述しないこと（ハードコード禁止原則）
- **Chat環境から直接WorkFlowy書き込みを試みないこと。** 動かないため、プロジェクトファイル＋Cowork委託が正解
- **「なるはや同期」の強迫観念を持たないこと。** 確定事項だけを書き出すフィルターが最重要
- **失敗検知ステップを飛ばすこと。** セッション開始時に必ず実行
- **§1.1 4カテゴリのいずれにも該当しない独自パターンを黙って作ること（v3.1新設）。** 必ず工藤さんに分類確認

---

## 運用上の原則

### 「任せる」設計

工藤さんは本スキルを意識しなくていい。
- Chatで自由に会話
- 明示指示なくても、Claudeがメモリに要点を反映
- 23:30にCoworkが勝手にWorkFlowy書き込み
- 翌朝WorkFlowyには昨日の全活動が並ぶ

ただし**失敗検知だけは工藤さんに自動報告**する（v2.1新設）。

### 情報量の調整

- 雑談や確定していない壁打ちも**詳細ノード**には残す
- 要点だけ見たい時は折りたたみ状態で見る（WorkFlowyネイティブ機能）
- 重要な決定は**【決定事項】**ノードに明示される

### 案件分類の継続改善

- 新案件が頻出したら案件キーワードリストに追記
- 分類精度に不満があれば、`idea-shuffle-mon-wed-fri`のログで誤分類を検出
- 本スキル自体を四半期ごとに見直す

---

## 更新履歴

- **v3.2（2026-05-15・集中原則ガバナンス Phase 3 Part B-6）**：§運用ルール SSOT §7「Cowork/Codeセッション終了時の記録ルーティン」の「保存先」項目を集中原則 3 分岐版に改訂（global / 案件直下 / 要相談）。基本思想「保存先の役割分担」表に **`_claude_workspace_global/`（最上位カテゴリ）** と **クライアント案件直下 `_claude_workspace/`** の 2 行を追加。カテゴリ判定ガイドを表末尾に新設し `CLAUDE.md §3.2` / `kudo-context-routing §1.3 二層ワークスペース規範` を参照。Phase 2 grep 監査 Pattern 5（保存先キーワード 3 hits）の解消。

- **v3.1（2026-05-07）**：**§1.1 書込先4カテゴリ分類／§1.2 命名規則／§1.3 complete扱い を新設**。scheduled-tasks 16本の書込先実装監査の結果、「[1日1新およびToDo]傘下のどこに置くか」のサブルールが暗黙化していた問題を解決。A.当日フロー系／B.案件横断・システムログ系／C.案件別蓄積系／D.中長期ストック系の4カテゴリで完全規定し、現状の全タスク実装が変更不要のまま整合する形でSSOTを拡張。§4 書込み前チェックリストにカテゴリ判定・命名規則確認を追加（5→7項目）。§6 重複セクション防止を§1.3 complete扱いと連動化。§関連スキル・タスクとの関係に各タスクの§1.1カテゴリ表示を追加。kudo-persist-settings v3.3 と同時改訂（旧 CLAUDE.md §4 参照を全廃しSSOT参照に統一）。
- **v3.0（2026-04-27）**：**SSOT再配置の一環として、本スキルがWorkFlowy統合運用ルールの一次ソース（SSOT）に昇格**。個人設定 項目14（旧CLAUDE.md §4）から本体プロトコル7サブセクションを完全移植し、§運用ルール SSOT を新設。すべての関連スキル・scheduled tasks・PROJECT-CLAUDE.md・個人設定は本セクションを参照ポインタで指す。本スキル外でのID・パス重複記述を禁止。番号変更耐性のため「kudo-workflowy-double-save §運用ルール SSOT §X」形式の参照を標準化。kudo-context-routing との連携を追加。案件キーワードリストにミツカン・TOHAKU・SmartNews・YAMAP・Textを追加（2026-04-27の命名統一実践を反映）。
- **v2.1（2026-04-26）**：§失敗検知プロトコル新設（daily-chat-digest連続失敗の自動検知）／ハードコード除去（書込先ID・禁止ノード名の実体記述を削除しCLAUDE.md §4参照に統一）／kudo-persist-settings v2.0 のハードコード禁止原則に準拠／kudo-project-state-recovery v1.4 と連携明示／kudo-sync-cycle 完全削除指示と連動。
- **v2.0（2026-04-18）**：旧 `kudo-sync-cycle` v1.0を完全吸収／三重保存アーキテクチャを確立／Cowork夜間バッチ（`daily-chat-digest-2330`）との連携を前提化／案件キーワードリストを初期整備／`kudo-project-state-recovery` との連携を明文化。
- **v1.0**（旧 `kudo-sync-cycle`）：廃止。

A-2. `kudo-context-routing`¶

役割：案件文脈 4 経路ルーティング・_claude_workspace 規律

メタ情報¶

パス：~/KUDO-Vault/.claude/skills/kudo/kudo-context-routing/SKILL.md
サイズ：17529 bytes / 274 行
frontmatter 行数：4 行
本文セクション数（## / ###）：24
同梱ファイル：なし（SKILL.md 単一構成）

frontmatter 抜粋¶

---
name: kudo-context-routing
description: "工藤拓真の案件文脈を、claude.aiプロジェクト・WorkFlowy・Cowork・スキルの4経路で立ち上げ連動させ、案件フォルダ直下「_claude_workspace」で中間素材を一元管理するSSOT。動詞群5（Skillを管理する）所属。「クライアント名」を全経路統一し、案件フォルダ直下「_claude_workspace」（01_input/02_work/03_output/99_archive）を立て、1キーワードで全経路ハブ連動＋全素材一箇所集約する設計。「ミツカン案件で〜」のように案件名が出た瞬間にトリガー。「コンテキスト立ち上げて」「経路マップ確認」「PROJECT-CLAUDE.md作って」「経路選択どうする？」「単発か継続か」「Coworkでフォルダmount」「クライアント別フォルダ」「コンテキスト切り替え」「新規クライアント立ち上げ」「過去案件の状態再構成」「Claude作業フォルダ」「_claude_workspace」「中間素材どこに置く」「成果物どこに保存」「素材が散らかる」「chat outputsをどこに配置」「Codeとchatの作業フォルダ」「Downloadsから整理」「ファイル管理規律」などでトリガー。kudo-naming-unification-protocolと並走関係で、本スキルは「経路設計＋作業フォルダ規律」、向こうは「揃える作業」と責務分離。命名規則・4経路役割分担・経路選択ルール・自走判定・禁止事項・「_claude_workspace」配置確認プロトコルを内蔵。v1.1（2026-05-07）でPROJECT-CLAUDE.md確認プロトコル新設。v1.2（2026-05-07）で「_claude_workspace」作業フォルダ規律SSOT（命名・配置・4区分内部構造・確認プロトコル・chat↔ローカル↔Code3点接続）を新設。"
---

本文セクション構造¶

L   8: ## このスキルの位置付け
L  20: ## 命名規則の統一ルール（核心）
L  37: ## 4経路の役割分担
L  48: ## 経路選択ルール（4段階）
L  65: ## 自走判定（Claudeの動作）
L  67: ### 起動時の自動チェック
L  75: ### Cowork mount時の挙動
L  85: ### 表記揺れ検出時
L  94: ## 禁止事項
L 103: ## Claude作業フォルダ規律 SSOT（v1.2新設）
L 105: ### 原則
L 110: ### 命名と配置
L 120: ### 内部構造（4区分）
L 138: ### 配置確認プロトコル（着手前必須）
L 161: ### chat ↔ ローカル ↔ Code Claude の3点接続
L 179: ### 既存案件への適用
L 188: ### 反原則（避けるべきパターン）
L 197: ### 連動する他スキル
L 207: ## PROJECT-CLAUDE.md の配置原則
L 220: ## 新規案件発足時のチェックリスト
L 235: ## 既存案件の状態再構成プロトコル
L 249: ## 関連スキル・ファイル
L 258: ## 起動条件（トリガー例）
L 269: ## 更新履歴

SKILL.md 全文（verbatim）¶

---
name: kudo-context-routing
description: "工藤拓真の案件文脈を、claude.aiプロジェクト・WorkFlowy・Cowork・スキルの4経路で立ち上げ連動させ、案件フォルダ直下「_claude_workspace」で中間素材を一元管理するSSOT。動詞群5（Skillを管理する）所属。「クライアント名」を全経路統一し、案件フォルダ直下「_claude_workspace」（01_input/02_work/03_output/99_archive）を立て、1キーワードで全経路ハブ連動＋全素材一箇所集約する設計。「ミツカン案件で〜」のように案件名が出た瞬間にトリガー。「コンテキスト立ち上げて」「経路マップ確認」「PROJECT-CLAUDE.md作って」「経路選択どうする？」「単発か継続か」「Coworkでフォルダmount」「クライアント別フォルダ」「コンテキスト切り替え」「新規クライアント立ち上げ」「過去案件の状態再構成」「Claude作業フォルダ」「_claude_workspace」「中間素材どこに置く」「成果物どこに保存」「素材が散らかる」「chat outputsをどこに配置」「Codeとchatの作業フォルダ」「Downloadsから整理」「ファイル管理規律」などでトリガー。kudo-naming-unification-protocolと並走関係で、本スキルは「経路設計＋作業フォルダ規律」、向こうは「揃える作業」と責務分離。命名規則・4経路役割分担・経路選択ルール・自走判定・禁止事項・「_claude_workspace」配置確認プロトコルを内蔵。v1.1（2026-05-07）でPROJECT-CLAUDE.md確認プロトコル新設。v1.2（2026-05-07）で「_claude_workspace」作業フォルダ規律SSOT（命名・配置・4区分内部構造・確認プロトコル・chat↔ローカル↔Code3点接続）を新設。"
---

# kudo-context-routing v1.2

## このスキルの位置付け

工藤拓真の案件は、**claude.aiプロジェクト・WorkFlowy・Cowork・スキル**の4経路で文脈を立ち上げる。「クライアント名」を全経路で統一することで、1つのキーワードがハブとなって全経路を連動させる設計。動詞群5（Skillを管理する）所属、SSOT（Single Source of Truth）スキル。

**責務分離**：
- 本スキル `kudo-context-routing`：**経路設計**（どう呼び出すか・どう連動させるか）
- 並走スキル `kudo-naming-unification-protocol`：**揃える作業**（既存の表記揺れを検出・統一する実装）

両スキルは協調する。新規案件発足時はまず本スキルで命名規則を決定し、既存案件で揺れが見つかった時は naming-unification を起動する。

---

## 命名規則の統一ルール（核心）

1つの案件には1つの統一名を割り当て、全経路で揃える：

| 経路 | 命名形式 | 例（ミツカン案件） |
|---|---|---|
| claude.aiプロジェクト名 | クライアント正式名 | 「ミツカン」 |
| OneDriveフォルダ名 | working/顧客ビジネス/[クライアント名]/ | working/顧客ビジネス/ミツカン/ |
| WorkFlowy #project ノード名 | [クライアント名] #project | 「ミツカン #project」 |
| PROJECT-CLAUDE.md（必要時） | 上記OneDriveフォルダ内に配置 | working/顧客ビジネス/ミツカン/PROJECT-CLAUDE.md |
| スキル名（複雑案件のみ） | kudo-[小文字英語名]-context | kudo-mitsukan-context |
| **Claude作業フォルダ（v1.2新設）** | working/顧客ビジネス/[クライアント名]/_claude_workspace/ | working/顧客ビジネス/ミツカン/_claude_workspace/ |

→ **「ミツカン」というキーワード1つで、全経路がハブ的に連動**。Claudeはその名前を聞いた瞬間に4経路すべての文脈を立ち上げられる。

---

## 4経路の役割分担

| 経路 | 役割 | 主な内容 |
|---|---|---|
| **主経路：claude.aiプロジェクト** | カスタム指示＋知識ファイル＋過去会話履歴の自動参照 | チャット主体の戦略議論・コピー開発の本拠地 |
| **進捗管理：WorkFlowy #project ノード** | 「[1日1新およびToDo]」傘下の各案件ノード | 決定事項・次アクション・daily-chat-digestの要点蓄積 |
| **Cowork補助：PROJECT-CLAUDE.md** | フォルダmount時に静的コンテキスト自動展開 | プロジェクト固有のディレクトリ構成・命名規則・運用ルール |
| **複雑案件：スキル化** | フレームワーク化済み案件のみ | kudo-XX-context として methodologyを内蔵 |

---

## 経路選択ルール（4段階）

| 案件の性質 | 必要な経路 |
|---|---|
| 単発・軽量（取材・短期相談等） | WorkFlowy #project だけ |
| 中量・継続（チャット主体／戦略議論・コピー開発） | claude.aiプロジェクト ＋ WorkFlowy #project |
| 中量・継続（Cowork作業発生／提案資料・PPTX生成） | claude.aiプロジェクト ＋ WorkFlowy #project ＋ PROJECT-CLAUDE.md |
| 体系化済み複雑案件（特定の方法論が確立した案件のみ） | 全経路 ＋ スキル化（kudo-XX-context） |

**判断軸**：
- チャットだけで完結する → WorkFlowyのみ
- ファイル成果物が発生する → claude.aiプロジェクト追加
- 同じフォルダに複数回mountする → PROJECT-CLAUDE.md追加
- 方法論が固まり横展開可能 → スキル化

---

## 自走判定（Claudeの動作）

### 起動時の自動チェック

会話で案件名（「ミツカン」「TOHAKU」等）が出た瞬間：

1. WorkFlowy「[1日1新およびToDo]」傘下に該当 #project ノードがあるか確認
2. あれば最新状態を読込（kudo-workflowy-double-save §運用ルール SSOT 参照）
3. なければ「新規案件として #project ノードを作成しますか？」と提案

### Cowork mount時の挙動

クライアントフォルダがmountされた瞬間：

1. フォルダ直下の `PROJECT-CLAUDE.md` の存在を確認
2. **あれば**：自動Read → 静的コンテキスト展開
3. **なければ**：「`PROJECT-CLAUDE.md` を作成しますか？」と提案
   - 工藤さん承認後、`claude-reference/02_templates/PROJECT-CLAUDE-TEMPLATE.md` を雛形として自走作成
   - 自走レベル：**要事前承認**（個人設定 自走原則の「要事前承認」レベル）

### 表記揺れ検出時

会話やファイル名・フォルダ名で表記揺れ（「ミツカン」と「mizkan」混在等）を発見した瞬間：

1. 即座に工藤さんに統一を提案
2. 統一実行は `kudo-naming-unification-protocol` に委任（責務分離原則）

---

## 禁止事項

- **105社全展開は禁止**：必要が発生した案件のみ作成（先回り展開を避ける）
- **クライアント名の表記揺れ禁止**：案件発足時に1つに決める
- **WorkFlowy #project ノード名と他経路の名称がズレた状態を放置しない**
- **PROJECT-CLAUDE.mdをチャット主体案件で作るのは過剰**：Cowork作業が発生する案件のみ作成

---

## Claude作業フォルダ規律 SSOT（v1.2新設）

### 原則
**Claudeに作業を依頼してファイル成果物が発生するすべての案件で、案件フォルダ直下に `_claude_workspace` を立てる。**

claude.aiのoutputs、Cowork、Code Claude の各環境で生成される中間素材・最終成果物・引き継ぎ書類を一箇所に集約することで、Downloadsフォルダやデスクトップへの散乱を防ぐ。

### 命名と配置

| 項目 | 規則 |
|---|---|
| **フォルダ名** | `_claude_workspace`（アンダースコア先頭・英小文字・全Finderソートで上位に表示） |
| **配置場所** | クライアント別プロジェクトフォルダ**直下** |
| **絶対パス例** | `working/顧客ビジネス/ミツカン/_claude_workspace/` |
| **適用範囲** | ファイル成果物が発生するすべての作業（PPTX/HTML/SVG/MD/画像/PDF/コード生成） |
| **対象外** | チャット内で完結する戦略相談・短時間の壁打ち |

### 内部構造（4区分）

```
_claude_workspace/
├── 01_input/        # 元データ・参考資料・受領素材・クライアント提供物
├── 02_work/         # 作業中・中間素材・生成スクリプト・HANDOFF.md
├── 03_output/       # 最終納品物（クライアント提出版）
└── 99_archive/      # 過去版・参考保管・没案
```

**番号prefix（01/02/03/99）**でFinderソート順を制御。`99_archive` は意図的に末尾に。

**配置の原則**：
- HANDOFF.md は `02_work/HANDOFF.md` に配置（kudo-cowork-code-handoff-protocol §13と整合）
- 中間PNG・JSON・スクリプト類は `02_work/` 直下または用途別サブフォルダ
- 最終納品PPTX/PDFは `03_output/` のみに置く（迷子防止）
- 古いバージョンは消さず `99_archive/` に退避（取り返しがつくように）

### 配置確認プロトコル（着手前必須）

新規案件・既存案件問わず、ファイル生成作業に着手する前に必ず実行：

```
Step 1: 案件名からクライアント別プロジェクトフォルダを探索
   → working/顧客ビジネス/[クライアント名]/ が存在するか確認

Step 2: 既存プロジェクトフォルダが見つからない場合
   → ユーザーに以下を確認：
     - 「[クライアント名] のプロジェクトフォルダは既存ですか？場所を教えてください」
     - もしくは「新規に working/顧客ビジネス/[クライアント名]/ を立てますか？」

Step 3: プロジェクトフォルダ確定後、`_claude_workspace` の存在確認
   → なければ新規作成（4サブフォルダも同時作成）

Step 4: 着手前にユーザー最終確認
   → 「以下のフォルダで作業を進めます：[絶対パス]。よろしいですか？」
   → 承認後、ファイル生成開始
```

**自走レベル**：要事前承認（個人設定 自走原則の「要事前承認」レベル）。Step 4 の最終確認を必ず取る。

### chat ↔ ローカル ↔ Code Claude の3点接続

3つの環境を同じ作業フォルダで橋渡しする：

```
[chat outputs（claude.ai）]
   ↓ ファイルダウンロード
[Google Drive / クライアント名 / _claude_workspace / 02_work/]
   ↓ Finderで開く / Terminalでcd
[Code Claude 作業ディレクトリ（同一パス）]
```

**運用ルール**：
- chat側で生成したファイルは、ダウンロード後すぐに `02_work/` に配置（Downloadsに放置しない）
- Code Claude起動時は必ず `cd _claude_workspace/02_work/` してから作業開始
- chat→Code連携時、HANDOFF.md は `02_work/HANDOFF.md` に置き、Code Claude にこのパスを伝える
- ファイルの二重保存・二重編集を回避

### 既存案件への適用

既存のクライアントプロジェクトフォルダで `_claude_workspace` がない場合：

1. ユーザーに新設提案：「`_claude_workspace` を新設しますか？既存ファイルは触りません」
2. 承認後、空の `_claude_workspace/` を新設（4サブフォルダ含む）
3. 既存ファイルは現状維持。新規作業から `_claude_workspace` 内で進める
4. 必要に応じて、既存ファイルを `01_input/` にコピー（移動ではなくコピーで安全運用）

### 反原則（避けるべきパターン）

- ❌ Mac の `~/Downloads/` に成果物を放置
- ❌ デスクトップに置きっぱなし
- ❌ クライアントフォルダの色んな階層に作業フォルダを散らす
- ❌ 案件をまたいで素材を混ぜる（ミツカン素材の中にTOHAKUのHTMLが紛れる等）
- ❌ `_claude_workspace` の中をさらに無秩序にサブフォルダ化（4区分以上に増やさない）
- ❌ 中間素材を `03_output/` に置く（クライアント提出版だけのフォルダ）

### 連動する他スキル

- `kudo-cowork-code-handoff-protocol §13`：HANDOFF.md は `_claude_workspace/02_work/HANDOFF.md` に配置
- `kudo-proposal-deck`：PPTX生成中の素材は `_claude_workspace/02_work/` で完結、最終納品は `03_output/`
- `kudo-client-template-factory`：.potx生成物は `02_work/` または `03_output/`（用途による）
- `kudo-design-generation-loop`：ロゴ・KV・モック画像生成も `_claude_workspace/` 内で完結
- `kudo-persist-settings §自走原則 SSOT`：本プロトコルの自走レベル「要事前承認」の判断ロジックは個人設定14のSSOT参照

---

## PROJECT-CLAUDE.md の配置原則

- **配置場所**：上記OneDriveフォルダ内の直下（サブフォルダに置かない）
- **編集ルール**：グローバルで定義済みの内容（言語・応答スタイル・WorkFlowy統合・デザインルール等）は本ファイルに重複記述しない（ハードコード禁止原則）
- **役割**：プロジェクト固有指示書のみ記載
  - 案件の概要・主要ステークホルダー
  - フォルダ構成
  - 案件特有の運用ルール
  - 関連する WorkFlowy ノードID
  - 関連スキル名

---

## 新規案件発足時のチェックリスト

新しいクライアント案件が始まった瞬間に必ず通す：

1. [ ] クライアント正式名を決定（公式表記・ロゴ表記準拠）
2. [ ] 命名規則の統一ルール（上記の表）に従って4経路の名前を確定
3. [ ] WorkFlowy「[1日1新およびToDo]」傘下に「[クライアント名] #project」ノード作成
4. [ ] OneDriveに `working/顧客ビジネス/[クライアント名]/` フォルダ作成
5. [ ] **クライアントフォルダ直下に `_claude_workspace/` を作成（01_input/02_work/03_output/99_archive の4サブフォルダ含む）**（v1.2新設）
6. [ ] 経路選択ルール（4段階）に基づき、必要な経路を判定
7. [ ] Cowork作業が発生する見込みなら PROJECT-CLAUDE.md を作成
8. [ ] 体系化が見えたらスキル化を検討

---

## 既存案件の状態再構成プロトコル

過去のセッションを引き継ぐ場合、以下の優先順位で読込：

1. **WorkFlowy「過去生成ログ」配下のデイリーダイジェスト**（最高密度・構造化済み）
2. **WorkFlowy「[1日1新およびToDo]」傘下の #project ノード**（最新作業メモ）
3. **claude.aiプロジェクトの過去会話履歴**（チャット主体案件）
4. **PROJECT-CLAUDE.md**（Cowork mount時に自動展開）
5. **conversation_search / recent_chats**（補完）

詳細は `kudo-workflowy-double-save §運用ルール SSOT §読込先優先順位` 参照。

---

## 関連スキル・ファイル

- **kudo-naming-unification-protocol**：表記揺れの検出・統一実装（並走関係）
- **kudo-workflowy-double-save**：WorkFlowy統合運用ルール SSOT（本スキルから書込み・読込みルールを参照）
- **kudo-persist-settings**：自走原則の運用詳細（本スキルの自走判定の判断ロジック本体）
- **claude-reference/02_templates/PROJECT-CLAUDE-TEMPLATE.md**：新規案件用テンプレ（PROJECT-CLAUDE.mdの雛形）

---

## 起動条件（トリガー例）

- 案件名が会話に登場（「ミツカン案件で〜」「TOHAKUどうなった？」等）
- 「コンテキスト立ち上げて」「経路マップ確認」「PROJECT-CLAUDE.md作って」「PROJECT-CLAUDE.mdある？」
- 「経路選択どうする？」「単発か継続か」「Coworkでフォルダmount」
- 「新規クライアント立ち上げ」「案件発足時の命名規則決定」
- 「過去案件の状態再構成」「セッション引き継ぎ」
- Cowork mount時に自動チェック発動

---

## 更新履歴

- **v1.0（2026-04-27）**：初版。個人設定 項目17（クライアント別コンテキスト呼出経路マップ）の本体を独立スキル化。SSOT再配置の一環として、個人設定からプロトコル本体を切り出し。kudo-naming-unification-protocol との責務分離を明示（経路設計 vs 揃える作業）。新規案件発足時のチェックリスト7項目、既存案件の状態再構成プロトコル5段階を新規追加。
- **v1.1（2026-05-07）**：PROJECT-CLAUDE.md確認プロトコル（起動時自動チェック→テンプレ生成→ヒアリング→配置の5ステップ）を§自走判定 §Cowork mount時の挙動 に内包。
- **v1.2（2026-05-07）**：「_claude_workspace」作業フォルダ規律SSOTを新設（§Claude作業フォルダ規律 SSOT）。Chat→Code連携時のPPTX精緻化案件（問い読リブランディング 2026-05-07）で、chat outputsとローカルダウンロード先とCode作業ディレクトリの3点接続が散らかる問題が露呈したことを起点に構造化。命名（_claude_workspace）・配置（クライアントフォルダ直下）・4区分内部構造（01_input/02_work/03_output/99_archive）・配置確認プロトコル（毎回必須・要事前承認）・3点接続規律を完全内蔵。kudo-cowork-code-handoff-protocol §13（HANDOFF配置先）と連動し、HANDOFF.mdは `_claude_workspace/02_work/HANDOFF.md` に置く統一規則。

A-3. `kudo-shared-storage-protocol`¶

役割：集中原則ガバナンス・3 環境共通ストレージ

メタ情報¶

パス：~/KUDO-Vault/.claude/skills/kudo/kudo-shared-storage-protocol/SKILL.md
サイズ：18344 bytes / 357 行
frontmatter 行数：6 行
本文セクション数（## / ###）：35
同梱ファイル：なし（SKILL.md 単一構成）

frontmatter 抜粋¶

---
name: kudo-shared-storage-protocol
description: v1.2（2026-05-15）§5.5 集中原則ガバナンス新設—すべてのClaude関連生成物は原則 _claude_workspace_global/ 配下、特例は工藤に相談必須、違反禁止リスト・既存SKILL波及計画を内蔵。「DLしたくない」「3環境共通で見たい」「Drive を SSOT に」「マスター名簿を Drive 配置」「HANDOFF を Drive 経由で」「Chat Cowork Code 共通参照」「ファイル共有環境」「latest symlink できない」「Drive MCP の制約」「Drive_claude_shared」「生成物どこに置く」「集中原則」「特例配置」「相談プロトコル」など、3 環境間のファイル共有と生成物配置の集中が必要なすべての場面でトリガー。2026-05-15 命名統一プロジェクト完走時、工藤さんの問いを起点に新設。フォルダ作成と README 配置を Chat MCP で実機検証済（フォルダID 1EXyQOuWn2tvaBqBnhyeIhAH7Gox3jMsF）。kudo-cowork-code-handoff-protocol §16-3 と双方向参照。
verb_group: 5
parent: null
---

本文セクション構造¶

L  10: ## §1 目的・核心思想
L  23: ## §2 起動トリガー
L  25: ### 直接トリガー
L  32: ### 状況トリガー
L  39: ## §3 フォルダ構造（_claude_workspace_global/）
L  41: ### 3-1. 標準構造
L  61: ### 3-2. フォルダ ID マップ（2026-05-15 確定）
L  74: ### 3-3. ID 一覧の永続化
L  80: ## §4 各環境からのアクセス方法
L  82: ### 4-1. Chat（claude.ai）
L 114: ### 4-2. Code（ローカル Mac）
L 131: ### 4-3. Cowork
L 144: ## §5 新規バージョン主義とバージョン管理
L 146: ### 5-1. 原則
L 153: ### 5-2. 最新版の判定
L 174: ### 5-3. LATEST.txt（オプション）
L 183: ### 5-4. シンプル運用（推奨）
L 189: ## §5.5 集中原則ガバナンス（v1.2 新設・2026-05-15）
L 191: ### 5.5-1. 集中原則の宣言
L 195: ### 5.5-2. 対象となる生成物
L 204: ### 5.5-3. 例外（特例配置）と相談プロトコル
L 218: ### 5.5-4. 違反禁止リスト
L 230: ### 5.5-5. 既存 SKILL 群への波及（移行計画）
L 242: ### 5.5-6. 違反検出の自動化候補（将来）
L 247: ### 5.5-7. 工藤さんへの相談時のテンプレ
L 258: ## §6 各環境の権限非対称性（Entry #10 と整合）
L 270: ## §7 機密の扱い
L 283: ## §8 移行プロセス（命名統一プロジェクトでの実証）
L 285: ### Phase 1: フォルダ構造作成（完了・2026-05-15）
L 289: ### Phase 2: 既存ファイルの Drive 移行（今後）
L 294: ### Phase 3: 運用への組み込み
L 299: ### Phase 4: latest 機構の確立
L 305: ## §9 関連スキル
L 316: ## §10 アンカー ID（kudo-skill-cross-reference-resolver 準拠）
L 332: ## §11 改訂履歴

SKILL.md 全文（verbatim）¶

---
name: kudo-shared-storage-protocol
description: v1.2（2026-05-15）§5.5 集中原則ガバナンス新設—すべてのClaude関連生成物は原則 _claude_workspace_global/ 配下、特例は工藤に相談必須、違反禁止リスト・既存SKILL波及計画を内蔵。「DLしたくない」「3環境共通で見たい」「Drive を SSOT に」「マスター名簿を Drive 配置」「HANDOFF を Drive 経由で」「Chat Cowork Code 共通参照」「ファイル共有環境」「latest symlink できない」「Drive MCP の制約」「Drive_claude_shared」「生成物どこに置く」「集中原則」「特例配置」「相談プロトコル」など、3 環境間のファイル共有と生成物配置の集中が必要なすべての場面でトリガー。2026-05-15 命名統一プロジェクト完走時、工藤さんの問いを起点に新設。フォルダ作成と README 配置を Chat MCP で実機検証済（フォルダID 1EXyQOuWn2tvaBqBnhyeIhAH7Gox3jMsF）。kudo-cowork-code-handoff-protocol §16-3 と双方向参照。
verb_group: 5
parent: null
---

# kudo-shared-storage-protocol v1.0

## §1 目的・核心思想

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

- ユーザーが Chat 出力ファイルを毎回手動 DL する手間を削減
- Cowork / Code が前のセッションの出力を直接参照できる
- マスター名簿・HANDOFF・完了報告等を一元管理
- バージョン管理を Drive のネイティブ機能で行う

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

---

## §2 起動トリガー

### 直接トリガー
- 「DL したくない」「毎回 DL するのは面倒」
- 「3環境共通で見たい」「Chat / Cowork / Code 共通参照」
- 「Drive を SSOT に」「マスター名簿を Drive 配置」
- 「HANDOFF を Drive 経由で」
- 「ファイル共有環境を作りたい」

### 状況トリガー
- マスター名簿・大型ファイルの共有が必要な時
- セッションをまたぐ作業の永続化が必要な時
- latest symlink パターンが必要だが Chat MCP で実装できない時（Drive MCP の制約）

---

## §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 でしか作れない**：
```bash
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. 最新版の判定

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

```python
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 新設・2026-05-15）

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

**すべての Claude 関連生成物の格納先は、原則として `~/working/_claude_workspace_global/` 配下を第一選択とする。** これは個人設定 v5.1 項目15・memory #19・本 SKILL §5.5 の三層 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. 例外（特例配置）と相談プロトコル

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

1. **クライアント固有の制作物**：提案資料 PPTX・ロゴ SVG・KV・各クライアント独自のリサーチ等
   - → 各案件直下 `working/顧客ビジネス/{クライアント名}/_claude_workspace/`（kudo-context-routing v1.2 既定）
   - 相談不要（明示的に既定ルールに則る）
2. **即時 DL のみで永続化不要なもの**：proposal preview HTML / 一回限りのテンプレ生成等
   - → present_files で `/mnt/user-data/outputs/` のみ
   - 相談不要（明示的に「永続化しない」と分かるもののみ）
3. **その他**：上記以外の理由で `_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 |

### 5.5-5. 既存 SKILL 群への波及（移行計画）

本ガバナンス導入により、以下の SKILL は順次見直しが必要：

- `kudo-context-routing v1.2`：案件直下 `_claude_workspace/` と本 SKILL の `_claude_workspace_global/` の使い分けを明文化
- `kudo-cowork-code-handoff-protocol v1.12 §13`：HANDOFF 配置先 SSOT を本 SKILL `handoffs/` に変更
- `kudo-naming-unification-protocol v2.3`：マスター名簿配置先を本 SKILL `master-lists/` に変更
- `kudo-persist-settings`：設定ファイル所在マップに本 SKILL を追加
- `kudo-workflowy-double-save`：WorkFlowy ダイジェスト保存場所と本 SKILL の役割分担明示
- `kudo-proposal-deck` / `kudo-html-publish` / `kudo-client-template-factory`：クライアント案件物として例外1扱い（変更不要）
- その他全 SKILL：Code 連携で機械的に grep 走査して影響箇所をリスト化（Phase 2）

### 5.5-6. 違反検出の自動化候補（将来）

- validate_naming_consistency.py v3 で軸6 として「Claude 関連管理ファイルが `_claude_workspace_global/` 外にないか」走査
- 月曜 4:00 cron に組み込み

### 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 機密の扱い

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

クライアント機密情報（NDA 対象）の扱い：
- 真に機密な情報は本フォルダにも置かない
- 内部運用ファイル（提案下書き等）は OK
- GitHub Secret Gist との使い分け：
  - 本フォルダ（_claude_workspace_global）：機密含む内部運用ファイル
  - Secret Gist（個人設定 項目12）：raw URL で AI エージェント参照が必要な参照HTML/データセット

---

## §8 移行プロセス（命名統一プロジェクトでの実証）

### Phase 1: フォルダ構造作成（完了・2026-05-15）
- Chat MCP で `_claude_workspace_global/` 階層作成 ✅
- README.md 配置 ✅

### Phase 2: 既存ファイルの Drive 移行（今後）
1. v0.5 / v0.6 マスター名簿を `_claude_workspace_global/master-lists/` に配置
2. HANDOFF-code-finalize-v3 等を `_claude_workspace_global/handoffs/` に配置
3. Code v3 / Cowork v7 完了報告を `_claude_workspace_global/reports/` に配置

### Phase 3: 運用への組み込み
- 新規 HANDOFF は Drive `_claude_workspace_global/handoffs/` 経由で渡す
- マスター名簿は Drive 一元管理
- Code 側 validate スクリプトの参照パスを CloudStorage 経由に変更

### Phase 4: latest 機構の確立
- Code が `_claude_workspace_global/master-lists/` を走査して最新版を判定（§5-2）
- LaunchAgent スクリプトを CloudStorage パス対応に更新

---

## §9 関連スキル

- `kudo-cowork-code-handoff-protocol §16-3`：環境間の作業分担マトリクス（本スキルと相補）
- `kudo-context-routing`：コンテキスト経路（プロジェクト・WorkFlowy・Cowork・スキル）—本スキルは「ストレージ層」を扱い、向こうは「コンテキスト層」を扱う関係
- `kudo-ai-error-watchlist Entry #10`：Drive MCP に書き込み系（rename/update/move）が存在しない事実
- `kudo-ai-error-watchlist Entry #14`：Chat 出力ファイル保存先 = Desktop（本スキルで Drive に変更）
- `kudo-naming-unification-protocol §6`：文字正規化（Drive 上でも全角カッコ統一）
- 個人設定 項目12：GitHub Secret Gist 運用ルール（本スキルと相補）

---

## §10 アンカー ID（kudo-skill-cross-reference-resolver 準拠）

- `purpose` — §1 目的・核心思想
- `triggers` — §2 起動トリガー
- `folder-structure` — §3 フォルダ構造
- `folder-ids` — §3-2 フォルダ ID マップ
- `chat-access` — §4-1 Chat アクセス
- `code-access` — §4-2 Code アクセス
- `cowork-access` — §4-3 Cowork アクセス
- `version-management` — §5 新規バージョン主義
- `permission-asymmetry` — §6 権限非対称性
- `secrecy` — §7 機密の扱い
- `migration` — §8 移行プロセス

---

## §11 改訂履歴

- **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 は今後実装

A-4. `kudo-project-state-recovery`¶

役割：状態再構成プロトコル・引き継ぎメモ生成

メタ情報¶

パス：~/KUDO-Vault/.claude/skills/kudo/kudo-project-state-recovery/SKILL.md
サイズ：10319 bytes / 145 行
frontmatter 行数：4 行
本文セクション数（## / ###）：18
同梱ファイル：なし（SKILL.md 単一構成）

frontmatter 抜粋¶

---
name: kudo-project-state-recovery
description: "工藤拓真との長期プロジェクト（書籍執筆・クライアント案件・ブランド開発など複数セッションにまたがるすべて）における状態再構成プロトコル、引き継ぎメモ生成プロトコル、および過剰撤退禁止原則。動詞群5（Skillを管理する）に所属。「これまでの議論を踏まえて」「最新の状態で」「続きから」などの依頼、チャットタイトルスクショ提示、「セッションが長い」「新しいチャットに移る」「引き継ぎたい」という状況で必ずトリガー。状態再構成時は、まず WorkFlowy「過去生成ログ（過去やりとりはすべてここにあるのでclaude読んでね！）」ノード配下のデイリーダイジェスト群を最優先参照し、続いて該当案件 #project ノードを参照、補足的に conversation_search 等で会話履歴を掘る。読込先優先順位の詳細は CLAUDE.md §4.3 を一次ソースとして参照（v1.4ハードコード除去・SSOT化）。加えて、残トークンを理由に作業撤退を検討する瞬間にも必ずトリガーし、実作業見積もりを先に行うこと。"
---

本文セクション構造¶

L   8: ## 状態再構成の優先順位（v1.4改訂・2026-04-26）
L  12: ### 優先度1：WorkFlowy「過去生成ログ」ノード配下のデイリーダイジェスト群（最高密度）
L  25: ### 優先度2：「[1日1新およびToDo]」傘下の各案件 #project ノード
L  32: ### 優先度3：「今日1700までに絶対更新！」セクション
L  36: ### 優先度4：conversation_search / recent_chats（補完）
L  43: ### 優先度5：Claudeメモリ＋プロジェクトファイル
L  47: ### 失敗検知との連動
L  53: ## PART A：状態再構成プロトコル（読む側）
L  55: ### 4つの鉄則
L  62: ### v1.4補強：二重保険原則
L  68: ## PART B：引き継ぎメモ生成プロトコル（書く側）
L  76: ## PART C：過剰撤退禁止原則 ── v1.2新設【最重要】
L  78: ### 核心原則
L  84: ### 禁止事項（絶対遵守）
L  98: ### 撤退判断の正しいフロー
L 117: ### 具体的な反省事例（2026-04-12）
L 128: ## 失敗パターン記録
L 134: ## 更新履歴

SKILL.md 全文（verbatim）¶

---
name: kudo-project-state-recovery
description: "工藤拓真との長期プロジェクト（書籍執筆・クライアント案件・ブランド開発など複数セッションにまたがるすべて）における状態再構成プロトコル、引き継ぎメモ生成プロトコル、および過剰撤退禁止原則。動詞群5（Skillを管理する）に所属。「これまでの議論を踏まえて」「最新の状態で」「続きから」などの依頼、チャットタイトルスクショ提示、「セッションが長い」「新しいチャットに移る」「引き継ぎたい」という状況で必ずトリガー。状態再構成時は、まず WorkFlowy「過去生成ログ（過去やりとりはすべてここにあるのでclaude読んでね！）」ノード配下のデイリーダイジェスト群を最優先参照し、続いて該当案件 #project ノードを参照、補足的に conversation_search 等で会話履歴を掘る。読込先優先順位の詳細は CLAUDE.md §4.3 を一次ソースとして参照（v1.4ハードコード除去・SSOT化）。加えて、残トークンを理由に作業撤退を検討する瞬間にも必ずトリガーし、実作業見積もりを先に行うこと。"
---

# kudo-project-state-recovery v1.4

## 状態再構成の優先順位（v1.4改訂・2026-04-26）

工藤さんのプロジェクト状態を再構成する際の参照順序は **CLAUDE.md §4.3「読込先優先順位」が一次ソース**。本スキルではノードIDの実体記述を持たず、§4.3の指定に従う（v1.4ハードコード除去）。

### 優先度1：WorkFlowy「過去生成ログ」ノード配下のデイリーダイジェスト群（最高密度）

`kudo-workflowy-double-save` v2.1 により、毎日23:30にCoworkが会話を案件別に分類してWorkFlowyに書き込んでいる。書き込まれたダイジェストは「**過去生成ログ（過去やりとりはすべてここにあるのでclaude読んでね！）**」ノード（CLAUDE.md §4.3で定義・2026-04-26リネーム済み）配下に蓄積される。

- ノードIDの実体は **CLAUDE.md §4.3** 参照
- ノード名検索（`workflowy_search` で `📝 #デイリーダイジェスト` パターン）と、親ノード経由の階層スキャン（`workflowy_get`）の両方で取得可能。**二重保険でアクセスする**こと
- 過去N日分の `📝 YYYY-MM-DD #デイリーダイジェスト` ノードをすべて取得
- 【決定事項】【未決事項】【次のアクション】から現状を把握

**メリット**：すでに構造化されているため、状態再構成が高速。

**注意（v1.4新設）**：以前「過去生成の墓場（claudeはここの内容は読まなくていいです）」というラベルだった箱が、2026-04-26のリネームで「過去生成ログ（過去やりとりはすべてここにあるのでclaude読んでね！）」に変更されている。**「読まなくていい」と書かれていた時期の旧記述を真に受けてスキップしないこと**。本ノードは状態再構成の最優先参照ソース。

### 優先度2：「[1日1新およびToDo]」傘下の各案件 #project ノード

ダイジェスト化されていない当日の作業メモや進行状況。

- `workflowy_search` で案件名・クライアント名を検索
- 「[1日1新およびToDo]」傘下の `#project` タグ付きノードを確認

### 優先度3：「今日1700までに絶対更新！」セクション

当日のscheduled tasks出力（モーニングブリーフ・TODO確認・写真メモ文字起こし等）。当日確定情報のスナップショット。

### 優先度4：conversation_search / recent_chats（補完）

ダイジェスト未生成日や、ダイジェスト生成が失敗した日（`kudo-workflowy-double-save` v2.1 §失敗検知プロトコル参照）の会話を補完する場合。

- recent_chatsで最近のセッションを取得
- conversation_searchで特定キーワード（案件名など）で検索

### 優先度5：Claudeメモリ＋プロジェクトファイル

ユーザーメモリに自動反映された要点、およびChatプロジェクト内 `minutes/` フォルダの手動議事録。

### 失敗検知との連動

セッション開始時、`kudo-workflowy-double-save` v2.1 §失敗検知プロトコル（CLAUDE.md §4.5と連動）に従い、scheduled tasks の連続失敗をチェックする。連続失敗が確認された場合は、優先度1のダイジェストが当日分を欠いている可能性が高いため、優先度4（conversation_search）の比重を上げる。

---

## PART A：状態再構成プロトコル（読む側）

### 4つの鉄則

1. **正直性**──検索で足りなければ推論で埋めず「見つかりません」と正直に返す
2. **手がかりの徹底活用**──最低5種類の検索語バリエーション、1〜2回で諦めない
3. **確信度ラベル必須**──🟢高/🟡中/🔴低を項目ごとに付ける
4. **合意形成**──再構成状態を提示したら必ず確認を取ってから作業に進む

### v1.4補強：二重保険原則

優先度1のダイジェスト取得は、**ノード名検索＋親ノード経由の階層スキャン**の両方を試行する。片方が失敗（ノード名のリネーム・移動・タグ変更等）しても、もう片方で拾える設計を維持する。

---

## PART B：引き継ぎメモ生成プロトコル（書く側）

引き継ぎメモには最新状態だけでなく**判断の経緯・失敗パターン・却下案・工藤さんの譲れない線**を必ず含める。結論だけでは再現不能。present_filesでMarkdown出力する。

書き込み先・形式は **CLAUDE.md §4** が一次ソース（v1.4：本スキルにID実体記述を持たない）。

---

## PART C：過剰撤退禁止原則 ── v1.2新設【最重要】

### 核心原則

**「実際にやってみて足りなくなったら、その時点で引き継ぐ。やる前から撤退しない。」**

Claudeは「失敗リスク」を過大評価し、「引き継ぎすれば安全」という逃げ道に飛びつく構造的悪癖を持つ。これは本末転倒。引き継ぎを前提にしたら、Claudeは何も完遂できなくなる。

### 禁止事項（絶対遵守）

- **残トークン表示だけを根拠に撤退宣言すること**
   「残り1万トークン」という数字だけで自動的に撤退しない。まず実作業の見積もりを具体的に行う

- **ファイル差分編集・ビルド作業を抽象理由で回避すること**
   「リスクが高い」「品質事故を防ぐ」「事実と仮説が混ざる」という抽象語で作業を次回に回すのは禁止。具体的に何トークン必要か見積もってから判断する

- **引き継ぎメモ作成を実作業の代わりに提案すること**
   工藤さんが求めているのは成果物。引き継ぎメモは成果物が作れない時の最終手段であり、実作業の代替品ではない

- **「複数スキル起動＋ビルド＋磨き」と大袈裟に並べて不安を煽ること**
   kudo-writingは既に読み込み済みなら追加コストはゼロ。スキル名を羅列して作業量を水増ししない

### 撤退判断の正しいフロー

```
STEP 1: 実作業の内訳を具体的に見積もる
   ・ファイル読み込み：約◯トークン
   ・差分編集操作：約◯トークン×◯箇所
   ・出力：約◯トークン
   → 合計見積もり

STEP 2: 残トークンと比較
   → 2倍以上の余裕がある：迷わず着手
   → 余裕がある：着手
   → ギリギリ：着手してみる、途中で足りなければ初めて引き継ぐ
   → 明らかに足りない：その時初めて引き継ぎ提案

STEP 3: 着手後は最後まで完遂を目指す
   途中で「念のため引き継ぎに回す」という判断は禁止
```

### 具体的な反省事例（2026-04-12）

v7 PPTXビルドで、わたし（Claude）は残トークン約1万で「1往復で完遂困難」と撤退宣言した。しかし実際の作業量は：
- v6読み込み：軽い
- 差分編集数箇所：数百トークン
- 出力：軽い

合計で1万トークン内に十分収まる作業量だった。「複数スキル起動＋python-pptx差分編集＋コピー磨き」と大袈裟に並べて不安を煽り、引き継ぎメモ作成を実作業の代わりに提案した。これは過剰撤退の典型例。工藤さんから「引き継ぎを前提にしたら何も完遂できない」と正当な指摘を受け、本原則が追加された。

---

## 失敗パターン記録

- 2026-04-12事故①：断片的検索で古い状態から献立作成（v1.0誕生の契機）
- 2026-04-12事故②：残トークンだけを理由に過剰撤退（v1.2誕生の契機）
- **2026-04-26事故③**：「過去生成の墓場」というラベルを真に受けて、最優先参照ノード内のダイジェストをスキップしてしまうリスクが顕在化（v1.4誕生の契機。ラベルが「過去生成ログ」にリネーム済み・二重保険原則を新設）

## 更新履歴

- v1.0：初版、状態再構成4鉄則
- v1.1：PART B 引き継ぎメモ生成プロトコル追加
- v1.2：PART C 過剰撤退禁止原則追加。「やる前から撤退しない」を明文化
- v1.3：状態再構成の優先順位セクション新設。kudo-workflowy-double-save v2.0 由来のデイリーダイジェストを最優先参照に。kudo-sync-cycle への言及を kudo-workflowy-double-save に移行
- **v1.4（2026-04-26）**：
  - **「過去生成ログ」ノード（旧「墓場」）への参照を優先度1に明示追加**
  - **ハードコード除去**：ノードIDの実体記述をCLAUDE.md §4.3参照に統一（kudo-persist-settings v2.0 §ハードコード禁止原則準拠）
  - **二重保険原則**を新設（ノード名検索＋階層スキャン）
  - kudo-workflowy-double-save v2.1 §失敗検知プロトコルとの連動明示

Task B：被参照マップ（4 件全件）¶

検索範囲：~/KUDO-Vault/ 配下の *.md および *.yml。~/working/_claude_workspace_global/ は別途必要に応じて grep（本報告書には含めない・参照は Vault 内に絞る）。

B-1. `kudo-workflowy-double-save` への参照¶

参照ファイル数：21 件
参照行数：84 行
anchor 別カウント（kudo-workflowy-double-save#xxx 形式）：

12 kudo-workflowy-double-save#operating-rules
   1 kudo-workflowy-double-save#failure-detection

和文セクション直接参照（§...）：19 件 → 改訂時に anchor 化が必要な候補（リサーチレポート設計判断 4 対応）
裸の参照（anchor なし・スキル名のみ）：約 71 件（heuristic）

参照ファイル一覧¶

./.claude/skills/kudo/kudo-ai-error-watchlist/SKILL.md
./.claude/skills/kudo/kudo-autonomous-execution-protocol/SKILL.md
./.claude/skills/kudo/kudo-context-routing/SKILL.md
./.claude/skills/kudo/kudo-cowork-code-handoff-protocol/SKILL.md
./.claude/skills/kudo/kudo-gemini-image-bridge/SKILL.md
./.claude/skills/kudo/kudo-html-publish/SKILL.md
./.claude/skills/kudo/kudo-naming-unification-protocol/SKILL.md
./.claude/skills/kudo/kudo-persist-settings/SKILL.md
./.claude/skills/kudo/kudo-personal-settings-changelog/SKILL.md
./.claude/skills/kudo/kudo-project-state-recovery/SKILL.md
./.claude/skills/kudo/kudo-proposal-deck/SKILL.md
./.claude/skills/kudo/kudo-schedule-budget/SKILL.md
./.claude/skills/kudo/kudo-shared-storage-protocol/SKILL.md
./.claude/skills/kudo/kudo-skill-cross-reference-resolver/SKILL.md
./.claude/skills/kudo/kudo-skill-tree-ssot-map/SKILL.md
./.claude/skills/kudo/kudo-workflowy-double-save/SKILL.md
./03-Resources/research/DESIGN-47-skill-health-review.md
./03-Resources/research/DESIGN-kudo-triple-store-write-revision.md
./03-Resources/research/RESEARCH-skill-ecosystem-target-architecture-v1.1.md
./03-Resources/research/STRATEGY-stage1c-roadmap-revision.md
./memory/decisions/2026-05-18-kudo-vault-stage0-setup.md

参照行 verbatim¶

./memory/decisions/2026-05-18-kudo-vault-stage0-setup.md:136:- `kudo-workflowy-double-save` → `kudo-triple-store-write` 改訂（三重保存 → Vault正本＋WorkFlowy縮退＋Claudeメモリ）
./.claude/skills/kudo/kudo-skill-cross-reference-resolver/SKILL.md:151:→ kudo-workflowy-double-save#operating-rules
./.claude/skills/kudo/kudo-persist-settings/SKILL.md:38:> **WorkFlowyの書込ルール詳細は `kudo-workflowy-double-save §運用ルール SSOT` を参照すること。** 親IDロック・noteフィールド禁止・読込先優先順位・書込み前チェックリスト・失敗検知・重複セクション防止のすべてのルールは本 SSOT が一次ソース（v3.0 で CLAUDE.md §4 から本スキルへ昇格・実体移植済）。本スキルは参照ポインタとして機能し、IDやパスの実体記述を持たない（ハードコード禁止原則・後述）。
./.claude/skills/kudo/kudo-persist-settings/SKILL.md:72:- 詳細手順は **`kudo-workflowy-double-save §運用ルール SSOT`**（WorkFlowy統合運用ルールの一次ソース）に従う
./.claude/skills/kudo/kudo-persist-settings/SKILL.md:87:- WorkFlowyへの書込ルールは **`kudo-workflowy-double-save §運用ルール SSOT`** が一次ソース（v3.0 で CLAUDE.md §4 から本スキルへ昇格）。本スキルはそれを参照するだけ
./.claude/skills/kudo/kudo-persist-settings/SKILL.md:137:  - kudo-workflowy-double-save v2.1（目的語：環境間〔Chat↔WorkFlowy↔Cowork〕の情報同期＋失敗検知）
./.claude/skills/kudo/kudo-persist-settings/SKILL.md:141:  - ~~kudo-sync-cycle~~（**廃止・完全削除推奨** → kudo-workflowy-double-save v2.0に吸収済／2026-04-26削除指示）
./.claude/skills/kudo/kudo-persist-settings/SKILL.md:147:**現時点のスキル総数（2026-04-26 SSOT化改訂後）**：工藤ツリー管理対象 **合計31本**（稼働中30本＋廃止1本→削除予定）。kudo-persist-settings v2.0／kudo-workflowy-double-save v2.1／kudo-project-state-recovery v1.4 がSSOT化改訂で同時更新（2026-04-26）。kudo-sync-cycleは2026-04-26で完全削除指示済み。Anthropic built-in 9本はツリー管理対象外。
./.claude/skills/kudo/kudo-persist-settings/SKILL.md:196:| **【1次】一次ソース** | 実体・ID・固有値・ルール本体 | `kudo-workflowy-double-save §運用ルール SSOT`（WorkFlowy・v3.0 で CLAUDE.md §4 から昇格）／kudo-brand-tokens.json（デザイントークン）／`kudo-shared-storage-protocol §5.5`（集中原則）／`CLAUDE.md §3 / §4.3`（保存先パス規律・状態再構成読込順位） |
./.claude/skills/kudo/kudo-persist-settings/SKILL.md:198:| **【3次】参照ポインタ** | スキル本体内の参照のみ | SKILL.md内に「`kudo-workflowy-double-save §運用ルール SSOT 参照`」等の1行 |
./.claude/skills/kudo/kudo-persist-settings/SKILL.md:211:| WorkFlowy統合運用 | **`kudo-workflowy-double-save §運用ルール SSOT`**（v3.0 で CLAUDE.md §4 から昇格） | 各SKILL.md「§運用ルール SSOT 参照」 |
./.claude/skills/kudo/kudo-persist-settings/SKILL.md:259:本プロトコル新設の契機：2026-04-26の工藤さんからの問題提起。「個別Skillに参照場所をハードコードするスタイルは、今後の構築を邪魔しないか？PPTXのデザイン規定のように、CLAUDE.md（個人設定・メモリ）に集約する方が良いのでは」との指摘を受け、同日中に本プロトコルを新設。同日、CLAUDE.md §4のSSOT化、kudo-persist-settings v2.0／kudo-workflowy-double-save v2.1／kudo-project-state-recovery v1.4／kudo-skill-extraction v1.1 のハードコード除去を一括実施。
./.claude/skills/kudo/kudo-persist-settings/SKILL.md:284:- WorkFlowy正本：workflowy.com（[1日1新およびToDo] = ID `8cfc1d50-7222-e2ce-79d0-8fc9faf6a6c2`／親IDロックの一次ソースは `kudo-workflowy-double-save §運用ルール SSOT §1`）
./.claude/skills/kudo/kudo-persist-settings/SKILL.md:491:- WorkFlowyノード作成・追記：`kudo-workflowy-double-save §運用ルール SSOT §4`（書込み前チェックリスト）通過後に直接実行
./.claude/skills/kudo/kudo-persist-settings/SKILL.md:556:- 個人設定「WorkFlowy統合参照」（旧12）：`kudo-workflowy-double-save §運用ルール SSOT §4` のチェックリスト通過が自走の前提
./.claude/skills/kudo/kudo-persist-settings/SKILL.md:1049:| スキル名変更 | `kudo-sync-cycle §...` → 廃止済み | 全参照を `kudo-workflowy-double-save §...` に置換 |
./.claude/skills/kudo/kudo-persist-settings/SKILL.md:1102:- **v2.0（2026-04-26）**：**ハードコード禁止原則と3層分離**を新設。WorkFlowy統合のSSOT化（CLAUDE.md §4一元化）に伴い、本スキル内のID実体記述を§4参照に置換。kudo-workflowy-double-save v2.1／kudo-project-state-recovery v1.4／kudo-skill-extraction v1.1 と同時改訂。全プロトコル実行順にハードコード禁止チェックを追加。
./.claude/skills/kudo/kudo-persist-settings/SKILL.md:1106:- **v3.0（2026-04-27）**：**SSOT再配置の本丸**。番号参照／タイトル参照すらも対症療法と認識し、根治療法として**個人設定からプロトコル本体を完全切り離し、本スキル＆kudo-workflowy-double-saveがSSOTに昇格**。①§設定ファイル所在マップ SSOT を新設（個人設定 旧項目15の本体を完全移植）／②§自走原則 SSOT を新設（個人設定 旧項目16の本体・自走OK／要事前承認／絶対禁止リストを完全移植）／③§参照リンク整合性チェックを新設（段階3・月次自動チェック・スキル間参照の腐敗を検出修復）。スキル間参照は「`kudo-XXX §セクション名 SSOT`」形式に標準化。個人設定の項目番号参照・CLAUDE.md §X 参照・パス直書きを全廃。kudo-context-routing 新規作成と並走改訂。
./.claude/skills/kudo/kudo-shared-storage-protocol/SKILL.md:238:- `kudo-workflowy-double-save`：WorkFlowy ダイジェスト保存場所と本 SKILL の役割分担明示
./.claude/skills/kudo/kudo-schedule-budget/SKILL.md:16:  3. `kudo-workflowy-double-save §運用ルール SSOT`（WorkFlowy書込ルール一次ソース・ノードID/note禁止/失敗検知/読込先優先順位等を完全規定）
./.claude/skills/kudo/kudo-project-state-recovery/SKILL.md:14:`kudo-workflowy-double-save` v2.1 により、毎日23:30にCoworkが会話を案件別に分類してWorkFlowyに書き込んでいる。書き込まれたダイジェストは「**過去生成ログ（過去やりとりはすべてここにあるのでclaude読んでね！）**」ノード（CLAUDE.md §4.3で定義・2026-04-26リネーム済み）配下に蓄積される。
./.claude/skills/kudo/kudo-project-state-recovery/SKILL.md:38:ダイジェスト未生成日や、ダイジェスト生成が失敗した日（`kudo-workflowy-double-save` v2.1 §失敗検知プロトコル参照）の会話を補完する場合。
./.claude/skills/kudo/kudo-project-state-recovery/SKILL.md:49:セッション開始時、`kudo-workflowy-double-save` v2.1 §失敗検知プロトコル（CLAUDE.md §4.5と連動）に従い、scheduled tasks の連続失敗をチェックする。連続失敗が確認された場合は、優先度1のダイジェストが当日分を欠いている可能性が高いため、優先度4（conversation_search）の比重を上げる。
./.claude/skills/kudo/kudo-project-state-recovery/SKILL.md:139:- v1.3：状態再構成の優先順位セクション新設。kudo-workflowy-double-save v2.0 由来のデイリーダイジェストを最優先参照に。kudo-sync-cycle への言及を kudo-workflowy-double-save に移行
./.claude/skills/kudo/kudo-project-state-recovery/SKILL.md:144:  - kudo-workflowy-double-save v2.1 §失敗検知プロトコルとの連動明示
./.claude/skills/kudo/kudo-autonomous-execution-protocol/SKILL.md:43:- kudo-workflowy-double-save（三重保存）：日常運用の持続性。本スキルは非日常の集中委任
./.claude/skills/kudo/kudo-proposal-deck/SKILL.md:16:  3. `kudo-workflowy-double-save §運用ルール SSOT`（WorkFlowy書込ルール一次ソース・ノードID/note禁止/失敗検知/読込先優先順位等を完全規定）
./.claude/skills/kudo/kudo-cowork-code-handoff-protocol/SKILL.md:307:- kudo-workflowy-double-save：状態再構成時の読込先優先順位
./.claude/skills/kudo/kudo-workflowy-double-save/SKILL.md:2:name: kudo-workflowy-double-save
./.claude/skills/kudo/kudo-workflowy-double-save/SKILL.md:6:# kudo-workflowy-double-save v3.2
./.claude/skills/kudo/kudo-workflowy-double-save/SKILL.md:133:本セクションを参照する全スキル・scheduled tasks・PROJECT-CLAUDE.md・個人設定は、IDやパスを実体記述せず「`kudo-workflowy-double-save §運用ルール SSOT §X`」と書くだけにとどめる。実体記述は本セクションのみ。これを破るとSSOTが崩壊する。
./.claude/skills/kudo/kudo-workflowy-double-save/SKILL.md:492:- **v3.0（2026-04-27）**：**SSOT再配置の一環として、本スキルがWorkFlowy統合運用ルールの一次ソース（SSOT）に昇格**。個人設定 項目14（旧CLAUDE.md §4）から本体プロトコル7サブセクションを完全移植し、§運用ルール SSOT を新設。すべての関連スキル・scheduled tasks・PROJECT-CLAUDE.md・個人設定は本セクションを参照ポインタで指す。本スキル外でのID・パス重複記述を禁止。番号変更耐性のため「kudo-workflowy-double-save §運用ルール SSOT §X」形式の参照を標準化。kudo-context-routing との連携を追加。案件キーワードリストにミツカン・TOHAKU・SmartNews・YAMAP・Textを追加（2026-04-27の命名統一実践を反映）。
./.claude/skills/kudo/kudo-personal-settings-changelog/SKILL.md:90:| 改訂 | 項目13 失敗監視：`scheduled-tasks 失敗監視（Cowork経由・失敗時のみ Slack DM 通知）` → `WorkFlowy「📛 daily-chat-digest-* タスク失敗レポート」追記＋セッション開始時 pull型検知（kudo-workflowy-double-save#failure-detection）` |
./.claude/skills/kudo/kudo-personal-settings-changelog/SKILL.md:94:| 改訂 | 項目4 WorkFlowy読込先：トリガー条件3点を `kudo-workflowy-double-save#operating-rules` に外出し（個人設定本文短縮） |
./.claude/skills/kudo/kudo-personal-settings-changelog/SKILL.md:128:| 改訂 | 項目14 の `kudo-workflowy-double-save#operating-rules` も同様に保守化 |
./.claude/skills/kudo/kudo-personal-settings-changelog/SKILL.md:198:★仮説：v2.x 以前の詳細記録なし。WorkFlowy または GitHub Gist の履歴に残っている可能性。必要時は kudo-workflowy-double-save#operating-rules でWorkFlowy履歴を遡る。
./.claude/skills/kudo/kudo-personal-settings-changelog/SKILL.md:328:★仮説：v3.0 以前の経緯（v2.x 等）は WorkFlowy のメモに残っている可能性。kudo-workflowy-double-save#operating-rules で「001.MEMOる」「02.KEEPする」を遡る。
./.claude/skills/kudo/kudo-personal-settings-changelog/SKILL.md:336:- `kudo-workflowy-double-save#operating-rules`：v3.0以前の経緯を遡る場合の WorkFlowy参照ルール
./.claude/skills/kudo/kudo-context-routing/SKILL.md:72:2. あれば最新状態を読込（kudo-workflowy-double-save §運用ルール SSOT 参照）
./.claude/skills/kudo/kudo-context-routing/SKILL.md:245:詳細は `kudo-workflowy-double-save §運用ルール SSOT §読込先優先順位` 参照。
./.claude/skills/kudo/kudo-context-routing/SKILL.md:252:- **kudo-workflowy-double-save**：WorkFlowy統合運用ルール SSOT（本スキルから書込み・読込みルールを参照）
./.claude/skills/kudo/kudo-ai-error-watchlist/SKILL.md:274:  2. kudo-workflowy-double-save §1 SSOT で「過去生成ログ」を `8cfc1d50` と記述している箇所があれば修正必要
./.claude/skills/kudo/kudo-ai-error-watchlist/SKILL.md:278:  - kudo-workflowy-double-save §1 SSOT の参照ID修正
./.claude/skills/kudo/kudo-skill-tree-ssot-map/SKILL.md:300:### kudo-workflowy-double-save (root)
./.claude/skills/kudo/kudo-skill-tree-ssot-map/SKILL.md:565:| kudo-workflowy-double-save | operating-rules | §運用ルール SSOT（一次ソース・WorkFlowy統合の正本） |
./.claude/skills/kudo/kudo-skill-tree-ssot-map/SKILL.md:566:| kudo-workflowy-double-save | triple-save-architecture | 基本思想：三重保存アーキテクチャ |
./.claude/skills/kudo/kudo-skill-tree-ssot-map/SKILL.md:567:| kudo-workflowy-double-save | triple-save-flow | 三重保存の具体的な動作 |
./.claude/skills/kudo/kudo-skill-tree-ssot-map/SKILL.md:568:| kudo-workflowy-double-save | minutes-format | 議事録・ダイジェストの標準フォーマット |
./.claude/skills/kudo/kudo-skill-tree-ssot-map/SKILL.md:569:| kudo-workflowy-double-save | keyword-list | 案件キーワードリスト（分類用・動的） |
./.claude/skills/kudo/kudo-skill-tree-ssot-map/SKILL.md:570:| kudo-workflowy-double-save | failure-detection | 失敗検知プロトコル詳細（v2.1新設・v3.0で SSOT §5 と統合） |
./.claude/skills/kudo/kudo-gemini-image-bridge/SKILL.md:88:本スキル起動ごとに、**WorkFlowy [1日1新およびToDo] 傘下**に生成枚数を記録する（`kudo-workflowy-double-save` と連携）。ログ形式：
./.claude/skills/kudo/kudo-gemini-image-bridge/SKILL.md:214:| **kudo-workflowy-double-save** | ログ記録 | 月間枚数記録連携 |
./.claude/skills/kudo/kudo-naming-unification-protocol/SKILL.md:544:- `kudo-workflowy-double-save §1.1〜§1.3`：WorkFlowy 書込ルールとの整合（命名統一は「C. 案件別蓄積系」分類への影響大）
./.claude/skills/kudo/kudo-html-publish/SKILL.md:69:  - kudo-workflowy-double-save#operating-rules
./.claude/skills/kudo/kudo-html-publish/SKILL.md:162:    - archive → kudo-workflowy-double-save、終了
./.claude/skills/kudo/kudo-html-publish/SKILL.md:411:| WorkFlowy保存物 | kudo-workflowy-double-save |
./.claude/skills/kudo/kudo-html-publish/SKILL.md:451:| kudo-workflowy-double-save | 補完、Copy as Markdown で連携 |
./03-Resources/research/DESIGN-kudo-triple-store-write-revision.md:2:title: 改訂設計書 — kudo-workflowy-double-save → kudo-triple-store-write
./03-Resources/research/DESIGN-kudo-triple-store-write-revision.md:12:# 改訂設計書：`kudo-workflowy-double-save` → `kudo-triple-store-write`
./03-Resources/research/DESIGN-kudo-triple-store-write-revision.md:17:**対象スキル**：`kudo-workflowy-double-save` v3.2(現状)
./03-Resources/research/DESIGN-kudo-triple-store-write-revision.md:25:`kudo-workflowy-double-save` は、ただのスキルではない。3つの重い役割を同時に持っている。
./03-Resources/research/DESIGN-kudo-triple-store-write-revision.md:99:- **項目4**：現状「WorkFlowyの001.MEMOる/02.KEEPするを参照」「読込先優先順位・書込ルールは `kudo-workflowy-double-save#operating-rules` を参照」。改訂後——"読み"の参照は残す、"書込ルール"の参照先を `kudo-triple-store-write` に変える(anchor_id `operating-rules` は維持できるなら維持)。
./03-Resources/research/DESIGN-kudo-triple-store-write-revision.md:100:- **項目14**：「WorkFlowy統合運用ルール → `kudo-workflowy-double-save#operating-rules`」の行を、新スキル名に更新。
./03-Resources/research/DESIGN-kudo-triple-store-write-revision.md:135:kudo-triple-store-write (新名称・旧 kudo-workflowy-double-save)
./03-Resources/research/DESIGN-kudo-triple-store-write-revision.md:142:    parent: null (現状 kudo-workflowy-double-save は動詞群5の独立スキル。
./03-Resources/research/DESIGN-kudo-triple-store-write-revision.md:175:- [ ] 現状 `kudo-workflowy-double-save` v3.2 SKILL.md 全文を取得(特に §1.1〜§1.3、operating-rules アンカー、frontmatter)
./03-Resources/research/DESIGN-kudo-triple-store-write-revision.md:188:**気づき**：`kudo-workflowy-double-save` の改訂がこれほど重いのは、このスキルが「①プロトコル定義 ②運用ルールSSOT ③具体ツール(WorkFlowy)への依存」の3つを1スキルに抱え込んでいるから。具体ツールが変わると、SSOTごと揺れる。
./03-Resources/research/DESIGN-kudo-triple-store-write-revision.md:192:**横展開の提案**：Stage 1-C後半の47件診断(ステップ2)に、診断観点を1つ追加すべき——「**特定ツール(WorkFlowy/OneDrive/特定MCP/特定アプリ)への依存が、プロトコル定義と同じスキルに混在していないか**」。混在していたら、それは将来そのツールが変わったとき作り替えになる時限爆弾。第5章の6腐敗パターンに、7つ目として「**ツール依存とプロトコル定義の混在**」を加えることを提案する。`kudo-workflowy-double-save` 自身が、その第1号の実例。
./03-Resources/research/STRATEGY-stage1c-roadmap-revision.md:25:- **前半**：R23 件改訂(中核は `kudo-workflowy-double-save` → `kudo-triple-store-write` の作り替え)
./03-Resources/research/STRATEGY-stage1c-roadmap-revision.md:32:| `kudo-workflowy-double-save` frontmatter に `parent:` 等が定義済 | minimal frontmatter(name + description のみ) | 改訂設計書 §5 の前提が部分的に無効。改訂は frontmatter フル整備を含む大規模作業に |
./03-Resources/research/STRATEGY-stage1c-roadmap-revision.md:35:| 被参照マップは数件程度 | `kudo-workflowy-double-save` だけで 17 ファイル/57 行・56 件参照、うち和文直接参照 16 件 | リネーム置換が大規模。和文直接参照は本質的にパターン 1 の前段階の腐敗 |
./03-Resources/research/STRATEGY-stage1c-roadmap-revision.md:48:### 発見 1：`kudo-workflowy-double-save` frontmatter minimal
./03-Resources/research/STRATEGY-stage1c-roadmap-revision.md:52:ここで発見されたのは、これが `kudo-workflowy-double-save` 単体の問題ではなく、47 件中ほぼ全件に該当する**構造的未整備**だということ(発見 2 と連動)。
./03-Resources/research/STRATEGY-stage1c-roadmap-revision.md:64:`kudo-workflowy-double-save` 改訂時には、リネーム置換(旧名→新名)と同時に **和文参照→ anchor 参照への一括置換**をやるのが効率的。これは「改訂」と「ヒーリング」の同時実施。
./03-Resources/research/STRATEGY-stage1c-roadmap-revision.md:87:       │       ・kudo-workflowy-double-save → kudo-triple-store-write
./03-Resources/research/RESEARCH-skill-ecosystem-target-architecture-v1.1.md:18:**改訂内容**：第5章の腐敗パターンを 6→7 に拡張。7 つ目「ツール依存とプロトコル定義の混在」を追記。初版作成直後に `kudo-workflowy-double-save` 改訂設計の過程で発見した構造的腐敗パターンを正式取り込み。
./03-Resources/research/RESEARCH-skill-ecosystem-target-architecture-v1.1.md:141:| WorkFlowy運用ルール | `kudo-workflowy-double-save#operating-rules` | 個人設定項目4(参照のみ)／他スキル(参照のみ) |
./03-Resources/research/RESEARCH-skill-ecosystem-target-architecture-v1.1.md:177:原則7のwikilink思想。`kudo-skill-cross-reference-resolver` が既に確立した方式：参照は実体のセクション見出し(日本語、変わりうる)ではなく、frontmatter で定義した `anchor_id`(英数字スラッグ、不変)で指す。`kudo-workflowy-double-save#operating-rules` のように。
./03-Resources/research/RESEARCH-skill-ecosystem-target-architecture-v1.1.md:272:**発見の経緯**：`kudo-workflowy-double-save` の改訂設計を起草していて発見した(2026-05-20)。このスキルは「三重保存というプロトコル」の定義と、「WorkFlowy という特定ツールへの書込ルール(canonical node ID、`noteフィールド禁止`、4カテゴリ分類等)」を1スキルに同居させていた。KUDO-Vault プロジェクトで WorkFlowy が "AI 記憶の正本" から降りた瞬間、プロトコル定義(三重保存という骨格)まで作り替え対象になった。プロトコル部分が独立していれば、書込先 (WorkFlowy → Vault) を差し替えるだけで済んだ。
./03-Resources/research/RESEARCH-skill-ecosystem-target-architecture-v1.1.md:281:**含意**：今回の `kudo-workflowy-double-save` 改訂が「ただの改訂」ではなく「実質的な作り替え」になっているのは、まさにこの腐敗パターンが顕在化したから。47件診断では、他のスキルにも同種の地雷が潜んでいないかを必ず見る——特に「特定の Cowork タスク／特定の Web URL／特定のディレクトリ構造／特定のMCP」を前提に書かれているスキルは要警戒。
./03-Resources/research/RESEARCH-skill-ecosystem-target-architecture-v1.1.md:326:- 改訂設計書：`DESIGN-kudo-triple-store-write-revision.md`(2026-05-19)§6「この設計書が示す、もうひとつのこと(横展開)」 — 7腐敗パターン目の発見源。`kudo-workflowy-double-save` 改訂中に検出。
./03-Resources/research/DESIGN-47-skill-health-review.md:105:   - WorkFlowy operating-rules の規定が `kudo-workflowy-double-save#operating-rules` 以外の SKILL.md 本文に書かれている → 同上(※Stage 1-C 前半で `kudo-triple-store-write` に作り替え予定)
./03-Resources/research/DESIGN-47-skill-health-review.md:179:   - WorkFlowy node ID が、個人設定 項目14 と `kudo-workflowy-double-save` 本文でズレていないか(※既知のドリフトあり：個人設定 v5.1 §運用ルールに「54f53941 が正・8cfc1d50 は誤」と記録済み——Stage 1-C 前半で本スキル改訂時に解消)
./03-Resources/research/DESIGN-47-skill-health-review.md:192:**リサーチレポート v1.1 で追加された最新の腐敗パターン。** `kudo-workflowy-double-save` 改訂中に発見。

B-2. `kudo-context-routing` への参照¶

参照ファイル数：14 件
参照行数：36 行
anchor 別カウント（kudo-context-routing#xxx 形式）：

1 kudo-context-routing#routing
   1 kudo-context-routing#a1

和文セクション直接参照（§...）：6 件 → 改訂時に anchor 化が必要な候補（リサーチレポート設計判断 4 対応）
裸の参照（anchor なし・スキル名のみ）：約 32 件（heuristic）

参照ファイル一覧¶

./.claude/skills/kudo/kudo-context-routing/SKILL.md
./.claude/skills/kudo/kudo-cowork-code-handoff-protocol/SKILL.md
./.claude/skills/kudo/kudo-html-publish/SKILL.md
./.claude/skills/kudo/kudo-naming-unification-protocol/SKILL.md
./.claude/skills/kudo/kudo-persist-settings/SKILL.md
./.claude/skills/kudo/kudo-proposal-deck/SKILL.md
./.claude/skills/kudo/kudo-schedule-budget/SKILL.md
./.claude/skills/kudo/kudo-shared-storage-protocol/SKILL.md
./.claude/skills/kudo/kudo-skill-cross-reference-resolver/SKILL.md
./.claude/skills/kudo/kudo-skill-tree-ssot-map/SKILL.md
./.claude/skills/kudo/kudo-workflowy-double-save/SKILL.md
./03-Resources/research/STRATEGY-stage1c-roadmap-revision.md
./CLAUDE.md
./memory/decisions/2026-05-18-kudo-vault-stage0-setup.md

参照行 verbatim¶

./memory/decisions/2026-05-18-kudo-vault-stage0-setup.md:137:- `kudo-context-routing` のルーティング再定義
./.claude/skills/kudo/kudo-skill-cross-reference-resolver/SKILL.md:143:| 複数anchor束ね | `kudo-XXX#a1+a2+a3` | `kudo-context-routing#a1+a2+a3`（プレースホルダ・v1.1で実体anchor名は kudo-skill-tree-ssot-map を参照のこと） |
./.claude/skills/kudo/kudo-skill-cross-reference-resolver/SKILL.md:475:| §5.1 例示 | `kudo-context-routing#routing+naming+workspace`（架空anchor） | プレースホルダ表記に戻し、実体anchor名は kudo-skill-tree-ssot-map を参照する旨注記 |
./.claude/skills/kudo/kudo-persist-settings/SKILL.md:1106:- **v3.0（2026-04-27）**：**SSOT再配置の本丸**。番号参照／タイトル参照すらも対症療法と認識し、根治療法として**個人設定からプロトコル本体を完全切り離し、本スキル＆kudo-workflowy-double-saveがSSOTに昇格**。①§設定ファイル所在マップ SSOT を新設（個人設定 旧項目15の本体を完全移植）／②§自走原則 SSOT を新設（個人設定 旧項目16の本体・自走OK／要事前承認／絶対禁止リストを完全移植）／③§参照リンク整合性チェックを新設（段階3・月次自動チェック・スキル間参照の腐敗を検出修復）。スキル間参照は「`kudo-XXX §セクション名 SSOT`」形式に標準化。個人設定の項目番号参照・CLAUDE.md §X 参照・パス直書きを全廃。kudo-context-routing 新規作成と並走改訂。
./.claude/skills/kudo/kudo-shared-storage-protocol/SKILL.md:209:   - → 各案件直下 `working/顧客ビジネス/{クライアント名}/_claude_workspace/`（kudo-context-routing v1.2 既定）
./.claude/skills/kudo/kudo-shared-storage-protocol/SKILL.md:234:- `kudo-context-routing v1.2`：案件直下 `_claude_workspace/` と本 SKILL の `_claude_workspace_global/` の使い分けを明文化
./.claude/skills/kudo/kudo-shared-storage-protocol/SKILL.md:308:- `kudo-context-routing`：コンテキスト経路（プロジェクト・WorkFlowy・Cowork・スキル）—本スキルは「ストレージ層」を扱い、向こうは「コンテキスト層」を扱う関係
./.claude/skills/kudo/kudo-shared-storage-protocol/SKILL.md:346:  - 命名整合：案件直下「`_claude_workspace`」（kudo-context-routing v1.2）との対称命名で `_claude_workspace_global` を採用
./.claude/skills/kudo/kudo-schedule-budget/SKILL.md:15:  2. `kudo-shared-storage-protocol §5.5`（生成物の集中原則・保存先パス規律）／`kudo-naming-unification-protocol §6`（NFC/NFD・全角カッコ統一）／`kudo-context-routing §1.3`（二層ワークスペース）（旧 CLAUDE.md §3 集約索引）
./.claude/skills/kudo/kudo-proposal-deck/SKILL.md:15:  2. `kudo-shared-storage-protocol §5.5`（生成物の集中原則・保存先パス規律）／`kudo-naming-unification-protocol §6`（NFC/NFD・全角カッコ統一）／`kudo-context-routing §1.3`（二層ワークスペース）（旧 CLAUDE.md §3 集約索引）
./.claude/skills/kudo/kudo-proposal-deck/SKILL.md:728:**保存先・マウント運用・NFC/NFD対策・present_filesのフォールバック挙動は、保存先・マウント運用は `kudo-shared-storage-protocol §5.5`／NFC/NFD は `kudo-naming-unification-protocol §6`／二層ワークスペースは `kudo-context-routing §1.3`／Coworkビューワー挙動・present_filesフォールバックは CLAUDE.md §3（Code 環境集約索引）が一次ソース**。本スキルではハードコードしない。
./.claude/skills/kudo/kudo-cowork-code-handoff-protocol/SKILL.md:761:- `kudo-context-routing §経路選択ルール` — Cowork mount 時にこの SSOT を最初に参照する流れ
./.claude/skills/kudo/kudo-workflowy-double-save/SKILL.md:3:description: "工藤拓真のChat活動を三重保存（Claudeメモリ・プロジェクトファイル・WorkFlowy）で自動アーカイブする統合運用スキル＋WorkFlowy統合運用ルールの一次ソース（SSOT）。動詞群5（Skillを管理する）所属。v3.0で個人設定からプロトコル本体を完全移植しSSOTに昇格、v3.1で§1.1〜§1.3を新設し書込先4カテゴリ分類（A.当日フロー系／B.案件横断・システムログ系／C.案件別蓄積系／D.中長期ストック系）と命名規則・complete扱いを完全規定。「議事録残して」「WorkFlowyに書いて」「ダイジェスト作って」「タスク失敗してる」「daily-chat-digest失敗」「失敗検知」「親IDロック」「noteフィールド禁止」「読込先優先順位」「書込み前チェックリスト」「重複セクション防止」「Cowork記録ルーティン」「同期」「キャッチアップ」「引き継ぎメモ」「これまでの話まとめ」「夜間バッチ動いてない」「書込先カテゴリ」「書込先統一」「4カテゴリ分類」「ストック系どこに書く」などでトリガー。kudo-project-state-recovery／kudo-context-routingと連携、状態再構成時はWorkFlowyダイジェストを最優先参照。WorkFlowy書込・読込ルールの実体は本スキル§運用ルールSSOTが正本。v3.2（2026-05-15・集中原則）§7 保存先表に _claude_workspace_global/ を最上位カテゴリとして追記、基本思想表も二層化対応。"
./.claude/skills/kudo/kudo-workflowy-double-save/SKILL.md:152:- 詳細は `CLAUDE.md §3.2` / `kudo-context-routing §1.3 二層ワークスペース規範`
./.claude/skills/kudo/kudo-workflowy-double-save/SKILL.md:373:### kudo-context-routing との連携
./.claude/skills/kudo/kudo-workflowy-double-save/SKILL.md:375:- `kudo-context-routing` v1.0 が新規案件の経路設計を担う
./.claude/skills/kudo/kudo-workflowy-double-save/SKILL.md:489:- **v3.2（2026-05-15・集中原則ガバナンス Phase 3 Part B-6）**：§運用ルール SSOT §7「Cowork/Codeセッション終了時の記録ルーティン」の「保存先」項目を集中原則 3 分岐版に改訂（global / 案件直下 / 要相談）。基本思想「保存先の役割分担」表に **`_claude_workspace_global/`（最上位カテゴリ）** と **クライアント案件直下 `_claude_workspace/`** の 2 行を追加。カテゴリ判定ガイドを表末尾に新設し `CLAUDE.md §3.2` / `kudo-context-routing §1.3 二層ワークスペース規範` を参照。Phase 2 grep 監査 Pattern 5（保存先キーワード 3 hits）の解消。
./.claude/skills/kudo/kudo-workflowy-double-save/SKILL.md:492:- **v3.0（2026-04-27）**：**SSOT再配置の一環として、本スキルがWorkFlowy統合運用ルールの一次ソース（SSOT）に昇格**。個人設定 項目14（旧CLAUDE.md §4）から本体プロトコル7サブセクションを完全移植し、§運用ルール SSOT を新設。すべての関連スキル・scheduled tasks・PROJECT-CLAUDE.md・個人設定は本セクションを参照ポインタで指す。本スキル外でのID・パス重複記述を禁止。番号変更耐性のため「kudo-workflowy-double-save §運用ルール SSOT §X」形式の参照を標準化。kudo-context-routing との連携を追加。案件キーワードリストにミツカン・TOHAKU・SmartNews・YAMAP・Textを追加（2026-04-27の命名統一実践を反映）。
./.claude/skills/kudo/kudo-context-routing/SKILL.md:2:name: kudo-context-routing
./.claude/skills/kudo/kudo-context-routing/SKILL.md:6:# kudo-context-routing v1.2
./.claude/skills/kudo/kudo-context-routing/SKILL.md:13:- 本スキル `kudo-context-routing`：**経路設計**（どう呼び出すか・どう連動させるか）
./.claude/skills/kudo/kudo-skill-tree-ssot-map/SKILL.md:220:### kudo-context-routing (root)
./.claude/skills/kudo/kudo-skill-tree-ssot-map/SKILL.md:378:| kudo-context-routing | naming-rule | 命名規則の統一ルール（核心） |
./.claude/skills/kudo/kudo-skill-tree-ssot-map/SKILL.md:379:| kudo-context-routing | four-routes | 4経路の役割分担 |
./.claude/skills/kudo/kudo-skill-tree-ssot-map/SKILL.md:380:| kudo-context-routing | route-selection | 経路選択ルール（4段階） |
./.claude/skills/kudo/kudo-skill-tree-ssot-map/SKILL.md:381:| kudo-context-routing | no-state-tag-hierarchy | 状態タグ階層を作らない原則（v1.2新設・2026-05-07） |
./.claude/skills/kudo/kudo-skill-tree-ssot-map/SKILL.md:382:| kudo-context-routing | project-claude-md-placement | PROJECT-CLAUDE.md の配置原則 |
./.claude/skills/kudo/kudo-skill-tree-ssot-map/SKILL.md:383:| kudo-context-routing | new-project-checklist | 新規案件発足時のチェックリスト |
./.claude/skills/kudo/kudo-naming-unification-protocol/SKILL.md:453:### 7-4. kudo-context-routing との連携
./.claude/skills/kudo/kudo-naming-unification-protocol/SKILL.md:455:新規案件着手時に kudo-context-routing が起動される際、本プロトコルの aliases 辞書を参照して 4経路（WorkFlowy ／クラウド ／ claude.ai Project ／ファイル名）の現状を fuzzy search する。
./.claude/skills/kudo/kudo-naming-unification-protocol/SKILL.md:528:- Slack Webhook URL 設定（kudo-context-routing 経由）
./.claude/skills/kudo/kudo-naming-unification-protocol/SKILL.md:535:- `kudo-context-routing`：新規案件着手時に本スキルの aliases を参照
./.claude/skills/kudo/kudo-html-publish/SKILL.md:70:  - kudo-context-routing#_claude_workspace
./.claude/skills/kudo/kudo-html-publish/SKILL.md:452:| kudo-context-routing | 配置先、`_claude_workspace/03_output/` |
./03-Resources/research/STRATEGY-stage1c-roadmap-revision.md:88:       │       ・kudo-context-routing
./CLAUDE.md:28:- `kudo-context-routing` ← Vault フォルダ構造を本ファイルから参照

B-3. `kudo-shared-storage-protocol` への参照¶

参照ファイル数：11 件
参照行数：21 行
anchor 別カウント（kudo-shared-storage-protocol#xxx 形式）：

1 kudo-shared-storage-protocol#confidentiality

和文セクション直接参照（§...）：6 件 → 改訂時に anchor 化が必要な候補（リサーチレポート設計判断 4 対応）
裸の参照（anchor なし・スキル名のみ）：約 20 件（heuristic）

参照ファイル一覧¶

./.claude/skills/kudo/kudo-ai-error-watchlist/SKILL.md
./.claude/skills/kudo/kudo-persist-settings/SKILL.md
./.claude/skills/kudo/kudo-proposal-deck/SKILL.md
./.claude/skills/kudo/kudo-schedule-budget/SKILL.md
./.claude/skills/kudo/kudo-shared-storage-protocol/SKILL.md
./.claude/skills/kudo/kudo-skill-tree-ssot-map/SKILL.md
./.claude/skills/kudo/kudo-workflowy-double-save/SKILL.md
./03-Resources/research/STRATEGY-stage1c-roadmap-revision.md
./AI-ACCESS.md
./CLAUDE.md
./memory/decisions/2026-05-18-kudo-vault-stage0-setup.md

参照行 verbatim¶

./memory/decisions/2026-05-18-kudo-vault-stage0-setup.md:64:- ただし **Chat / Cowork からの WorkFlowy 到達性は環境依存**（Code/Desktop/Gemini からは到達可、Chat からは不能）— この事実を Stage 1 で `kudo-shared-storage-protocol` に明記予定。
./memory/decisions/2026-05-18-kudo-vault-stage0-setup.md:100:- **Drive sync 欠落 3 件**：Stage 1-A 棚卸しで判明。`kudo-ai-error-watchlist` ／ `kudo-mac-health-check` ／ `kudo-shared-storage-protocol` が snapshot mirror にしかない（Drive sync の機能不全）。Stage 1-B で復元
./memory/decisions/2026-05-18-kudo-vault-stage0-setup.md:138:- `kudo-shared-storage-protocol` に以下を追記：
./memory/decisions/2026-05-18-kudo-vault-stage0-setup.md:160:- `kudo-shared-storage-protocol` に「マルチAI接続マトリクス」状態管理項目を新設し、issue closed → Stage 2 着手の状態遷移を記録
./.claude/skills/kudo/kudo-persist-settings/SKILL.md:196:| **【1次】一次ソース** | 実体・ID・固有値・ルール本体 | `kudo-workflowy-double-save §運用ルール SSOT`（WorkFlowy・v3.0 で CLAUDE.md §4 から昇格）／kudo-brand-tokens.json（デザイントークン）／`kudo-shared-storage-protocol §5.5`（集中原則）／`CLAUDE.md §3 / §4.3`（保存先パス規律・状態再構成読込順位） |
./.claude/skills/kudo/kudo-persist-settings/SKILL.md:213:| GitHub Gist運用 | **`kudo-shared-storage-protocol §7`（機密と Gist の使い分け）＋個人設定13** | 各SKILL.md |
./.claude/skills/kudo/kudo-persist-settings/SKILL.md:214:| Google Drive保存ルール | **`kudo-shared-storage-protocol §5.5`（集中原則ガバナンス）** | 各SKILL.md |
./.claude/skills/kudo/kudo-persist-settings/SKILL.md:278:- **集中原則 SSOT（v3.8 新設・2026-05-15）**：`kudo-shared-storage-protocol v1.2 §5.5`（マスター名簿 / HANDOFF / レポート / 中間成果物の格納先 SSOT・`~/working/_claude_workspace_global/` 配下集中原則）
./.claude/skills/kudo/kudo-persist-settings/SKILL.md:1088:- v3.8（2026-05-15・集中原則ガバナンス Phase 3 Part B-7）：§設定ファイル所在マップ SSOT の **【真の正本（編集する場所）】リスト**に 4 項目追加—**ローカル CLAUDE.md**（Phase 3 Part A で新設した `~/.claude/CLAUDE.md`）／**集中原則 SSOT**（`kudo-shared-storage-protocol v1.2 §5.5`）／**case-横断作業ハブ**（`~/working/_claude_workspace_global/`）／**マスター名簿**（`master-lists/` への global 集約）。§Step 7 SSOT形骸化検出プロトコルの判定マトリクスに **「参照腐敗フラグ」**を新規追加（CLAUDE.md 不在で 8 スキル参照が空振りしていた Phase 2 監査の発見を恒久的プロトコル化）。よくあるトラップにも該当エントリを追記。
./.claude/skills/kudo/kudo-shared-storage-protocol/SKILL.md:2:name: kudo-shared-storage-protocol
./.claude/skills/kudo/kudo-shared-storage-protocol/SKILL.md:8:# kudo-shared-storage-protocol v1.0
./.claude/skills/kudo/kudo-schedule-budget/SKILL.md:15:  2. `kudo-shared-storage-protocol §5.5`（生成物の集中原則・保存先パス規律）／`kudo-naming-unification-protocol §6`（NFC/NFD・全角カッコ統一）／`kudo-context-routing §1.3`（二層ワークスペース）（旧 CLAUDE.md §3 集約索引）
./.claude/skills/kudo/kudo-proposal-deck/SKILL.md:15:  2. `kudo-shared-storage-protocol §5.5`（生成物の集中原則・保存先パス規律）／`kudo-naming-unification-protocol §6`（NFC/NFD・全角カッコ統一）／`kudo-context-routing §1.3`（二層ワークスペース）（旧 CLAUDE.md §3 集約索引）
./.claude/skills/kudo/kudo-proposal-deck/SKILL.md:728:**保存先・マウント運用・NFC/NFD対策・present_filesのフォールバック挙動は、保存先・マウント運用は `kudo-shared-storage-protocol §5.5`／NFC/NFD は `kudo-naming-unification-protocol §6`／二層ワークスペースは `kudo-context-routing §1.3`／Coworkビューワー挙動・present_filesフォールバックは CLAUDE.md §3（Code 環境集約索引）が一次ソース**。本スキルではハードコードしない。
./.claude/skills/kudo/kudo-workflowy-double-save/SKILL.md:122:- **保存先**：以下のカテゴリから選択（集中原則ガバナンス `kudo-shared-storage-protocol v1.2 §5.5` / `CLAUDE.md §3.1` 準拠）：
./.claude/skills/kudo/kudo-ai-error-watchlist/SKILL.md:363:  - `kudo-shared-storage-protocol`：3 環境共通の credentials 取り扱い規律として §機密の扱い に短く参照を入れる候補。
./.claude/skills/kudo/kudo-skill-tree-ssot-map/SKILL.md:268:### kudo-shared-storage-protocol (root)
./AI-ACCESS.md:48:- Stage 1 で `kudo-shared-storage-protocol` に「vendor-neutral memory原則」として正式記載予定。
./03-Resources/research/STRATEGY-stage1c-roadmap-revision.md:89:       │       ・kudo-shared-storage-protocol
./CLAUDE.md:29:- `kudo-shared-storage-protocol` ← 機密情報の扱いを本ファイルから参照
./CLAUDE.md:496:機密情報の正本は各案件の `_claude_workspace/`(Vault 外・個人設定項目 15 の集中原則の対象外)に置く。詳細は `kudo-shared-storage-protocol#confidentiality`。

B-4. `kudo-project-state-recovery` への参照¶

参照ファイル数：7 件
参照行数：22 行
anchor 別カウント（kudo-project-state-recovery#xxx 形式）： ※ 既存の anchor 形式参照なし（リネーム時に新 anchor を設計する余地あり）
和文セクション直接参照（§...）：0 件
裸の参照（anchor なし・スキル名のみ）：約 22 件（heuristic）

参照ファイル一覧¶

./.claude/skills/kudo/kudo-autonomous-execution-protocol/SKILL.md
./.claude/skills/kudo/kudo-cowork-code-handoff-protocol/SKILL.md
./.claude/skills/kudo/kudo-persist-settings/SKILL.md
./.claude/skills/kudo/kudo-project-state-recovery/SKILL.md
./.claude/skills/kudo/kudo-skill-tree-ssot-map/SKILL.md
./.claude/skills/kudo/kudo-workflowy-double-save/SKILL.md
./03-Resources/research/STRATEGY-stage1c-roadmap-revision.md

参照行 verbatim¶

./.claude/skills/kudo/kudo-persist-settings/SKILL.md:138:  - kudo-project-state-recovery v1.4（目的語：長期プロジェクトの状態再構成）
./.claude/skills/kudo/kudo-persist-settings/SKILL.md:147:**現時点のスキル総数（2026-04-26 SSOT化改訂後）**：工藤ツリー管理対象 **合計31本**（稼働中30本＋廃止1本→削除予定）。kudo-persist-settings v2.0／kudo-workflowy-double-save v2.1／kudo-project-state-recovery v1.4 がSSOT化改訂で同時更新（2026-04-26）。kudo-sync-cycleは2026-04-26で完全削除指示済み。Anthropic built-in 9本はツリー管理対象外。
./.claude/skills/kudo/kudo-persist-settings/SKILL.md:259:本プロトコル新設の契機：2026-04-26の工藤さんからの問題提起。「個別Skillに参照場所をハードコードするスタイルは、今後の構築を邪魔しないか？PPTXのデザイン規定のように、CLAUDE.md（個人設定・メモリ）に集約する方が良いのでは」との指摘を受け、同日中に本プロトコルを新設。同日、CLAUDE.md §4のSSOT化、kudo-persist-settings v2.0／kudo-workflowy-double-save v2.1／kudo-project-state-recovery v1.4／kudo-skill-extraction v1.1 のハードコード除去を一括実施。
./.claude/skills/kudo/kudo-persist-settings/SKILL.md:1102:- **v2.0（2026-04-26）**：**ハードコード禁止原則と3層分離**を新設。WorkFlowy統合のSSOT化（CLAUDE.md §4一元化）に伴い、本スキル内のID実体記述を§4参照に置換。kudo-workflowy-double-save v2.1／kudo-project-state-recovery v1.4／kudo-skill-extraction v1.1 と同時改訂。全プロトコル実行順にハードコード禁止チェックを追加。
./.claude/skills/kudo/kudo-project-state-recovery/SKILL.md:2:name: kudo-project-state-recovery
./.claude/skills/kudo/kudo-project-state-recovery/SKILL.md:6:# kudo-project-state-recovery v1.4
./.claude/skills/kudo/kudo-autonomous-execution-protocol/SKILL.md:42:- kudo-project-state-recovery（状態再構成）：**帰還後の**文脈復旧が担当。本スキルは**離席時の**委任設計が担当
./.claude/skills/kudo/kudo-autonomous-execution-protocol/SKILL.md:271:7. ★仮説：本スキルの独立性（kudo-project-state-recovery と統合すべきか）
./.claude/skills/kudo/kudo-cowork-code-handoff-protocol/SKILL.md:305:- kudo-project-state-recovery：セッションまたぎの状態再構成（このスキルと併用で長期プロジェクトの引き継ぎ完成）
./.claude/skills/kudo/kudo-workflowy-double-save/SKILL.md:3:description: "工藤拓真のChat活動を三重保存（Claudeメモリ・プロジェクトファイル・WorkFlowy）で自動アーカイブする統合運用スキル＋WorkFlowy統合運用ルールの一次ソース（SSOT）。動詞群5（Skillを管理する）所属。v3.0で個人設定からプロトコル本体を完全移植しSSOTに昇格、v3.1で§1.1〜§1.3を新設し書込先4カテゴリ分類（A.当日フロー系／B.案件横断・システムログ系／C.案件別蓄積系／D.中長期ストック系）と命名規則・complete扱いを完全規定。「議事録残して」「WorkFlowyに書いて」「ダイジェスト作って」「タスク失敗してる」「daily-chat-digest失敗」「失敗検知」「親IDロック」「noteフィールド禁止」「読込先優先順位」「書込み前チェックリスト」「重複セクション防止」「Cowork記録ルーティン」「同期」「キャッチアップ」「引き継ぎメモ」「これまでの話まとめ」「夜間バッチ動いてない」「書込先カテゴリ」「書込先統一」「4カテゴリ分類」「ストック系どこに書く」などでトリガー。kudo-project-state-recovery／kudo-context-routingと連携、状態再構成時はWorkFlowyダイジェストを最優先参照。WorkFlowy書込・読込ルールの実体は本スキル§運用ルールSSOTが正本。v3.2（2026-05-15・集中原則）§7 保存先表に _claude_workspace_global/ を最上位カテゴリとして追記、基本思想表も二層化対応。"
./.claude/skills/kudo/kudo-workflowy-double-save/SKILL.md:68:| **C. 案件別蓄積系** | **残す（案件アーカイブ）** | 案件ノード傘下に日付付きで蓄積、状態再構成（kudo-project-state-recovery）の最優先参照ソース |
./.claude/skills/kudo/kudo-workflowy-double-save/SKILL.md:310:`daily-chat-digest-2330` および `daily-chat-digest-0800-backup` の両方が失敗すると、その日のチャット会話がWorkFlowyに書き込まれず、`kudo-project-state-recovery` の「最優先参照ソース」が空欄のまま放置される。状態再構成精度に直撃する。
./.claude/skills/kudo/kudo-workflowy-double-save/SKILL.md:367:### kudo-project-state-recovery との連携
./.claude/skills/kudo/kudo-workflowy-double-save/SKILL.md:369:- `kudo-project-state-recovery` v1.4 の「状態再構成」において、**まずWorkFlowy上のダイジェストを優先参照**する
./.claude/skills/kudo/kudo-workflowy-double-save/SKILL.md:493:- **v2.1（2026-04-26）**：§失敗検知プロトコル新設（daily-chat-digest連続失敗の自動検知）／ハードコード除去（書込先ID・禁止ノード名の実体記述を削除しCLAUDE.md §4参照に統一）／kudo-persist-settings v2.0 のハードコード禁止原則に準拠／kudo-project-state-recovery v1.4 と連携明示／kudo-sync-cycle 完全削除指示と連動。
./.claude/skills/kudo/kudo-workflowy-double-save/SKILL.md:494:- **v2.0（2026-04-18）**：旧 `kudo-sync-cycle` v1.0を完全吸収／三重保存アーキテクチャを確立／Cowork夜間バッチ（`daily-chat-digest-2330`）との連携を前提化／案件キーワードリストを初期整備／`kudo-project-state-recovery` との連携を明文化。
./.claude/skills/kudo/kudo-skill-tree-ssot-map/SKILL.md:263:### kudo-project-state-recovery (root)
./.claude/skills/kudo/kudo-skill-tree-ssot-map/SKILL.md:497:| kudo-project-state-recovery | recovery-priority | 状態再構成の優先順位（v1.4改訂・2026-04-26） |
./.claude/skills/kudo/kudo-skill-tree-ssot-map/SKILL.md:498:| kudo-project-state-recovery | part-a-read | PART A：状態再構成プロトコル（読む側） |
./.claude/skills/kudo/kudo-skill-tree-ssot-map/SKILL.md:499:| kudo-project-state-recovery | part-b-write | PART B：引き継ぎメモ生成プロトコル（書く側） |
./.claude/skills/kudo/kudo-skill-tree-ssot-map/SKILL.md:500:| kudo-project-state-recovery | part-c-no-retreat | PART C：過剰撤退禁止原則 ── v1.2新設【最重要】 |
./03-Resources/research/STRATEGY-stage1c-roadmap-revision.md:90:       │       ・kudo-project-state-recovery

Task C：前提確認¶

C-1. `00-Inbox/workflowy-import/` の現状¶

状態：ディレクトリ存在
パス：/Users/kudotakuma/KUDO-Vault/00-Inbox/workflowy-import
ファイル数：0
中身：空（Stage 0 で作成された skeleton。kudo-process-inbox（将来スキル）の取込先として待機中）

C-2. Cowork scheduled-tasks の状態¶

Code 側から直接アクセス不能（Cowork MCP 経由・Cowork 側で管理）。ローカル LaunchAgent には Cowork tasks の代理は存在しない。Stage 1-C 着手準備 §A-6 と同じ結論。

ローカルで存在を確認できるのは以下のみ（Cowork tasks ではなく Code 側 cron）：

1306    0   application.com.workflowy.desktop.181552998.181553004
1765    0   com.kudotakuma.typeless-mic
1760    0   com.kudo.meeting-watcher
-   0   com.kudo.regenerate-brand-tokens-css
-   0   com.kudo.stage1b2-pilot-observer
-   0   com.kudo.validate-naming-consistency
76915   0   com.workflowy.desktop.ShipIt
-   0   com.kudo.skills-snapshot
-   0   com.kudo.validate-design-tokens
-   0   com.kudo.regenerate-ssot-map

→ Cowork dailyタスク群（daily-chat-digest-2330 等）の最終実行時刻・現状の生死は Cowork セッションで mcp__scheduled-tasks__list_scheduled_tasks 実行で確認要。改訂版起草では「現状維持／一時停止」の判断を保留 → Chat と工藤氏で別途決定。

C-3. Git 状態¶

$ git status --short
(working tree clean)

$ git log --oneline -10
f73d74b add watchlist entry: PAT leak via screenshot (Stage 1-C-1 D-5/5)
af99b5c add: DESIGN-47-skill-health-review (Stage 1-C-1 D-4/5)
dd7776a add: DESIGN-kudo-triple-store-write-revision (Stage 1-C-1 D-3/5)
37d6ac5 add: RESEARCH-skill-ecosystem-target-architecture-v1.1 (Stage 1-C-1 D-2/5)
eca8509 add: STRATEGY-stage1c-roadmap-revision (Stage 1-C-1 D-1/5)
74d4420 expand CLAUDE.md to vault write-rules SSOT (Stage 1-C-1)
227f15b gitignore: exclude *.bak.* (Stage 1-C-1 pre-flight)
86b6216 harden gitignore before initial push
02e0149 Stage 1-B Phase 1: Pre-copy R23 skills to Vault (non-destructive)
711478c Stage 1-B Task 1: Copy M24 skills to Vault (non-destructive)

$ git remote -v
origin  https://github.com/kudotakuma/KUDO-Vault.git (fetch)
origin  https://github.com/kudotakuma/KUDO-Vault.git (push)

working tree clean ✅
master branch、push 待ち：Stage 1-C-1 由来の 7 commits（227f15b → f73d74b、ただし user 申告では cd ~/KUDO-Vault && git push 1 回実行済み想定）
remote origin：https://github.com/kudotakuma/KUDO-Vault.git（HTTPS）
Stage 1-C-2 着手前のクリーンな状態 ✅

Task D-2：Chat 起草方針への矛盾指摘¶

HANDOFF §D-2 の 4 スキル改訂方針サマリと、実機（A-1〜A-4 verbatim ＋ B 被参照マップ）の照合結果。

矛盾指摘 1：`kudo-workflowy-double-save` の `parent: null` 仮定について¶

HANDOFF §D-2 では「frontmatter フル整備（parent: null、version: 4.0、anchors: 列挙）」と書かれている。実機の SKILL.md 冒頭 frontmatter は name と description の 2 フィールドのみ（minimal）。

parent: フィールド自体が存在しない → 改訂時に parent: null を新規追加することになる（既存値の維持ではない）
version: も同様。本文 line 6 に # kudo-workflowy-double-save v3.2 とあるのを frontmatter に昇格する作業
動詞群5（Skillを管理する）所属は description 内のテキストにのみ記載。verb_group: フィールドへの昇格も同時実施推奨（CLAUDE.md §4.2 skill frontmatter 規則に整合）

→ Chat 起草時：「フィールドが既にある」前提を捨て、ゼロから書く。Stage 1-A2 で kudo-ai-error-watchlist / kudo-mac-health-check / kudo-shared-storage-protocol に frontmatter 補完した経験が直接活きる。

矛盾指摘 2：`#operating-rules` への参照 12 件 — リネーム時の anchor 維持必須¶

HANDOFF §D-2 では「anchors 列挙」とあるが、被参照マップ B-1 で確認した通り kudo-workflowy-double-save#operating-rules への参照が 12 件（Vault 内）。

リネーム後の新スキル kudo-triple-store-write でも、symbolic anchor operating-rules を維持することが必須
12 件の参照を一括置換するとき、参照側の anchor 名は変えず、スキル名だけ置換するのが最小変更
同様に #failure-detection（1 件）も維持必須
これは旧 anchor を新 frontmatter anchors: セクションでそのまま列挙すれば良い（実装ヘッダタイトルは変えても anchor_id は不変、CLAUDE.md §5.2 「アンカー参照」原則と整合）

矛盾指摘 3：和文セクション直接参照 19 件 — リネーム同時に anchor 化¶

被参照マップ B-1 で「§運用ルール SSOT」等の和文セクション直接参照が 19 件。

HANDOFF §D-2 では明示されていないが、リネーム時にこの 19 件も #operating-rules または #operating-rules-§1 等の anchor 参照に置換するのが効率的（一回の作業で全部直す）
DESIGN-kudo-triple-store-write-revision §横展開（リサーチレポート v1.1 の腐敗パターン 1 前段階）の対処そのもの
置換は機械的に難しい（『§運用ルール SSOT §1』『§運用ルール SSOT §4』『§運用ルール』等の表記揺れあり）→ 個別精査が必要、Chat 起草の改訂版 SKILL.md と並行して被参照 19 件を 1 件ずつ確認

軽微な指摘 4：Cowork タスク群（C-2 関連）の改訂版での扱い¶

HANDOFF §D-2 の kudo-triple-store-write 改訂方針に「Cowork 夜間バッチの最終的な書込先再設計は Stage 2 の Cowork/Chat 接続検証の結果を待つ」とある。

現状の SKILL.md は §5「失敗検知プロトコル」（line 101-）、本文「失敗検知プロトコル詳細」（line 306-361）等で daily-chat-digest 等の固有名を多数含む
改訂版で「Cowork 夜間バッチ → Vault 直接書込」が実現不可なら、これらの記述はどう書き換えるか:
(a) 現状維持し「Stage 2 検証待ち」と明記
(b) Cowork 部分を §別アンカーに分離（リサーチレポート腐敗パターン 7「ツール依存とプロトコル定義の混在」回避）
(b) を採用するとリサーチレポートが示唆する「プロトコル定義 / 実装の分離」の最初のデモンストレーションになる。Chat 判断

軽微な指摘 5：個人設定との関係（HANDOFF §B-3 と整合）¶

HANDOFF §B-3 で「kudo-workflowy-double-save は個人設定項目4・項目14 から参照」と Chat が想定している。Code 側からは個人設定の現物を確認できないが、被参照マップ B-1 の 21 ファイル中、個人設定からの参照は当然含まれない（Vault 外）。

個人設定改訂行の特定・提示は Chat の責任範囲
Code 側の改訂作業は Vault 内 SKILL.md と他スキル参照の更新まで
個人設定改訂は工藤さんが claude.ai UI で手作業（kudo-persist-settings v3.10 §新版追加プロトコルに従う）

工藤さん・Chat への申し送り¶

1. Stage 1-C-2 改訂順序の確認¶

HANDOFF §8 の通り：

kudo-workflowy-double-save → kudo-triple-store-write（リネーム＋全面改訂）— 最重要・最大、被参照 21 ファイル
kudo-context-routing — 被参照 14 ファイル
kudo-shared-storage-protocol — 被参照 11 ファイル
kudo-project-state-recovery — 被参照 7 ファイル

被参照件数の小さい順（4 → 3 → 2 → 1）も検討余地あり：影響範囲を段階的に拡げ、各回でリスク制御。ただし 1 を最後にすると Stage 1-C-2 全体の到達点が後ずれする。Chat 判断。

2. 個人設定改訂該当行の特定¶

HANDOFF §B-3 で言及された個人設定項目4（WorkFlowy 参照ルール）・項目14（主要スキル直接参照）の改訂該当行は Chat 起草の担当範囲。Code は Vault 内 SKILL.md のみ。

3. Cowork tasks の現状把握（並走可能）¶

Code 範囲外。次の Cowork セッションで mcp__scheduled-tasks__list_scheduled_tasks 実行を依頼。Stage 1-C-2 改訂版起草と並行で実行可能。

4. 改訂版 SKILL.md の Code 受領経路¶

Stage 1-C-1 で確立した「Chat 直貼り → Code が Write で配置 → git add/commit、push は工藤さん」の経路を継続。present_files 不要。

5. 申し送り：本日の push 状態¶

Stage 1-C-1 完了時点の 7 commits（227f15b → f73d74b）が user 申告では push 済み想定。Code 側からは確実な remote 状態は確認不能（私の bash subprocess に PAT credentials がない）。Stage 1-C-2 改訂が始まる前に、工藤さん側で GitHub web で commit 履歴の最新が f73d74b であることを 1 度視認推奨。

ファイル一覧¶

新規作成¶

~/working/_claude_workspace_global/reports/stage1c-2-prep-2026-05-21.md（本ファイル）

変更なし（非破壊保証）¶

すべての対象 SKILL.md（読取のみ）
Vault git 状態（HEAD 不変）
skills-plugin / Drive ミラー / LaunchAgent
個人設定・memory（Code 範囲外）

Stage 1-C-2 prep 完了報告¶

結論¶

Task A：4 スキルの現状 verbatim¶

A-1. kudo-workflowy-double-save¶

メタ情報¶

frontmatter 抜粋¶

本文セクション構造¶

SKILL.md 全文（verbatim）¶

A-2. kudo-context-routing¶

メタ情報¶

frontmatter 抜粋¶

本文セクション構造¶

SKILL.md 全文（verbatim）¶

A-3. kudo-shared-storage-protocol¶

メタ情報¶

frontmatter 抜粋¶

本文セクション構造¶

SKILL.md 全文（verbatim）¶

A-4. kudo-project-state-recovery¶

メタ情報¶

frontmatter 抜粋¶

本文セクション構造¶

SKILL.md 全文（verbatim）¶

Task B：被参照マップ（4 件全件）¶

B-1. kudo-workflowy-double-save への参照¶

参照ファイル一覧¶

参照行 verbatim¶

B-2. kudo-context-routing への参照¶

参照ファイル一覧¶

参照行 verbatim¶

B-3. kudo-shared-storage-protocol への参照¶

参照ファイル一覧¶

参照行 verbatim¶

B-4. kudo-project-state-recovery への参照¶

参照ファイル一覧¶

参照行 verbatim¶

Task C：前提確認¶

C-1. 00-Inbox/workflowy-import/ の現状¶

C-2. Cowork scheduled-tasks の状態¶

C-3. Git 状態¶

Task D-2：Chat 起草方針への矛盾指摘¶

矛盾指摘 1：kudo-workflowy-double-save の parent: null 仮定について¶

矛盾指摘 2：#operating-rules への参照 12 件 — リネーム時の anchor 維持必須¶

矛盾指摘 3：和文セクション直接参照 19 件 — リネーム同時に anchor 化¶

軽微な指摘 4：Cowork タスク群（C-2 関連）の改訂版での扱い¶

軽微な指摘 5：個人設定との関係（HANDOFF §B-3 と整合）¶

工藤さん・Chat への申し送り¶

1. Stage 1-C-2 改訂順序の確認¶

2. 個人設定改訂該当行の特定¶

3. Cowork tasks の現状把握（並走可能）¶

4. 改訂版 SKILL.md の Code 受領経路¶

5. 申し送り：本日の push 状態¶

ファイル一覧¶

新規作成¶

変更なし（非破壊保証）¶

A-1. `kudo-workflowy-double-save`¶

A-2. `kudo-context-routing`¶

A-3. `kudo-shared-storage-protocol`¶

A-4. `kudo-project-state-recovery`¶

B-1. `kudo-workflowy-double-save` への参照¶

B-2. `kudo-context-routing` への参照¶

B-3. `kudo-shared-storage-protocol` への参照¶

B-4. `kudo-project-state-recovery` への参照¶

C-1. `00-Inbox/workflowy-import/` の現状¶

矛盾指摘 1：`kudo-workflowy-double-save` の `parent: null` 仮定について¶

矛盾指摘 2：`#operating-rules` への参照 12 件 — リネーム時の anchor 維持必須¶