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（観察デザイナー層）

判定フロー：

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

§運用ルール 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 書込み前チェックリスト（毎回実行）¶

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

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

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

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

§運用ルール 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には昨日の全活動が案件別に並んでいる。

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

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

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

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

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

Claudeが議事録を生成（フォーマットは後述）
プロジェクトファイルに .md 保存（minutes/YYYY-MM-DD_案件名.md）
WorkFlowy貼付用ブロック（コピペ可能形式）を出力
「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は以下を順に確認：

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

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

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

違反時の挙動¶

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

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

トリガー時の確認事項¶

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

何を残すか：今のセッション全体の議事録か、特定トピックの議事録か
どの案件に紐づくか：自動分類か、工藤さんが指定するか
どこに書くか：プロジェクトファイルだけか、WorkFlowyにも流すか（ただしWorkFlowy書き込みはCowork経由）
§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に書き込みます」と伝達

出力フォーマット例¶

# 議事録: [案件名] (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）：廃止。