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 §失敗検知プロトコル（v3.0 で kudo-workflowy-double-save §運用ルール SSOT §5 へ昇格）に従い、scheduled tasks の連続失敗をチェックする。連続失敗が確認された場合は、優先度1のダイジェストが当日分を欠いている可能性が高いため、優先度4（conversation_search）の比重を上げる。

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

4つの鉄則¶

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

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

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

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

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

書き込み先・形式は kudo-workflowy-double-save §運用ルール SSOT が一次ソース（v3.0 で 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 §失敗検知プロトコルとの連動明示