kudo-persist-settings v3.8¶

会話で生まれた「ルール・方針・好み・運用の合意」を、次回以降のセッションに確実に引き継ぐためのスキル。

なぜこのスキルが必要か¶

Claudeはセッションをまたいだ自動記憶を持たない。会話で合意した内容は、明示的にどこかに書き込まなければ消える。このスキルは「消えるはずの合意」を検知して、適切な永続化先に書き込むまでを一貫して担う。

トリガー判定：何を「永続化すべき合意」とみなすか¶

以下のどれかに該当すれば、即座に永続化提案を行う：

「今後は〜してほしい」「毎回〜で」「常に〜」という依頼
「この方針を覚えておいて」「忘れないで」「設定として残して」
「記憶の仕組みは？」「どう引き継がれる？」という質問（＝永続化への関心の表れ）
ツールの使い方・作業の進め方・アウトプット形式に関する新しいルールが決まった
特定のクライアント案件に関して「いつもこう扱って」という指示が出た

永続化先の選択基準¶

合意の種類	書き込み先	理由
全セッション共通の行動ルール（ツール使い方、出力形式、言葉遣い等）	CLAUDE.md	毎回自動で読み込まれる最強の記憶
特定案件・クライアントに関する方針	WorkFlowy「[1日1新およびToDo]」傘下の該当案件ノード	セッション開始時に参照するハブ
一時的なメモ・今日のToDo	WorkFlowy「[1日1新およびToDo]」	短期記憶として機能

WorkFlowyの書込ルール詳細は kudo-workflowy-double-save §運用ルール SSOT を参照すること。 親IDロック・noteフィールド禁止・読込先優先順位・書込み前チェックリスト・失敗検知・重複セクション防止のすべてのルールは本 SSOT が一次ソース（v3.0 で CLAUDE.md §4 から本スキルへ昇格・実体移植済）。本スキルは参照ポインタとして機能し、IDやパスの実体記述を持たない（ハードコード禁止原則・後述）。

実行手順¶

Step 1：合意内容を一文で整理する¶

ユーザーに確認する前に、合意の核心を自分で一文にまとめる。

例：「コンピューター直接操作はUIを触らないとできない場合のみ。ターミナルで完結するものはコマンドを提示する。」

Step 2：永続化先を提案して確認を取る¶

以下のテンプレートで提案する：

この合意、永続化しませんか？

〔合意内容を一文で〕

書き込み先：〔CLAUDE.md ／ WorkFlowy「[1日1新およびToDo]」傘下：案件名〕

「はい」で書き込みます。¶

Step 3：承認後、書き込みを実行する¶

CLAUDE.md への書き込み： - CLAUDE.md を Read で読み込む - 合意内容を適切なセクションに追記する（新規セクションが必要なら作る） - Edit ツールで保存する

WorkFlowy への書き込み： - 詳細手順は kudo-workflowy-double-save §運用ルール SSOT（WorkFlowy統合運用ルールの一次ソース）に従う - 本スキルでIDや禁止ノード名を実体記述しない（ハードコード禁止原則）

Step 4：完了を報告する¶

書き込み完了後、どこに何を書いたかを一言で報告する。

例：「CLAUDE.md の「3. 作業環境」セクション末尾に追記しました。次回以降のすべてのセッションで自動反映されます。」

注意事項¶

承認なしに書き込まない。必ずStep 2の確認を経ること
CLAUDE.md は既存の構造を壊さないよう、Read → 確認 → Edit の順で慎重に編集する
WorkFlowyへの書込ルールは kudo-workflowy-double-save §運用ルール SSOT が一次ソース（v3.0 で CLAUDE.md §4 から本スキルへ昇格）。本スキルはそれを参照するだけ
合意が曖昧なときは、一文にまとめる前にユーザーに「こういう理解でよいですか？」と確認する

persist-settings ガバナンス原則【最終版】¶

スキルガバナンス原則¶

工藤拓真のスキル群は、動詞群（広い動詞）+ 目的語（細目） の2階層で管理される。動詞は動詞群レベルでだけ持ち、各スキルは目的語で識別される。

下記ツリーは現時点のスナップショットであり、スキルの追加・改訂・統廃合があれば必ず更新する。本ツリーはSingle Source of Truthとして機能し、これと矛盾する記述を他所に残してはならない。

動詞群と所属スキル¶

[動詞群1] 戦略や企画を考える
  [親] kudo-mitate（目的語：世の中の現在地と必然性）
    └─ [子] kudo-strategy-houshin（目的語：戦略＝7要素の型）
        ├─ [孫] kudo-marketing-strategy（目的語：マーケ戦略＝STP/4P/CEP）
        ├─ [孫] kudo-brand-architecture（目的語：ブランド構造＝記憶の箱・版木）
        ├─ [孫] kudo-brand-lens（目的語：ブランドの現在地）
        └─ [辞書型孫] kudo-strategist-lens-library（目的語：外部戦略家18名のレンズ辞書）

[動詞群2] ことばをかく
  [親] kudo-writing（目的語：ことばと文章＝短文コピーから書籍執筆まで統合）

[動詞群3] 資料をつくる
  [親] kudo-proposal-deck（目的語：提案資料＝PPTX／HTML／SVG）
    ├─ [子] kudo-briefing（目的語：オリエン・発注シート）
    ├─ [子] kudo-schedule-budget（目的語：スケジュール・予算ページ）
    ├─ [子] kudo-deck-generation-router v1.1（目的語：生成ルート3レーン選択／v1.1で .potx 前処理§1.5 追加・確定版）
    ├─ [子] kudo-deck-aesthetic-qa（目的語：Phase 4審美QA ★仮説v0.9）
    ├─ [子・新設] kudo-client-template-factory（目的語：クライアント別 .potx 量産 v1.0）
    └─ [辞書型孫] kudo-presenter-lens-library（目的語：プレゼンター16名のレンズ辞書）

[動詞群4] ことば以外をつくる
  [親] kudo-design-generation-loop（目的語：生成系ツール4段階プロトコル PRE→GEN→CRIT→FIX）
    ├─ [孫] kudo-logo-craft-protocol（目的語：ロゴ／VI）
    ├─ [孫] kudo-ad-kv-composition（目的語：広告KV／サイトTV）
    ├─ [孫] kudo-motion-kv-composition（目的語：映像／TVCM／SNS動画）
    ├─ [孫] kudo-package-design-protocol（目的語：パッケージ／立体物）
    └─ [孫] kudo-spatial-experience-design（目的語：空間／体験／店舗）
  [辞書スキル] kudo-designer-lens-library（目的語：デザイナー16名のレンズ辞書／5孫全てから参照）
  [下流検証] kudo-design-mockup（目的語：3Dモックアップでタッチポイント検証＋.potx表紙クロスチェック v0.4）
  ~~kudo-design-partners~~（廃止 → kudo-designer-lens-libraryに統合済み／削除推奨）

[動詞群5] Skillを管理する
  - kudo-persist-settings v2.0（目的語：合意事項とスキル運用ガバナンス＋ハードコード禁止原則）※本スキル
  - kudo-skill-extraction（目的語：暗黙知のスキル化プロセス）
  - kudo-workflowy-double-save v2.1（目的語：環境間〔Chat↔WorkFlowy↔Cowork〕の情報同期＋失敗検知）
  - kudo-project-state-recovery v1.4（目的語：長期プロジェクトの状態再構成）
  - kudo-autonomous-execution-protocol（目的語：離席中の自律実行プロトコル ★仮説v0.9）
  - morning-tweet-quotes（目的語：朝のブランディング名言ツイート3案自動生成）
  - ~~kudo-sync-cycle~~（**廃止・完全削除推奨** → kudo-workflowy-double-save v2.0に吸収済／2026-04-26削除指示）

[メタ／横断スキル] 叙述・思考の作法
  - kudo-binary-fusion（目的語：二項融解論法／全スキルから参照される叙述作法）

現時点のスキル総数（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本はツリー管理対象外。

起動ルール¶

子・孫スキルが起動された場合、親をたどってすべての祖先の原則を参照する（子が親を呼ぶ）。

新スキル追加プロトコル¶

Step 0：命名プリフライト（予約語チェック＋役割分離）

新スキルのname:フィールドに書く名前を決めた直後、以下の2段階チェックを必ず通す。

① 予約語チェック（絶対ルール）

現時点で判明している予約語：claude（スキル名に含まれると保存時エラー）
判定方法：スキル名文字列を小文字化したとき、予約語を部分文字列として含まないこと
例：kudo-claude-design-integration → NG／kudo-deck-generation-router → OK

② name／description／本文の役割分離

領域	優先事項	ルール
`name:`フィールド	予約語回避	固有名詞が犠牲になっても予約語を避ける
`description`／本文中	トリガー精度	固有名詞（`Claude Design`／`Claude Code`等）はそのまま保持する

Step 0.5：description 字数事前チェック

詳細は「## 形式制約事前チェック：description 字数＋XMLタグ」セクション参照。description フィールドが1024字以下に収まることを name: 確定の直後と、執筆完了後の 2回チェックする。

Step 1〜5：「動詞群＋目的語」言語化 → 既存重複確認 → 工藤さんに動詞群配置確認 → ツリー更新 → ツリー整合性セルフチェック実行（詳細は2026-04-24既存記述参照）

ハードコード禁止原則と3層分離（2026-04-26新設・v2.0）¶

なぜ必要か¶

スキル間で同じ情報（ID・パス・色コード・フォント名・ノード名・運用ルール）を実体として複数箇所に書く（ハードコード）と、更新コストがO(N)に膨らみ、必ず不整合が発生する。

2026-04-26のWorkFlowy統合運用点検で、8cfc1d50-7222-e2ce-79d0-8fc9faf6a6c2（[1日1新およびToDo]ノードID）が4本のスキルに実体記述されており、ID変更や運用ルール改訂のたびに4本同時更新が必要な状態だった。実際にはCLAUDE.md §4を更新しても3本のSKILL.mdが古い記述のまま残るリスクが顕在化。

工藤さんはPPTXのデザイントークン管理（kudo-brand-tokens.json → 個人設定「デザイン・資料生成ルール」）で既にこの問題を解決済み。同じ構造を全領域に適用する。

3層分離原則¶

設定情報・運用ルール・固有値は以下の3層で管理する：

層	役割	例
【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`（保存先パス規律・状態再構成読込順位）
【2次】サマリ参照	人間用ナビ・要約	個人設定の「デザイン・資料生成ルール」「SSOTマップ」項目
【3次】参照ポインタ	スキル本体内の参照のみ	SKILL.md内に「`kudo-workflowy-double-save §運用ルール SSOT 参照`」等の1行

鉄則： - 一次ソースは 必ず1箇所 に集約する - 二次・三次は一次の 参照ポインタ として機能し、実体記述（ID・パス・色コード等）を持たない - 一次ソースを更新すれば全システムに自動反映される設計を維持する

適用領域¶

以下の領域はすべて3層分離で管理する：

領域	一次ソース	三次ポインタ
WorkFlowy統合運用	`kudo-workflowy-double-save §運用ルール SSOT`（v3.0 で CLAUDE.md §4 から昇格）	各SKILL.md「§運用ルール SSOT 参照」
デザイントークン（カラー・フォント）	kudo-brand-tokens.json	CLAUDE.md §6・個人設定8・各SKILL.md
GitHub Gist運用	CLAUDE.md §3＋個人設定13	各SKILL.md
Google Drive保存ルール	CLAUDE.md §3	各SKILL.md
Slack通知ルール	個人設定（要整備）	各SKILL.md
Chrome操作ルール	CLAUDE.md §7	各SKILL.md

ハードコード許容例外（限定的）¶

以下の場合に限り、SKILL.md本体に実体記述を許容する：

kudo-persist-settings本スキル：動詞群ツリー（スキル名のリスト）は本スキルが一次ソースのため実体記述
テンプレート例：説明用の架空ID（例：<session> のようなプレースホルダ）は実体ではないので可
歴史記述：「2026-04-26にIDを変更した」のような履歴記述は事実記録として可

違反時の挙動¶

スキル新規作成・改訂時、ID・パス・固有値の実体記述を発見した場合：

それが許容例外（上記）に該当するか確認
該当しない場合、一次ソースの場所を特定し、SKILL.md側を「[一次ソースの場所]参照」に書き換える
一次ソースが存在しない場合、CLAUDE.md または個人設定に新規セクションを立ててから参照ポインタ化する

grep検出コマンド（半自動化）¶

スキル改訂時、以下のgrepで残存ハードコードを検出：

# WorkFlowyノードID
grep -rn "8cfc1d50-7222-e2ce-79d0-8fc9faf6a6c2" /mnt/skills/user/

# 過去生成ログノードID
grep -rn "54f53941-7c30-350f-1845-6e5a536ad348" /mnt/skills/user/

# 禁止ノード名の実体列挙
grep -rn "001\.MEMOる\|02\.KEEPする\|03\.何でもarchive" /mnt/skills/user/

検出された箇所はすべて参照ポインタ化対象。kudo-persist-settings本体（許容例外）は除く。

適用タイミング（必須）¶

新規スキル作成時：「新スキル追加プロトコル」Step 5の後、ツリー整合性チェックと並走
既存スキル改訂時：「3軸自己チェックプロトコル」Step 1の前段（メタルール違反チェックの一部として）
CLAUDE.md / 個人設定改訂時：改訂後にgrepで全スキル横断チェック

背景¶

本プロトコル新設の契機：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 のハードコード除去を一括実施。

§設定ファイル所在マップ SSOT（v3.0でSSOT昇格）¶

本セクションが「設定ファイル所在マップ」の唯一の正本（SSOT）。 個人設定からも本セクションを参照する形に再配置（v3.0）。すべてのスキル・補足ドキュメントは「kudo-persist-settings §設定ファイル所在マップ SSOT」で参照する。

なぜ必要か¶

2026-04-26のセッションで、CLAUDE.mdの実体場所を特定するのに30分以上を費やした。原因は「memory/CLAUDE.mdは読取専用キャッシュで、真の正本はAnthropicサーバー側のmcqAnswersに保存されている」という仕組みを最初から把握していなかったため。本プロトコルで再発防止する。

真の正本の場所マップ（2026-04-26調査確定・v3.0でSSOT本体に昇格）¶

CLAUDE.md／個人設定の真の正本は claude.ai > 設定 > 個人設定 で管理される mcqAnswers フィールド（Anthropicサーバー側）。これがセッション起動時に local_xxx.json と memory/CLAUDE.md にキャッシュ展開される。

【真の正本（編集する場所）】 - グローバル指示書（CLAUDE.md相当）の正本：claude.ai > 設定 > 個人設定（mcqAnswers） - ローカル CLAUDE.md（Code 用グローバル行動規範・v3.8 新設・2026-05-15）：~/.claude/CLAUDE.md（Phase 3 Part A で新設。§3 保存先パス規律 / §4 状態再構成・読込ルール を保有。8 スキルが「CLAUDE.md §3 / §4.3 が一次ソース」として参照していたものの実体） - 集中原則 SSOT（v3.8 新設・2026-05-15）：kudo-shared-storage-protocol v1.2 §5.5（マスター名簿 / HANDOFF / レポート / 中間成果物の格納先 SSOT・~/working/_claude_workspace_global/ 配下集中原則） - case-横断作業ハブ（v3.8 新設・2026-05-15）：~/working/_claude_workspace_global/（Drive 同期フォルダ ID: 1EXyQOuWn2tvaBqBnhyeIhAH7Gox3jMsF）。サブフォルダ：master-lists/ handoffs/ reports/ outputs/ - プロジェクト固有指示書：各案件フォルダ内の PROJECT-CLAUDE.md（Google Drive配下／例：claude/claude-reference/PROJECT-CLAUDE.md） - カスタマイズスキル（SKILL.md）：claude.ai > 設定 > カスタマイズ > スキル - カスタマイズスキル（実体ストレージ）：~/Library/Application Support/Claude/local-agent-mode-sessions/skills-plugin/{device-id}/{user-id}/skills/（Code発見・2026-05-07・auto-snapshot.shが日次バックアップする本物の物理ストレージ）／~/.claude/skills/ は空のplaceholderなので注意 - scheduled tasks：Coworkセッション内 mcp__scheduled-tasks - WorkFlowy正本：workflowy.com（[1日1新およびToDo] = ID 8cfc1d50-7222-e2ce-79d0-8fc9faf6a6c2／親IDロックの一次ソースは kudo-workflowy-double-save §運用ルール SSOT §1） - デザイントークン：~/Library/CloudStorage/GoogleDrive-kudotakuma421@gmail.com/マイドライブ/working/claude/claude-reference/design-tokens/kudo-brand-tokens.json - マスター名簿（命名統一）：~/working/_claude_workspace_global/master-lists/naming-master-list-vN.M.xlsx（v3.8 で global 集約）

【読取専用キャッシュ（編集禁止）】 - ~/Library/Application Support/Claude/local-agent-mode-sessions/{user}/{device}/memory/CLAUDE.md（1分以内に再生成される） - ~/Library/Application Support/Claude/local-agent-mode-sessions/{user}/{device}/local_{session}.json（セッション固有・新セッションで上書き） - /var/folders/.../T/claude-hostloop-plugins/.../CLAUDE.md（さらにキャッシュのキャッシュ）

【データフロー】

個人設定（claude.ai > 設定・mcqAnswers）→ サーバー保存 → セッション起動時にlocal_xxx.json展開 → memory/CLAUDE.md展開 → systemPromptに合成 → Claudeが起動時に読む

【L1：真の正本】 claude.ai > 設定 > 個人設定（mcqAnswers）
       ↓ サーバー側永続化
【L2：セッションキャッシュ】 local_xxx.json の mcqAnswers キー（~5KB）
       ↓ 起動時に memory/ へ展開
【L3：ローカルキャッシュ】 ~/Library/.../memory/CLAUDE.md（読取専用・1分以内に再生成）
       ↓ システムプロンプトに注入
【L4：合成プロンプト】 systemPrompt キー（47KB）→ Claude起動時に注入

Step 1：所在マップを最初に確認¶

ユーザーから「○○ファイル探して」「○○の場所」「○○を編集して」と依頼があった時、最初に 本セクション §設定ファイル所在マップ SSOT の所在マップを参照する。記載があればそこに直行。

Step 2：マップにない場合の体系的探索¶

ターミナルで以下を順に実行（macOS環境前提）：

mdfind（Spotlight・最強）：mdfind -name "ファイル名" 2>/dev/null
find（ホームディレクトリ）：find ~ -name "ファイル名" 2>/dev/null
VM mount確認：/sessions/.../mnt/ 配下にあるか
Cowork配下確認：~/Library/Application Support/Claude/ 配下
Google Drive配下確認：~/Library/CloudStorage/GoogleDrive-kudotakuma421@gmail.com/マイドライブ/ 配下

Step 3：JSON内のキー解析（必要時）¶

local_xxx.json（126KB）等の大きなJSONファイル内に長文設定が埋め込まれていることがある。Pythonで解析：

python3 -c '
import json
with open("path/to/file.json") as f: d = json.load(f)
for k in d.keys():
    s = json.dumps(d[k], ensure_ascii=False)
    if "探したい文字列" in s:
        print(f"key={k}, size={len(s)}")
'

Step 4：mountが必要な場合¶

ホスト側のファイルにVMから直接編集が必要なら、request_cowork_directory で親フォルダのmountリクエストを発行する。

Step 5：発見した実体パスを永続化（最重要）¶

新しい設定ファイルを発見したら、必ず以下を更新する： - 本スキル §設定ファイル所在マップ SSOT の所在マップに追加（一次ソース更新） - 個人設定の参照ポインタは触らない（ハードコード禁止原則）

これを怠ると次回も同じ探索コストが発生する。

Step 6：編集経路の判定¶

発見したファイルの 編集経路 を判定する：

ファイル種別	編集経路	永続化
`~/Library/CloudStorage/GoogleDrive-...` 配下	直接編集可	✅ Google Drive同期
`~/Library/.../memory/CLAUDE.md`	編集禁止（1分以内に再生成）	❌ 読取専用キャッシュ
`~/Library/.../local_*.json`	セッション内のみ	❌ 新セッションで上書き
claude.ai > 設定 > 個人設定	UI経由のみ	✅ サーバー永続化
Claude.app の Local Storage / IndexedDB	直接編集不可	API経由のみ

Step 7：SSOT形骸化検出プロトコル（v3.4新設・2026-05-07）¶

問題：あるフォルダが「これがSSOTです」「ここが正本です」と自称しているのに、実際は更新が止まっており、別の拠点（archive／staging／recovery／外部実体）の方が新しいケースが発生する。これを検出せずSSOTとして信頼すると古いデータを参照してしまう。

起動条件：以下のいずれかでこのプロトコルが発動： 1. SSOT／正本／一次ソース／原本を名乗るフォルダにアクセスする時 2. 同じ概念を扱う複数の関連フォルダ（例：skill関連が複数拠点）を発見した時 3. 「○○のSSOTはどこ？」とユーザーから訊かれた時

検出手順：

# A. 自称SSOTの最終更新日を取得（最新ファイルmtime）
SSOT_DIR="path/to/self-claimed-ssot"
SSOT_MTIME=$(find "$SSOT_DIR" -type f -exec stat -c %Y {} \; 2>/dev/null | sort -rn | head -1)

# B. 関連拠点（archive／staging／recovery／dropoff／temp等）の最終更新日と比較
for related in path/to/related-locations/*; do
  RELATED_MTIME=$(find "$related" -type f -exec stat -c %Y {} \; 2>/dev/null | sort -rn | head -1)
  if [ "$RELATED_MTIME" -gt "$SSOT_MTIME" ]; then
    echo "WARN: $related is newer than self-claimed SSOT $SSOT_DIR"
  fi
done

# C. 外部実体（~/.claude/ 等）の存在チェックは Cowork sandbox から不可視
#    → kudo-cowork-code-handoff-protocol 経由で Code 側へ委任

判定マトリクス：

状態	判定	対処
自称SSOTが関連拠点より新しい	健全	通常運用継続
自称SSOTより新しい関連拠点が存在	形骸化フラグ	ユーザーに即報告／真のSSOT特定／refresh計画
自称SSOTが3ヶ月以上更新なし	休眠フラグ	関連拠点と比較して判定
自称SSOTがCowork sandboxから不可視（外部実体・例：`~/.claude/`）	Code委任	kudo-cowork-code-handoff-protocolでHANDOFF.md発行
複数 SKILL が「CLAUDE.md §X が一次ソース」等と参照しているが、参照先ファイルの実体が不在（v3.8 新設・2026-05-15）	参照腐敗フラグ	(1) `find / -name "<参照先>"` で実体探索 (2) 真にバックアップが無ければ参照先を新規作成して実体化 (3) 過去バージョン履歴があれば優先復元 (4) 完了後、参照スキル群の整合性を再走査

報告フォーマット：

⚠️ SSOT形骸化検出
- 自称SSOT：[パス]（最終更新：[日付]）
- 新しい関連拠点：[パス]（最終更新：[日付]）
- 推定される真のSSOT：[パス／外部実体]
- 推奨アクション：[refresh／統合／HANDOFF発行]

手動再構成パターン検出（v3.7 拡張・2026-05-07）：

ユーザーまたはClaude（Cowork/Code）がフォルダ構造を手動で再整理した直後は、SKILL.md／HANDOFF文書／設定ファイル／個人設定の path 記述が古いパスのまま残存しやすい。これを SSOT形骸化の特殊ケースとして検出する。

起動条件：以下のいずれかを検知したら自動起動： 1. ユーザーが「フォルダを再整理した」「移動した」「集約した」と発話 2. Cloud / 真SSOT 側でフォルダ階層に変化が観測された（ls差分） 3. Code/Cowork のいずれかがmvコマンドでフォルダ移動を実行した直後

検出手順：

# 1. 旧パス候補をリスト化（移動元）と新パス（移動先）を確定
OLD_PATTERNS=("working/kudo-skill-sync/" "working/claude-reference/" "working/code-handoffs/")
NEW_PREFIX="working/claude/"

# 2. 全SKILL.md／HANDOFF文書／設定ファイルから旧パス参照を grep
for pat in "${OLD_PATTERNS[@]}"; do
  grep -rn --include="SKILL.md" --include="HANDOFF*.md" --include="*.sh"     "$pat" /path/to/skills/ /path/to/code-handoffs/     | grep -v "$NEW_PREFIX"     | tee -a /tmp/stale-path-refs.txt
done

# 3. 旧パス参照件数 > 0 なら警告
[ -s /tmp/stale-path-refs.txt ] && echo "WARN: $(wc -l < /tmp/stale-path-refs.txt) stale path references found"

修正方針： - 履歴記述（更新履歴・改訂履歴・事例記録）はそのまま（過去の事実として正史価値あり） - 現役プロトコル本体・運用ルール・参照ポインタは新パスに統一 - 個人設定（CLAUDE.md相当）の path 記述は別途UI経由で修正（claude.ai > 設定 > 個人設定）

実証例（2026-05-07）：

工藤さんとClaude（Code）が並走で working/claude/ ハブを新設し、3フォルダ（claude-reference／kudo-skill-sync／code-handoffs）を集約。Code が14スキルのpath参照を一括更新（古パス残存0件・新パス出現27件）。残作業として以下が必要： - 個人設定項目8（デザイントークン参照path）の1行修正 - ユーザーが claude.ai > 設定 > 個人設定で手動修正必須（mcqAnswers サーバー側は自動更新されない） - bash sync-skills.sh --install 実行で真SSOTへ反映

MCPデータ形骸化検出（v3.6 拡張・2026-05-07）：

ファイルシステム上のSSOTだけでなく、MCPツールが返すデータも形骸化検出の対象にする。具体的には：

MCPデータ形骸化のサイン	検出方法	対処
同じMCPを Cowork/Code 両側から呼んで応答件数が乖離	両側で `list_*` 系ツールを呼んで件数比較	件数の多い方を信頼。少ない方は「自分のスコープ外」と認識
MCP 応答件数が0なのに、関連ファイル／設定の実体は存在	`launchd plist` `~/.config/` 等の物理ファイルを並行確認	MCP応答は使うべきでない（接続先がplaceholder）
MCP応答の「最終実行時刻」が3日以上前なのに、自動運用のはず	nextRunAt と現在時刻の差分計算	形骸化フラグ（cron停止／plist消失／MCP接続切れ等）

典型ケース：scheduled-tasks MCP が Cowork で 17件、Code で 0件と返す事例（2026-05-07連続事象）。これは MCP スコープ非対称性の表れであり、SSOT形骸化ではない。Step 7 はこの両者を区別して報告する。

実証例（2026-05-07）：

working/claude/kudo-skill-sync/skills/ がREADMEで「クラウドSSOT」を自称していたが、最終更新は2026-04-08で停止していた。一方 working/skill-recovery-2026-05-05/ が2026-05-07更新で新しく、さらに真の実SSOTは ~/.claude/skills/（約50スキル・Cowork sandbox不可視・Code側でのみ検証可）であることが判明。形骸化フラグを立てて Code 側に refresh タスクを HANDOFF（HANDOFF-TO-CODE-2026-05-07.md）。同様の罠は他の自称SSOT（design-tokens／context-routing 等）にも潜在し得るため、本プロトコルで自己点検を体系化する。

§14 SSOTマップとの関係：本プロトコルは個人設定§14が指す「§設定ファイル所在マップ SSOT」の守り手。マップに登録されたSSOTがいつの間にか形骸化していないかを検出する自己点検機構として機能する。

よくあるトラップ¶

memory/CLAUDE.md を編集したのに反映されない → 読取専用キャッシュ。編集は 個人設定（claude.ai > 設定 > 個人設定） でやる
ファイルが見つからない → mdfindを使う（Spotlightインデックスが最強）
編集が消える → そのファイルは「キャッシュ」。真の正本を探す（mcqAnswers キー → 個人設定）
SSOTを名乗るフォルダが古い／関連拠点と不一致 → §Step 7 SSOT形骸化検出プロトコルで判定。真のSSOTが外部実体（~/.claude/等）の場合は Code 側に委任
複数 SKILL.md が「CLAUDE.md §X が一次ソース」と参照しているが CLAUDE.md の実体が不在 → §Step 7 判定マトリクス末尾「参照腐敗フラグ」（v3.8）に従い、find 全 FS 検索で実体探索 → バックアップ無ければ新規作成して実体化（2026-05-15 Phase 3 Part A の ~/.claude/CLAUDE.md 新設が実例）

背景¶

2026-04-26のセッションで、Claude（私）がCLAUDE.md実体を探すのに無駄な時間を費やした実害があった。memory/CLAUDE.mdが読取専用キャッシュで、真の正本がmcqAnswers→個人設定だと特定するまで、ターミナルで5回以上のコマンド試行とSpotlight検索を繰り返した。本プロトコルはその経験から、「設定ファイル探索の体系的手順」と「真の正本の場所マップ」を型化したもの。

§自走原則 SSOT（v3.0でSSOT昇格）¶

本セクションが「自走原則」の唯一の正本（SSOT）。 個人設定からも本セクションを参照する形に再配置（v3.0）。すべてのスキル・補足ドキュメントは「kudo-persist-settings §自走原則 SSOT」で参照する。

なぜ必要か¶

工藤さんの認知負荷を下げ、Claudeを「補佐官」として最大限活用するため、「言われる前に自走実行」する範囲を明示的に定義する。本セクションがSSOT本体。

自走OK／要事前承認／絶対禁止リスト（v3.0で本体に昇格）¶

【自走OK：黙ってやってOK・完了後1行報告】 - スキル改訂・追記：SKILL.md改訂版を生成→.skillファイル保存促し - scheduled tasksのdescription補強・軽微修正：mcp__scheduled-tasks__update_scheduled_task で直接実行 - WorkFlowyノード作成・追記：kudo-workflowy-double-save §運用ルール SSOT §4（書込み前チェックリスト）通過後に直接実行 - GitHub Gist作成・更新（Public化以外） - PROJECT-CLAUDE.md / SKILL.md / kudo-brand-tokens.json 等のmount済みファイル更新 - Google Drive配下のファイル新規作成・編集（claude-reference内） - mountリクエスト発行（request_cowork_directory）

【要事前承認：実行前に1秒だけ確認】 - 個人設定の項目追加：テキスト案を提示→「OK」をもらってから工藤さんがコピペ（直接編集できないため） - 既存スキルの大幅な構造変更（v1.x→v2.x相当のメジャーバージョンアップ） - WorkFlowy内の構造変更（ノード移動・大量整理・複数案件横断更新） - 新規scheduled tasksの作成（cron設定含む） - 新規ファイル作成のうち、保存先がデスクトップ／Google Drive外の場合

【絶対禁止：工藤さん自身が必ず手を動かす】 - スキルの削除（廃止プロトコル通過後も、削除ボタンは工藤さんが押す） - 個人設定の全文差し替え・項目削除（コピペミス時に全部失うリスク） - WorkFlowyノードの削除 - クライアントへの送信物・公開コンテンツ（X投稿・メール・Slack送信・公開Gist化） - 金銭・契約・法務関連 - Claude.app／claude.ai／GitHub等のアカウント設定変更

自走判定の3問チェックリスト（実行前に必ず通す）¶

ユーザーから明示指示がない操作を実行しようとする前、以下の3問を自問する：

Q	問い	YES なら
Q1	この操作は可逆か？（追記・修正・追加）	自走OK寄り
Q2	影響範囲は工藤さん個人に閉じるか？（外部送信・公開なし）	自走OK寄り
Q3	本セクションの「自走OK」リストに該当するか？	自走OK

3問すべてYES → 自走実行＋1行報告 1問でもNO → 本セクションの「要事前承認」または「絶対禁止」リストを確認 → 該当する分類で対応

自走実行の標準作法¶

Step 1：宣言（複数操作の場合のみ）

複数の自走操作を連続で行う場合、まとめて「○○・○○・○○を一気にやります」と宣言してから実行。

Step 2：実行

宣言なしでも単発操作なら即実行可。

Step 3：1行報告（必須）

完了後に「○○を更新しました」「○○を追加しました」と1行で報告。黙ってやらない。

Step 4：予期せぬ事態時は即停止

操作の途中で予想外の事態（エラー・既存ファイルの予想外の状態等）が出たら、すぐに止めて報告→指示を仰ぐ。

「要事前承認」レベルの3秒ルール¶

「要事前承認」リストにある操作でも、明らかに工藤さんの意図に沿うものは「やります、止めるなら言ってください」とアナウンス→3秒待ってから実行可。3秒は暴走防止のクッションとして必ず置く。

違反時の挙動¶

黙って自走した場合：次回会話で「○○を黙ってやりました、すみません」と振り返り報告
不可逆操作を自走した場合：原状復帰を試みる→不可なら即報告

既存項目との関係¶

個人設定「スキル提案」（旧10）：本項目に統合・格上げ。提案ベース → 自走＋報告ベースへ
個人設定「スキル管理」（旧11）：本項目と整合。自走でSKILL.md改訂版生成→.skillファイル保存促し
個人設定「WorkFlowy統合参照」（旧12）：kudo-workflowy-double-save §運用ルール SSOT §4 のチェックリスト通過が自走の前提
本スキル §設定ファイル所在マップ SSOT：探索→発見→自走更新の流れで連携

自走OK領域の典型例（参考）¶

領域	自走例
スキル	SKILL.md改訂版生成→.skill保存促し（最終ボタンは工藤さん）
scheduled tasks	description補強・軽微cron修正をmcp経由で直接実行
WorkFlowy	案件ノードへの追記・新案件 #project ノード作成
GitHub Gist	データセット・参照HTML・プレビューのSecret Gist作成
文書ファイル	PROJECT-CLAUDE.md・SKILL.md・kudo-brand-tokens.json の更新
Google Drive	claude-reference 配下のファイル新規作成・編集

背景¶

2026-04-26のセッションで、Claudeが「scheduled tasks 4本のdescription補強」を「前回提示済み・工藤さん作業待ち」として保留していたが、工藤さんから「コレは君がやってくれないの？」と指摘された。本来Claudeが自走できる操作（mcp__scheduled-tasks__update_scheduled_taskで直接実行可能）を提案ベースで止めていたのは過剰な萎縮。本プロトコルはこの反省から、「自走OK／要事前承認／絶対禁止」の線引きを明確化し、Claudeが補佐官として最大限機能するための判断ロジックを型化したもの。

形式制約事前チェック：description 字数¶

なぜ必要か¶

claude.aiのスキル保存UIには description フィールドに2つの形式制約がある：

制約1：文字数上限 1024字

field 'description' in SKILL.md must be at most 1024 characters

制約2：XMLタグ禁止（2026-04-28追加発覚）

SKILL.md description cannot contain XML tags

description内に <...> 形式のタグ（例：<p:bg>、<a:font>、<br>等）を含めると保存時に弾かれる。XMLサンプルやHTMLタグを description に書きたい場合は、p:bg や a:font のように山括弧を外して記述する。

チェックフロー¶

Step F0：kudo-skill-md-format-validator 自動起動（v3.2新設・最優先）

新規スキル作成・既存スキル改訂のたびに、まず kudo-skill-md-format-validator の validate_skill.py を起動して7項目（frontmatter／name／description必須／字数1024以内／XMLタグ禁止／動詞群明示／セッション固有パス禁止）を一括検査する。

# 単一ファイル検査
python3 [validatorのパス]/scripts/validate_skill.py /path/to/SKILL.md

# 一括検査（既存スキル全件）
python3 [validatorのパス]/scripts/validate_skill.py --dir /path/to/skills/

判定： - 全PASS → そのまま保存OK - WARN（動詞群未明示等） → 推奨レベルなので案件文脈で判断 - FAIL → 該当 Step F2-F4 で対処してから再検査

Step F0が手動Step F1より優先される理由： - 7項目を1秒で網羅的にチェック - false negative（チェック漏れ）を機械的にゼロにする - 2026-04-28に kudo-proposal-deck v2.5 / kudo-client-template-factory v0.4 で2連続「字数超過＋XMLタグ含有」エラーが発生した反省から、手動チェックでは漏れることが実証された

Step F1：description 字数＋XMLタグの一括チェック（手動チェック・予備）

import re
with open('SKILL.md') as f:
    content = f.read()
m = re.search(r'description:\s*(.*?)(?=\n---)', content, re.DOTALL)
desc = m.group(1).strip()

# 制約1：文字数
print(f'文字数: {len(desc)}')
print(f'1024超過: {"NG (" + str(len(desc)-1024) + "字超)" if len(desc) > 1024 else "OK (" + str(1024-len(desc)) + "字余裕)"}')

# 制約2：XMLタグ
xml_tags = re.findall(r'<[^>]+>', desc)
print(f'XMLタグ: {"NG (" + str(xml_tags) + ")" if xml_tags else "OK (なし)"}')

# 両方OKなら保存可、どちらか1つでもNGなら保存不可
ok = len(desc) <= 1024 and not xml_tags
print(f'保存可否: {"✅ 保存OK" if ok else "❌ 保存不可・修正必要"}')

Step F2：判定と対処

文字数判定：

字数	判定	対処
〜800字	◎ 安全	そのまま出力
800〜950字	○ ターゲット帯	そのまま出力（推奨ゾーン／追記時バッファ100字確保）
950〜1024字	△ ギリギリ	再見直しを推奨
1024字超過	✕ NG	必ず短縮してから出力

XMLタグ判定（2026-04-28追加）：

検出結果	判定	対処
タグ0個	◎ OK	そのまま出力
タグ1個以上	✕ NG	山括弧を外す／別表現に置換／本文へ移動

Step F3：超過時の短縮戦略

冗長語の削除
同義語の統合
説明的接続詞の省略
旧バージョン詳細を本文側へ逃がす
トリガーキーワードリストを「など」で省略

残してはいけないもの：主要トリガーキーワード／連携スキル併用条件／動詞群所属／最新バージョン主要変更点／「子が親を呼ぶ」原則

Step F4：XMLタグ含有時の対処（2026-04-28追加）

description にXMLタグを書きたい場合は、以下のいずれかで回避：

元の表記	推奨置換	例
`<p:bg>` 属性	「p:bg 属性」	山括弧を削除
`<a:font>` 要素	「a:font 要素」	同上
HTML `<br>`	「改行」	別表現に
サンプルXML	本文に移動	description には「詳細は本文§N参照」と書く

原則：description は「トリガー精度を上げる説明テキスト」であって、技術仕様の引用場所ではない。XMLサンプルは本文側で記述する。

適用タイミング（必須）¶

タイミング	場面	必須度
新規スキル作成時	「新スキル追加プロトコル」Step 0.5	必須
既存スキル改訂時	「3軸自己チェックプロトコル」Step 0	必須
description に追記が発生する全場面	例外なし	必須

過去の失敗ケース¶

2026-04-24 kudo-design-mockup v0.4：1080字（56字超過）→ 708字に短縮で対応
2026-04-28 kudo-proposal-deck v2.5：1240字（216字超過）＋ <p:bg> XMLタグ含有 → 942字＋タグ除去で対応。Claudeが本SKILL.md §形式制約セクションの存在を忘れて作業し、2連続のエラーで保存できなかった反省事例。本プロトコルを「スキル改訂時の Step 0.5 で必ず通す」運用を再徹底
2026-04-28 kudo-client-template-factory v0.4：1061字（37字超過）＋ <p:bg> XMLタグ含有 → 945字＋タグ除去で対応（同上事例）
2026-04-28 上記2連続失敗を受け kudo-skill-md-format-validator v1.0 を新設（scripts/validate_skill.py）。本セクション §形式制約事前チェックの Step F0 で必ず起動するフローに組込（v3.2）。検出力テストで kudo-naming-unification-protocol のセッション固有パスハードコード4箇所も発見し v1.2 へ修正完了

スキル改訂時の3軸自己チェックプロトコル¶

スキルに新しい原則・チェック項目・ルールを追記する際、直近案件で得た学びをそのまま型化してしまう失敗パターンが繰り返し発生している。原因は「汎用性の多面的な担保」を怠り、一軸だけで汎用性チェックを済ませてしまうこと。

本プロトコルは、スキルへの追記・改訂作業の前後に必ず通す自己チェック。

前提：本プロトコル開始前に、必ず「形式制約事前チェック」と「ハードコード禁止チェック」（v2.0新設）を通すこと。

Step 1：メタルール違反チェック（改訂前） - 「今回の答えと汎用的な操作を区別する」違反 - 「手段を規定するな、機能を規定せよ」違反 - 「事例は鑑賞リストではなく生成レシピである」違反 - 「条件付き適用を明示する」違反 - 「ハードコード禁止原則」違反（v2.0追加）：他スキル一次ソースの実体記述を本スキル内に複製していないか

Step 2：汎用性3軸チェック（改訂前）

軸	観点	チェック問い
業種軸	クライアント企業・組織の業種	食品・金融・ファッション・BtoB・NPO・行政・テック・医療・教育すべてで成立するか？
ジャンル軸	アウトプットの種類	マニフェスト・LP・祝賀文・謝罪文・採用文・IR・CSR・スピーチ・創業者挨拶・ビジョン・弔辞・キャンペーン等で成立するか？
要件軸	温度・口調・目的	熱／冷／中立、反骨／優しい／厳格／詩的／荘厳、批判／祝福／説得／告知／感謝／謝罪／決意／教示／慰めの組み合わせで成立するか？

Step 3：他案件転用テスト（改訂前）

「この原則は、TEXT.案件以外で使える場面を3つ言えるか？」を自問する。

Step 4：記述原則の明示（改訂中）

汎用原則と今回の答えを構造的に区別する記述を採用する。

Step 5：差し戻し点の記録（改訂後）

工藤さんから「抽象化が不十分」「軸が足りない」等の差し戻しを受けた場合、その指摘を本プロトコルの更新素材として記録する。

Step 6：description 字数の最終確認（改訂後・必須）

改訂内容を反映した SKILL.md を出力する直前に、「形式制約事前チェック」Step F1 のスクリプトで字数を再確認。

§.skillファイル形式（ZIP圧縮構造）（v3.3新設・2026-05-07）¶

なぜ必要か¶

claude.aiの「カスタマイズ → スキル」画面の保存ボタンは、.skill 拡張子のファイルがZIP圧縮されたディレクトリ構造であることを期待する。単純にSKILL.mdを .skill 拡張子にコピーしただけのプレーンテキストファイルは「Invalid zip file」エラーで弾かれる。

これは present_files 経由でユーザーに「保存ボタン」を提示する場合の必須要件。形式が違うと工藤さんに二度手間を強いる（ダウンロード→クリップボードコピー→貼り付け）ため、必ず正しい形式で出力する。

正しい`.skill`ファイル形式¶

構造

kudo-XXX.skill (ZIP圧縮されたアーカイブ)
└── kudo-XXX/         ← スキル名と同じフォルダ名（必須）
    └── SKILL.md      ← 必須
    └── scripts/      ← オプション（実行スクリプト）
    └── references/   ← オプション（参照ファイル）

作成コマンド（標準作法）

# 1. ワーキングディレクトリでスキル名のフォルダを作る
WORK=/tmp/skills_zip
mkdir -p $WORK/kudo-XXX

# 2. SKILL.md を配置
cp /path/to/SKILL.md $WORK/kudo-XXX/SKILL.md

# 3. ZIP化（フォルダごと）
cd $WORK
zip -r /mnt/user-data/outputs/kudo-XXX.skill kudo-XXX/

検証コマンド（必須実行）

# ZIP形式であることを確認
file /mnt/user-data/outputs/kudo-XXX.skill
# 期待結果："Zip archive data, at least v1.0 to extract"

# 中身のディレクトリ構造を確認
unzip -l /mnt/user-data/outputs/kudo-XXX.skill
# 期待結果：kudo-XXX/ と kudo-XXX/SKILL.md が含まれる

違反時のシグナル¶

claude.ai画面で「Invalid zip file」エラーが表示される。これは即座のシグナル。この表示が出たら、ZIP化されていないかフォルダ構造が間違っているか、いずれかが原因。

適用タイミング（必須）¶

スキル新規作成・改訂時に .skill 形式で出力するなら、以下4ステップを必ず実行：

SKILL.md を kudo-XXX/ フォルダに配置（フラット配置はNG）
zip -r でフォルダごと圧縮し .skill 拡張子で保存
file コマンドで Zip archive data であることを検証
unzip -l で中身のディレクトリ構造を検証

これら4ステップを通過してから present_files で工藤さんに渡す。

複数スキル一括出力時の作法¶

同じセッションで複数スキルを更新する場合、共通のワーキングディレクトリで個別にZIP化する：

cd /tmp && rm -rf skills_zip && mkdir -p skills_zip

mkdir skills_zip/kudo-A && cp /path/to/A/SKILL.md skills_zip/kudo-A/
mkdir skills_zip/kudo-B && cp /path/to/B/SKILL.md skills_zip/kudo-B/
mkdir skills_zip/kudo-C && cp /path/to/C/SKILL.md skills_zip/kudo-C/

cd skills_zip
zip -r /mnt/user-data/outputs/kudo-A.skill kudo-A/
zip -r /mnt/user-data/outputs/kudo-B.skill kudo-B/
zip -r /mnt/user-data/outputs/kudo-C.skill kudo-C/

ZIPには複数スキルを混ぜない。.skill ファイル＝1スキル単位。

過去の失敗ケース（実証）¶

2026-05-07：kudo-proposal-deck v2.8 ／ kudo-marketing-strategy v1.2 ／ kudo-deck-aesthetic-qa v1.3 を初回 .skill 出力した際、SKILL.md を単に拡張子変更（cp SKILL.md kudo-XXX.skill）しただけで present_files したため、claude.ai で「Invalid zip file」エラー発生。工藤さんから保存できないとフィードバック後、ZIP化（フォルダ構造保持）して再出力で解決。このスキル §.skillファイル形式は、この失敗から構造化されたもの。

連動¶

kudo-skill-md-format-validator：description字数チェックと併せて、.skill 出力前に file/unzip による形式検証も実行する
全プロトコル実行順（v3.3で更新）：形式制約事前チェック内に「.skillファイル形式検証」を追加

スキル廃止／改名プロトコル（2026-04-24新設）¶

実行手順（半自動化）¶

Step 1：影響範囲のgrep実行

grep -rn "廃止または旧スキル名" /mnt/skills/user/ 2>/dev/null | grep -v "/廃止または旧スキル名/SKILL.md"

Step 2：タイプ1／タイプ2の分類

タイプ	内容	対処
タイプ1：廃止事実の説明として正しい記述	「旧〇〇を吸収統合」「〇〇を廃止」「アーカイブ化」等	維持
タイプ2：廃止／旧スキルを現役として扱っている記述	連携表の行、上流／並走／下流スキル一覧等	修正必要

Step 3：タイプ2の一括修正

Step 4：廃止スキル側への明示（description冒頭に【削除推奨】マーカー）

Step 5：ツリー更新

Step 6：ツリー整合性セルフチェック実行

違反時の挙動¶

Step 1のgrepを飛ばして「廃止完了」報告するのは禁止。

ツリー整合性セルフチェックプロトコル（2026-04-24新設）¶

6項目セルフチェック¶

チェック1：実態整合　ls /mnt/skills/user/ の結果と本スキルのツリー記述に差分はないか？

チェック2：親子双方向整合　子が「親はX」と書いていれば、親Xにも「子にY」が書かれているか？

チェック3：廃止スキル明示　統合・廃止された旧スキルは取り消し線または廃止マーク付きで残されているか？

チェック4：辞書型・メタスキル参照　辞書型孫の参照元が明示されているか？

チェック5：目的語一意性　目的語が他スキルと重複していないか？

チェック6：★仮説スキルの明示　検証未完了のスキルにマークが付いているか？

適用タイミング（必須）¶

新規スキル作成時：Step 5として必須
既存スキル改訂時：出力前に必須
ドリフト検出時：即座に実行
スキル月次棚卸し会議（第1日曜 9:00-9:30 JST）：必須議題

パス記述3層ルール（2026-04-24新設）¶

ルール：ファイルパスに言及する際は必ず3層で書く¶

**パス（3層必須）**：
- **永続ローカル参照**：`~/Library/CloudStorage/GoogleDrive-kudotakuma421@gmail.com/マイドライブ/working/claude/claude-reference/...`（Google Drive同期、人間/AI参照用）
- **VM内パス**：`/sessions/<session>/mnt/claude-reference/...`（mount経由、ビューワー動作）
- **セッション内スクラッチ**：`/sessions/<session>/mnt/outputs/...`（Claude作業中のみ、ユーザー提示前に必ずmount配下へコピー）

記述上の禁則¶

セッションIDを固有名詞として書かない
短縮パスを単独で書かない
永続化先が未確認の場合はTODOマーカーを残す
スクラッチパスだけで完結させない

全プロトコル実行順（2026-04-28改訂・v3.2）¶

v3.2 改訂点：Step 0 として kudo-skill-md-format-validator 自動起動を追加。これによりすべての新規作成・改訂作業が機械チェックを通過してから本プロトコルに入る。

新規スキル作成時¶

Step 0：命名プリフライト
Step 0.5：description 字数事前チェック
Step 0.7：ハードコード禁止チェック（v2.0新設）
Step 1〜4：「動詞群＋目的語」確認、ツリー更新
Step 5：ツリー整合性セルフチェック
本文執筆
形式制約事前チェック（再）
ハードコード禁止チェック（再・grep実行）
パス記述3層ルール検証
SKILL.md 出力

既存スキル改訂時¶

形式制約事前チェック
ハードコード禁止チェック（v2.0新設）：追記内容にCLAUDE.md一次ソースの実体記述が混入していないか
3軸自己チェックプロトコル Step 1〜4
改訂内容の執筆
3軸自己チェックプロトコル Step 5・6
ハードコード禁止チェック（再・grep実行）
ツリー整合性セルフチェック
パス記述3層ルール検証
SKILL.md 出力

廃止／改名時¶

スキル廃止／改名プロトコル Step 1〜6
ハードコード禁止チェック：削除されたスキル名がgrepで他スキルに残存していないか
ツリー整合性セルフチェック

§参照リンク整合性チェック（v3.0新設・段階3）¶

なぜ必要か¶

SSOT再配置（v3.0）でスキル間の参照リンク（「kudo-XXX §セクション名」形式）が全システムに張り巡らされる。スキル名やセクション名が変わると参照リンクが切れて、SSOTが機能不全に陥る。本セクションは月次自動チェックで切れリンクを検出・修復するためのプロトコル。

いつ実行するか¶

定期：毎月第1日曜 9:00–9:30 JST（重複セクション防止プロトコルと同じタイミング）
臨時：スキルの大幅改版時／セクション見出し変更時／工藤さんから「参照リンクチェックして」と明示要求があった時

実行手順（半自動化）¶

Step 1：全SKILL.mdから「kudo-XXX §」形式の参照を抽出

grep -rE 'kudo-[a-z-]+\s*§[^「」\]]+' \
  /Users/kudotakuma/Library/Application\ Support/Claude/local-agent-mode-sessions/*/skills/*/SKILL.md \
  /Users/kudotakuma/Library/CloudStorage/GoogleDrive-kudotakuma421@gmail.com/マイドライブ/working/claude/claude-reference/PROJECT-CLAUDE.md \
  > /tmp/refs.txt

Step 2：各参照について、参照先スキル＋§セクションが実在するか検証

while IFS= read -r line; do
  skill=$(echo "$line" | grep -oE 'kudo-[a-z-]+' | head -1)
  section=$(echo "$line" | grep -oE '§[^「」\]]+' | head -1)

  skill_path="/path/to/skills/$skill/SKILL.md"
  if [ ! -f "$skill_path" ]; then
    echo "❌ MISSING SKILL: $skill (referenced in $line)"
  elif ! grep -qE "^## $section|^### $section" "$skill_path"; then
    echo "⚠️ MISSING SECTION: $skill $section"
  fi
done < /tmp/refs.txt

Step 3：切れリンクのレポート

検出された切れリンクは： 1. 工藤さんに報告（リスト形式・該当箇所のファイルパスと行番号付き） 2. 修復案を提示： - A. リネーム反映（参照先のセクション名が変わった場合） - B. 削除（参照先が廃止された場合） - C. 新規セクション作成（参照先がまだ作られていない場合） 3. 工藤さん承認後、自走で書き換え（自走OK：可逆・個人内完結）

検出すべき典型パターン¶

パターン	例	対処
スキル名変更	`kudo-sync-cycle §...` → 廃止済み	全参照を `kudo-workflowy-double-save §...` に置換
セクション名変更	`§設定ファイル探索プロトコル` → `§設定ファイル所在マップ SSOT`	旧名参照を新名に一括置換
番号付きセクションのリネーム	`§4.1 親IDロック` → `§運用ルール SSOT §1`	全参照を新形式に書換
スキル削除	参照先スキル自体が削除	参照箇所を別スキルに振替 or 削除

参照記述の標準フォーマット（v3.0確立）¶

スキル間参照は 以下の3形式のいずれか に統一：

推奨1：kudo-XXX §セクション名 SSOT
推奨2：kudo-XXX §セクション名（バックスラッシュ・修飾語なし）
許容：本スキル §セクション名（自スキル内自己参照のみ）

禁止： - 個人設定の項目番号参照（「個人設定項目14」等） - 旧 CLAUDE.md セクション番号参照（「CLAUDE.md §4」等） - パス・URL・ID 直書き（SSOT違反）

段階的成熟ロードマップ¶

v3.0（現在・2026-04-27）：手動実行ベース（grep + 工藤さん目視確認 + Claude修復案提示）
v3.1（将来）：scheduled task として自動化（毎月第1日曜・成長したリンクツリーを定期検証）
v3.2（将来）：Cowork mountフォルダ内の全スキルファイルを横断的にチェック・自動レポート生成

違反時の挙動¶

参照リンク追加時は 必ず本チェックを通してから記述する。月次チェックで切れリンクが2件以上溜まっている場合は、即時修復を最優先タスクとする（放置すると指数的に膨らむ）。

更新履歴¶

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 監査の発見を恒久的プロトコル化）。よくあるトラップにも該当エントリを追記。
v3.7（2026-05-07）：§設定ファイル所在マップ SSOT の Step 7 SSOT形骸化検出プロトコル に 手動再構成パターン検出 を追加。ユーザー/Code側がフォルダ階層を再整理した直後に発動し、SKILL.md／HANDOFF／個人設定／設定ファイルの旧パス参照を一括検出する。working/claude/ ハブ集約（Code自走実施・14スキルpath更新済み）の事例を実証として記録。修正方針（履歴記述は残置／現役プロトコルは新パス統一／個人設定はUI経由で別途修正）も明記。
v3.6（2026-05-07）：§設定ファイル所在マップ SSOT の Step 7 SSOT形骸化検出プロトコル に MCPデータ形骸化検出 を追加。ファイルシステムだけでなくMCP応答（list_系ツール）の3パターン（両側応答乖離／応答0件vs実体存在／lastRunAtドリフト）を検出対象に拡張。scheduled-tasks 0件誤認の連続事例（2026-05-05/05-07）を実証として記録。kudo-cowork-code-handoff-protocol §7-1-a と相互参照。
v3.5（2026-05-07）：OneDrive→Google Drive 移行に伴う一括更新。所在マップ／プロトコル本体内のOneDriveパス記述を全面 Google Drive（GoogleDrive-kudotakuma421@gmail.com/マイドライブ）に置換。さらにCode発見の 真のスキル実体ストレージパス（~/Library/Application Support/Claude/local-agent-mode-sessions/skills-plugin/{device}/{user}/skills/）を §真の正本（編集する場所）リストに追加。~/.claude/skills/ は空のplaceholderである事実を明記し、Step 7 SSOT形骸化検出プロトコルの実証例として記録。
v3.4（2026-05-07）：§設定ファイル所在マップ SSOT に Step 7 SSOT形骸化検出プロトコル を新設。自称SSOT（README等で「これが正本」と謳うフォルダ）が関連拠点より古い／外部実体（~/.claude/等）が真のSSOTであるケースの自動検出と Code 側委任手順を内蔵。kudo-cowork-code-handoff-protocol と連動。working/claude/kudo-skill-sync/skills/ が Apr 8 で停止していたのに対し working/skill-recovery-2026-05-05/ が新しく、さらに真SSOTは ~/.claude/skills/（約50スキル）にあった実例を起点に新設。よくあるトラップにも対応エントリ追加。
v3.3（2026-05-07）：§.skillファイル形式（ZIP圧縮構造）を新設。claude.ai「カスタマイズ→スキル」画面の保存ボタンが期待するZIP形式（kudo-XXX/SKILL.md構造）を明文化。Invalid zip fileエラーへの対策プロトコル（4ステップ検証作法）を確立。kudo-proposal-deck v2.8／kudo-marketing-strategy v1.2／kudo-deck-aesthetic-qa v1.3 の3スキル一括出力時の失敗ケースが起点。
v1.0：初版（2026-04-07ごろ）
v1.x：形式制約事前チェック追加（2026-04-24）／スキル廃止プロトコル追加（2026-04-24）／ツリー整合性プロトコル追加（2026-04-24）／パス記述3層ルール追加（2026-04-24）
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 と同時改訂。全プロトコル実行順にハードコード禁止チェックを追加。
v2.1（2026-04-26）：設定ファイル探索プロトコルを新設。CLAUDE.md実体探索で30分以上を費やした実害から型化。「真の正本＝mcqAnswers（個人設定）」の構造を所在マップとして永続化。個人設定「設定ファイル所在マップ」と連携。
v2.2（2026-04-26）：自走原則の運用詳細プロトコルを新設。Claudeの代行範囲（自走OK／要事前承認／絶対禁止）を明確化し、判断3問チェックリストと標準作法を型化。個人設定「自走原則」と連携。提案ベースから「自走＋報告」ベースへ運用シフト。
v2.3（2026-04-27）：個人設定の17項目連番化（旧16欠番→詰め）に伴い、SKILL.md内の項目番号参照を全て更新。項目16→15（設定ファイル所在マップ）、項目17→16（自走原則）の8箇所修正。今後はハードコード番号でなくタイトル参照を主体とする方針へ転換（番号変更耐性のため）。
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 新規作成と並走改訂。

¶

v3.2（2026-04-28）：kudo-skill-md-format-validator v1.0 との連携を組込。§形式制約事前チェックに「Step F0：validator自動起動」を新設し、新規スキル作成・既存スキル改訂時の機械チェックを必須化。description にも連携明示。失敗ケースDBに validator 導入経緯を追記。kudo-naming-unification-protocol の検出4箇所が v1.2 修正完了の実績付き。

反映方法¶

「## スキルガバナンス原則」直後に「## ハードコード禁止原則と3層分離」が新規挿入される
description（YAMLフロントマター）にv2.0の新規トリガー語（ハードコードされてる／SSOT化／一次ソース化／参照ポインタ化／3層分離／設定情報を一元化）を追加済み
既存「## 永続化先の選択基準」テーブル下のWorkFlowy書込ルール詳細記述（旧⚠️絶対ルールブロック）を「WorkFlowyの書込ルール詳細はCLAUDE.md §4を参照すること。」に置換
既存「Step 3：承認後、書き込みを実行する」のWorkFlowyへの書き込み手順詳細を「CLAUDE.md §4「WorkFlowy統合運用ルール」に従う」に簡略化
既存「## 注意事項」のWorkFlowy書込先限定ルールを「§4が一次ソース」記述に置換

kudo-persist-settings v3.8¶

なぜこのスキルが必要か¶

トリガー判定：何を「永続化すべき合意」とみなすか¶

永続化先の選択基準¶

実行手順¶

Step 1：合意内容を一文で整理する¶

Step 2：永続化先を提案して確認を取る¶

「はい」で書き込みます。¶

Step 3：承認後、書き込みを実行する¶

Step 4：完了を報告する¶

注意事項¶

persist-settings ガバナンス原則【最終版】¶

スキルガバナンス原則¶

動詞群と所属スキル¶

起動ルール¶

新スキル追加プロトコル¶

ハードコード禁止原則と3層分離（2026-04-26新設・v2.0）¶

なぜ必要か¶

3層分離原則¶

適用領域¶

ハードコード許容例外（限定的）¶

違反時の挙動¶

grep検出コマンド（半自動化）¶

適用タイミング（必須）¶

背景¶

§設定ファイル所在マップ SSOT（v3.0でSSOT昇格）¶

なぜ必要か¶

真の正本の場所マップ（2026-04-26調査確定・v3.0でSSOT本体に昇格）¶

Step 1：所在マップを最初に確認¶

Step 2：マップにない場合の体系的探索¶

Step 3：JSON内のキー解析（必要時）¶

Step 4：mountが必要な場合¶

Step 5：発見した実体パスを永続化（最重要）¶

Step 6：編集経路の判定¶

Step 7：SSOT形骸化検出プロトコル（v3.4新設・2026-05-07）¶

よくあるトラップ¶

背景¶

§自走原則 SSOT（v3.0でSSOT昇格）¶

なぜ必要か¶

自走OK／要事前承認／絶対禁止 リスト（v3.0で本体に昇格）¶

自走判定の3問チェックリスト（実行前に必ず通す）¶

自走実行の標準作法¶

「要事前承認」レベルの3秒ルール¶

違反時の挙動¶

既存項目との関係¶

自走OK領域の典型例（参考）¶

背景¶

形式制約事前チェック：description 字数¶

なぜ必要か¶

チェックフロー¶

適用タイミング（必須）¶

過去の失敗ケース¶

スキル改訂時の3軸自己チェックプロトコル¶

§.skillファイル形式（ZIP圧縮構造）（v3.3新設・2026-05-07）¶

なぜ必要か¶

正しい.skillファイル形式¶

違反時のシグナル¶

適用タイミング（必須）¶

複数スキル一括出力時の作法¶

過去の失敗ケース（実証）¶

連動¶

スキル廃止／改名プロトコル（2026-04-24新設）¶

実行手順（半自動化）¶

違反時の挙動¶

ツリー整合性セルフチェックプロトコル（2026-04-24新設）¶

6項目セルフチェック¶

適用タイミング（必須）¶

パス記述3層ルール（2026-04-24新設）¶

ルール：ファイルパスに言及する際は必ず3層で書く¶

記述上の禁則¶

全プロトコル実行順（2026-04-28改訂・v3.2）¶

新規スキル作成時¶

既存スキル改訂時¶

廃止／改名時¶

§参照リンク整合性チェック（v3.0新設・段階3）¶

なぜ必要か¶

いつ実行するか¶

実行手順（半自動化）¶

検出すべき典型パターン¶

参照記述の標準フォーマット（v3.0確立）¶

自走OK／要事前承認／絶対禁止リスト（v3.0で本体に昇格）¶

正しい`.skill`ファイル形式¶