kudo-naming-unification-protocol v2.4

§1 概要

工藤拓真の案件名・クライアント名・プロジェクト名を6経路にわたって統一するメタプロトコル。動詞群5（Skillを管理する）の独立スキル。

6経路： - ① Mac ローカル ~/working/（顧客ビジネス／自社ビジネス等のフォルダ階層） - ② Google Drive（クラウド本体・①と双方向同期） - ③ claude.ai Project（プロジェクト名） - ④ Claude Chat（チャットタイトル） - ⑤ NotebookLM（ノートブック名） - ⑥ WorkFlowy（#project ノード名）

核心思想（Postel's law）：書く時は厳格に統一・読む時は寛容に揺れを許容。表記揺れの完全駆逐は手段であって目的ではない。揺れた状態でも検索が取りこぼさないことが本質。

---

§2 起動トリガー

直接トリガー

• 「mizkanとミツカン混在」「表記揺れ整理」「命名統一」「リネームしたい」「揺れ検出」「徹底統一」「ファイル名整理」
• 「macOS大文字小文字」「Case-Insensitive」「クライアント名で検索したのに見つからない」「ヒットしない」「fuzzy match」「揺れを許容して検索」
• 「装飾語削除」「リブランディング外して」「ブランディング外して」
• 「半角全角カッコ問題」「NFC正規化」「フォルダ名がxlsxと違う」「文字正規化」

状況トリガー

• 新規クライアント／案件発足時の命名事前合意
• Drive 一括改名・WorkFlowy 案件名統一・claude.ai Project 名整理・NotebookLM 一覧整理
• 6経路で名前がバラついている時の整理
• xlsx マスター名簿と実体ファイル名の不一致発見時

---

§3 命名規則 v0.3（SSOT・このセクションが正本）

3-1. 基本フォーマット

A_B

- A：主表記（ブランドロゴ・コミュニケーション上の第一表記） - B：副表記（検索性確保のための翻字・読み） - 連結子：アンダースコア _（一択）

例： - Uniqlo_ユニクロ（英字主、カタカナ副） - ミツカン_Mizkan（カタカナ主、英字副） - 東京国立博物館_TNM（漢字主、頭字語副）

3-2. ★NEW★ 装飾語削除ルール（D1 教訓・2026-05-15）

削除対象の装飾語：以下は識別子としての価値がないため、統合スラッグから機械的に削除：

v0.3 オリジナル： - リブランディング - ブランディング - ブランド戦略 - 戦略 - 作戦会議室 - 会議室

v0.3.1 拡張（2026-05-15・WorkFlowy 実証由来）： - リニューアル - ブランドリニューアル - リブランド - VIリニューアル

理由：装飾語は「内容説明」であり「識別子」ではない。フォルダ名・プロジェクト名は識別子に徹するべき。

例： - Text._テキスト ブランディング → Text._テキスト - 東京国立博物館_TNM リブランディング → 東京国立博物館_TNM - 2602Text.ブランディング作戦会議室 → Text._テキスト - NEXFIELD VI リニューアル → NEXFIELD_ネクスフィールド（v0.3.1） - 味よし食品 ブランドリニューアル → 味よし食品_Ajiyoshi（v0.3.1）

判断基準：その語を取り除いて識別性が損なわれるか？ - 損なわれない → 削除（内容説明 = 装飾語） - 損なわれる → 保持（固有名の一部）

3-2-A. ★NEW★ 階層原則（v0.3.1・2026-05-15）

工藤さんの判断（2026-05-15）：「リニューアルとかは、プロジェクト名の下のフォルダで創るのはいいけど、ネーミングからは排除がいいね」

これは階層的命名原則を示している：

レベル	装飾語の扱い	理由
親レベル（プロジェクト名）	装飾語を削除（識別子に徹する）	プロジェクト名は「何の案件か」を一意に識別する役割
子レベル（作業段階フォルダ）	装飾語 OK（役割名として機能）	作業段階は「リニューアル」「コンセプト開発」「初期リサーチ」等のフェーズ識別が必要

構造例：

NEXFIELD_ネクスフィールド/          ← 親：装飾語なし
   ├ VI リニューアル/                ← 子：装飾語 OK（作業段階）
   ├ コンセプト開発/                 ← 子：装飾語 OK
   └ 初期リサーチ/                   ← 子：装飾語 OK

ライフネット生命_LifeNet/           ← 親：装飾語なし
   ├ ブランド戦略 2024/              ← 子：装飾語 OK（時期付き作業段階）
   └ ブランディング 2025/            ← 子：装飾語 OK

SNKRDUNK_スニーカーダンク/          ← 親
   ├ CD Proposals — Selection + Mockup Loop/  ← 子：成果物ループ記録
   └ ロゴ開発 Phase A〜D/            ← 子：作業フェーズ

洞察：「装飾語は識別子としては機能しないが、役割名としては機能する」。レイヤーで使い分けることで、Postel's law の「書く時厳格・読む時寛容」が親レベル＝厳格／子レベル＝寛容として実装される。

3-2-B. 装飾語のグラデーション

純度100%装飾語と純度100%固有名の間にグラデーションがある：

純度	装飾語例	扱い
装飾語 90%+	ブランディング・リブランディング・ブランド戦略	v0.3 で削除確定
装飾語 60-70%	リニューアル・リブランド・VIリニューアル	v0.3.1 で削除確定
装飾語 30-40%	プロジェクト・案件	ケースバイケース（固有名の一部かどうか文脈判断）
固有名 90%+	問読プロジェクト・虎ノ門広告祭2026	完全保持（例外）

新規語に出会ったら、まずこのグラデーションマップで判断する。判断不能なら工藤さんに上げる（Cowork B群 4件のパターン）。

3-2-C. 命名規則の進化トリガー

実運用で v0.3.x で判断不能なケースが発生したら、判断と同時に「v0.3.x 拡張提案」として上げる：

1. 新規装飾語の発見（例：「リニューアル」が v0.3 になかった → v0.3.1）
2. 新規装飾記号・絵文字の発見（例：「📚」が v0.3.1 になかった → v0.3.2）
3. グラデーション判定の境界事例（例：「DUNK CD Proposals — Selection + Mockup Loop」は親か子か）
4. 階層原則の例外（例：子レベルでも避けたい装飾語がある場合）

これらは Chat（私）が拾い上げて、Stage 2「命名規則策定／レビュー」のサブプロセスとして工藤さんに合意を取り、v0.3.x として永続化する。

3-2-D. ★NEW★ 装飾記号・絵文字削除ルール（v0.3.2・2026-05-15）

起点：2026-05-15 命名統一プロジェクトで 📚 Kudo Canon書籍プロジェクト ノードを発見。工藤さんの判断：「作業に関係しないなら、シンプルが一番だから変な記号とかは削除したほうがいいよ」。

削除対象：

カテゴリ	例	扱い
装飾的絵文字（識別目的でない）	📚 ✨ 🎯 🔥 ⭐ 🚀 💡 📝 🎨	削除
装飾的記号（識別目的でない）	★ ◆ ●（見出し風）	削除
件名見やすさのための余計な記号	→（矢印・流れを意味しない場合）	削除

保持例外：

カテゴリ	例	理由
作業に関係する記号	TODO: ／ DRAFT: ／ ARCHIVE:	状態識別子として機能
連番・順序	① ② ③ ／ 1. 2. 3.	順序情報
チェック状態	✓ ❌ 🔴 🟡 🟢	状態識別子
固有名の一部	T._テキスト の _ 等	識別子の構造

判断基準：その記号を取り除いて識別性・作業性が損なわれるか？ - 損なわれない → 削除（装飾） - 損なわれる → 保持（機能を持つ記号）

★NEW★ 適用範囲（v0.3.2-範囲限定・2026-05-15 Cowork v7 実証）：

本ルール（v0.3.2 装飾記号削除）は #project タグ付き案件ノードのみに適用する。日次ログ・自動生成セクション見出し・週次レビュー内のセクションヘッダ等のログ系ノードは対象外。

理由： - 日次ログの自動生成見出しは Cowork scheduled-tasks 等の automation の出力 - 個別改名は無意味（次回 automation 実行で復活する） - 真の改名対象は人間管理下の案件ノード（#project タグ付き）

起点：Cowork v7 Task 4 装飾的絵文字検索結果： - 📚: 22件（うち多くが週次レビューセクション見出し） - 🎯: 50+件（大半が日次ログ） - 💡: 50+件（大半が日次ログ） - → ★私見「絵文字ノードの大半は日次ログの自動生成セクション見出しで、改名対象にすべきではない」

実装：v8 一括改名スクリプト・validate_naming_consistency.py 軸6 ともに、#project タグ付きノード以外はスキップする。

核心原則（工藤拓真 2026-05-15）：

「作業に関係しないなら、シンプルが一番」

これは §3-2 装飾語削除ルールの「記号バージョン」。同じ思想：識別子は最小限の必要要素だけで構成する。

例： - 📚 Kudo Canon書籍プロジェクト → Kudo Canon書籍プロジェクト または装飾語ルールも適用して Kudo Canon書籍 - 🎯 純粋想起TOP10入り広報戦略 → 純粋想起TOP10入り広報戦略 - ✨ 新案件 #project → 新案件 #project

3-3. 装飾語削除の例外（固有名扱い）

以下は装飾語に見えても固有名の一部として保持： - 純粋想起TOP10入り広報戦略 — 工藤さん自己ブランディング戦略名 - 資産10倍戦略 — 工藤さん自己プロジェクト名 - 虎ノ門広告祭2026 — イベント固有名 - 問読プロジェクト — 案件固有名（井上くんと岩佐さんのサービス） - ベンチャープロジェクト1803- — BRANDFARM自社・複数フェーズ管理の便宜

3-4. 主表記の決定原則（Q5 合意）

ブランドロゴ・コミュニケーション上の第一表記を「主」とする。 - 単語型英字：先頭大文字（Uniqlo, Shiseido, Sony） - 頭字語型英字：全大文字維持（MUFG, ANA, NHK）

3-5. 廃止する習慣（Q3 合意）

• 日付プレフィックス全廃（1503, 2020, 2505, 2602, 2603, 2606 等）
• 例外：複数フェーズ管理のベンチャープロジェクト1803- は固有名として保持
• タイポ・括弧閉じ忘れ・全角半角混在をマスター名簿側で正規化して保持

3-6. 連結子と併記（Q1 合意）

• 連結子：アンダースコア _ 一択
• 併記：漢字（なければカタカナ・ひらがな）と英語の両方を含むこと

---

§4 6経路マッピング（環境分担・§16 v1.10 準拠）

経路	棚卸し担当	改名担当	根拠
① Mac ローカル ~/working/	Code	Code（mv）	ローカルFS書込権限（kudo-cowork-code-handoff-protocol §1-1）
② Google Drive	Chat（drive_search MCP）	Code 経由（Mac mv → Drive for desktop 自動同期）	Drive MCP に rename ツール不在（Entry #10）
③ claude.ai Project	工藤さん手動 or スクショ	工藤さん手動	API・MCP 不在
④ Claude Chat	工藤さん手動 or スクショ	工藤さん手動	API・MCP 不在
⑤ NotebookLM	工藤さん手動 or スクショ	工藤さん手動	API・MCP 不在
⑥ WorkFlowy	Cowork（workflowy MCP）	Cowork（workflowy MCP）	workflowy MCP は Cowork でのみ稼働（kudo-cowork-code-handoff-protocol §1-2）

4-1. 環境間の依存関係

[棚卸し] Chat（Drive読み取り） ─→ マスター名簿生成 ─→ Chat
                                       │
                  ┌────────────────────┴────────────────────┐
                  ↓                                          ↓
[実行] ① Mac mv (Code) ─同期→ ② Drive                ⑥ WorkFlowy (Cowork)
                                                              ↓
                                                       ③ claude.ai Project (手動)
                                                       ⑤ NotebookLM (手動)

4-2. 各経路の特徴

• ① + ② は一体：Mac ローカルが Drive for desktop の同期フォルダ（パターン A）なら、Mac の mv が自動的に Drive 側にも反映される（フォルダID 不変・共有リンク維持）
• ③ ④ ⑤ は手動：HTML 手順書を生成して工藤さんが Web UI で改名（kudo-html-publish で v0.4 形式）
• ⑥ WorkFlowy 独立：他経路と必ずしも 1:1 対応していない。命名規則 v0.3 を適用して個別判断

4-3. ★NEW★ 経路の役割の違い（包括 vs 選択的・2026-05-15 Cowork v7 実証）

実証データ：v0.5 マスター名簿 GDrive×YES 改名後の代表 10 案件を WorkFlowy で検索した結果、登録は4件のみ（Netflix・資生堂・MUFG・ライフネット生命・Uniqlo・東京国立博物館の6件は WorkFlowy 未登録）。

これは「6経路は対等ではなく、役割が違う」ことを示す：

経路	性質	含まれるもの
① Mac ローカル / ② Drive	包括（全クライアント案件の倉庫）	過去の全案件・終了済案件・参考資料含む
③ claude.ai Project	選択的（Claude と継続協業中の案件）	工藤さんが Claude と対話する案件のみ
④ Claude Chat	一過性（直近の会話）	関連付け不定・優先度低
⑤ NotebookLM	選択的（リサーチ中の案件）	案件知識ベースを構築する案件のみ
⑥ WorkFlowy	選択的（稼働案件トラッカー + 日次ログ）	「進行中プロジェクト」内の案件のみ＋活動の日々ログ

運用への影響： - 「② Drive にあるが ⑥ WorkFlowy にない」は 正常（終了案件や参考資料のみのため WorkFlowy 未登録） - 「⑥ WorkFlowy にあるが ② Drive にない」は 異常（稼働中なら必ず Drive にも資料があるはず） - マスター名簿（v0.5～）は ② Drive 基準で構築する。⑥ WorkFlowy は補助的な存在として扱う

判定マトリクス（命名統一の整合性チェック時）： - Drive のみ登録 → 正常（参考資料） - Drive ＋ WorkFlowy 両方登録 → 正常（稼働案件） - WorkFlowy のみ登録 → 要調査（Drive へのフォルダ作成漏れ？） - どちらにも未登録（claude.ai Project 等のみ）→ 要調査（命名統一の管理対象外？）

---

§5 5 Stage プロトコル

Stage 1：棚卸し（Inventory）

各経路の現状名を全件取得： - ① Mac：ls -la ~/working/顧客ビジネス/（Code） - ② Drive：drive_search で全フォルダ取得（Chat） - ③ Project：工藤さんが claude.ai プロジェクト一覧スクショ - ④ Chat：工藤さんが claude.ai 直近チャット一覧スクショ - ⑤ NotebookLM：工藤さんが NotebookLM 一覧スクショ - ⑥ WorkFlowy：workflowy_search(pattern="#project")（Cowork）

各エントリは以下の構造で集約（xlsx マスター名簿）：

現状名	経路	新名（統合スラッグ）	カテゴリ	状態	備考

「状態」列の値： - YES：改名対象 - NO：特殊事案・現状維持 - DELETE：削除対象 - RENAME-MAIN：統合先メイン - MERGE-DELETE：統合元（メインに統合後削除）

Stage 2：命名規則策定／レビュー

§3 命名規則 v0.3 を基準に、各エントリの新名を提案。判断項目（D1〜DN）を立て、工藤さんの合意を取る。合意したルールはこのスキルの §3 に永続化する（規則の進化）。

Stage 3：マスター名簿生成

xlsx 形式で以下を集約： - Sheet 1：マスター名簿（全件） - Sheet 2：命名規則（v0.3） - Sheet 3：統合手順（Lifenet 統合などの特殊ケース） - Sheet 4：6経路マッピング

xlsx は NFC 正規化必須（§6 参照）。マスター名簿のファイル名は naming-master-list-vN.M.xlsx（v0.1, v0.2, ... と進化）。

Stage 4：経路別実行

§4 マッピング通りに環境分担して並行実行： - ① ② → Code（HANDOFF.md 渡す） - ③ ④ ⑤ → 工藤さん手動（HTML 手順書 v0.4） - ⑥ → Cowork（指示書渡す）

各経路で dry-run → 工藤さん承認 → 本番 の二段ステップ必須。Chat が承認判断の中央集権点。

Stage 5：永続化／監視

• ~/.claude/scripts/validate_naming_consistency.py：6経路の現在名 vs マスター名簿の整合性を週次チェック
• LaunchAgent com.kudo.validate-naming-consistency：月曜 4:00 cron
• 揺れ検出時は Slack DM or WorkFlowy ノートに自動レポート

---

§6 文字正規化チェックプロトコル（フォートレス問題教訓・2026-05-15）

6-1. 起点

2026-05-15 命名統一プロジェクト Phase 2 実行時、フォートレス(かんぽ がマスター名簿側半角カッコ／Mac 実体側全角カッコでズレ、66/67件成功・1件欠落の結果に。

6-2. 構造的問題

xlsx などツール経由で取得した文字列と、実体ファイルシステムの文字列は Unicode 正規化レベルで一致しないことがある：

カテゴリ	例	対処
半角/全角カッコ	( vs （	NFC 正規化＋全角統一を機械的に実施（v2.3 追加・後述の §6-3 プロトコル）
濁点合成/分解	が（NFC: U+304C）vs か+ ゙（NFD: U+304B U+3099）	macOS HFS+/APFS は NFD で保存することがある。NFC 正規化必須
ハイフン種類	- vs ‐ vs ‒ vs – vs —	NFC 正規化＋種類統一
全角/半角スペース	vs	全角に統一 or 半角に統一
末尾スペース	ライフネット生命 #project vs ライフネット生命 #project	末尾スペースを strip() で除去（v2.3 追加）
機種依存文字	① ② ③（U+2460-2462）vs 1. 2. 3.	機種依存文字は基本廃止

6-2-A. ★NEW★ 末尾スペース問題（v2.3 追加・2026-05-15 Cowork v7 実証）

起点：Cowork v7 で 04a4b097: ライフネット生命 #project （末尾スペース付き）を発見。v0.4 マスター名簿に未登録。WorkFlowy 検索では ライフネット生命 でヒットするが、xlsx/grep 系では一致しない。

プロトコル： - すべての文字列正規化処理に .strip() を必須化 - xlsx 生成時にもセル値の前後スペースを削除 - WorkFlowy ノード名取得時にも末尾スペース検出を実装

def normalize(s: str) -> str:
    s = unicodedata.normalize('NFC', s)
    s = s.strip()  # ★v2.3 追加：末尾スペース除去
    s = s.replace('(', '（').replace(')', '）')  # カッコ全角統一
    return s

6-2-B. ★NEW★ xlsx 生成時の全角カッコ統一（v2.3 追加・2026-05-15 リスクマネジメント検出）

起点：Code v3 validate 初回テストで リスクマネジメント（広報含む） が軸2 未登録として検出。マスター名簿 v0.5 には リスクマネジメント(広報含む)（半角カッコ）で登録されており、Mac 実体は全角カッコ。フォートレス問題と同じ構造。

プロトコル： - マスター名簿生成スクリプトで、セル値を全角カッコに機械的に統一 - xlsx → DataFrame 読込時にも正規化レイヤーを挟む - これにより半角／全角の揺れを根絶

6-3. プロトコル骨子

xlsx 生成時

import unicodedata
def normalize(s: str) -> str:
    """マスター名簿のセル文字列を NFC 正規化＋カッコ全角統一"""
    s = unicodedata.normalize('NFC', s)
    s = s.replace('(', '（').replace(')', '）')  # カッコは全角統一
    return s

dry-run スクリプト生成時

# 比較は必ず NFC 正規化済み同士で
old_local = unicodedata.normalize('NFC', local_filename)
old_master = unicodedata.normalize('NFC', master_filename)
if old_local != old_master:
    # 揺れ検出→レポート
    report.append((local_filename, master_filename, "NFC mismatch"))

検出時の対応

1. 揺れの種類を判定（半角全角／NFC-NFD／ハイフン種類等）
2. v0.5 改訂対象としてマーク
3. 既に進んだ作業はロールバックしない（個別 mv で吸収）
4. マスター名簿側を実体側に合わせる or 実体側をマスター名簿側に合わせるかは案件次第

6-4. 関連

• kudo-ai-error-watchlist Entry #10（MCP機能の暗黙仮定禁止）と同種：「事前検証していれば防げた問題」
• validate_naming_consistency.py は本プロトコルを内蔵する

---

§7 ファジー検索プロトコル（Postel's law）

7-1. 思想

書く時は厳格に統一（§3）・読む時は寛容に揺れを許容。マスター名簿で統一されていても、過去のチャット・WorkFlowy・別ツールには旧名が残る。検索時に旧名で取りこぼすと致命的。

7-2. ファジー検索の実装

案件名のエイリアス展開

aliases = {
    "ライフネット生命_LifeNet": [
        "ライフネット生命_LifeNet",  # 新名
        "2511ライフネットブランド戦略",  # 旧名1
        "Lifenet Rebranding",  # 旧名2
        "ライフネット生命リブランディング",  # 旧名3
        "Lifenet",  # 略称
        "ライフネット",  # 略称
        "lifenet",  # 小文字
    ],
    "ミツカン_Mizkan": [
        "ミツカン_Mizkan", "ミツカン", "Mizkan", "mizkan", "mitsukan",
    ],
}

検索時の動作

1. ユーザーが「ミツカン案件で〜」と発言
2. ファジー検索が aliases["ミツカン_Mizkan"] 全エントリで検索
3. どの旧名にヒットしても新名のコンテキストに集約

7-3. WorkFlowy / conversation_search への適用

conversation_search(query="ミツカン") でも conversation_search(query="Mizkan") でも同じチャットがヒットすべき。これは MCP 側の挙動次第なので、ヒットしない場合は両方検索する：

results = set()
for alias in aliases[canonical_name]:
    results.update(conversation_search(query=alias))

7-4. kudo-context-routing との連携

新規案件着手時に kudo-context-routing が起動される際、本プロトコルの aliases 辞書を参照して 4経路（WorkFlowy ／クラウド ／ claude.ai Project ／ファイル名）の現状を fuzzy search する。

---

§8 Phase 別 HANDOFF テンプレ

8-1. Code 向け HANDOFF（Mac ローカル改名）

HANDOFF-mac-local-rename-vN.md の構造： - §0 ファイル配置マップ（同梱物 vs 外部参照物） - §1 前提（なぜ Code 側で実行するか・スコープ・絶対禁止事項） - §2 Stage 0：同期状態判別 - §3 Stage 1：棚卸し - §4 Stage 2：dry-run スクリプト生成（NFC 正規化含む） - §5 Stage 3：本番実行 - §6 Stage 4：完了報告 - §7 ロールバック手順 - §8 完了後の連携

8-2. Cowork 向け 指示書（WorkFlowy 改名）

COWORK-workflowy-rename-vN.md の構造： - §0 エラーリセット - §1 WorkFlowy MCP 接続確認 - §2 棚卸し（#project タグ） - §3 マスター名簿との突き合わせ - §4 dry-run 提案を Chat に戻す - §5 承認後の本番実行 - §6 報告フォーマット

8-3. 工藤さん手動向け HTML 手順書

{経路}-rename-guide-vN.html（kudo-html-publish v0.4 形式）： - mixed mode（external 本体 + internal 議論用） - チェックボックス付き進捗バッジ - 進捗 N/M 表示 - @media print で internal 自動除外

---

§9 永続化スクリプト：validate_naming_consistency.py

9-1. 役割

6経路の現在名 vs マスター名簿（最新版）の整合性を週次チェック。揺れを検出したら Slack DM or WorkFlowy ノートにレポート。

9-2. 配置

• スクリプト：~/.claude/scripts/validate_naming_consistency.py
• LaunchAgent：~/Library/LaunchAgents/com.kudo.validate-naming-consistency.plist
• 実行頻度：月曜 4:00 cron
• マスター名簿：~/working/_claude_workspace_global/master-lists/naming-master-list-vN.M.xlsx（最新版・最大 vN.M を最新と判定）
• 旧配置 ~/Downloads/naming-master-list-vN.M.xlsx は廃止（2026-05-15 集中原則ガバナンス導入により、kudo-shared-storage-protocol v1.2 §5.5 / CLAUDE.md §3.1 に準拠して移行）

9-3. 検査軸

1. NFC 正規化整合性：xlsx vs Mac vs Drive vs WorkFlowy のすべてを NFC 正規化して比較
2. エイリアス完備：マスター名簿の「現状名」が aliases 辞書に登録されているか
3. 装飾語残存：「リブランディング」「ブランディング」等の装飾語が新名側に残っていないか
4. 日付プレフィックス残存：「1503」「2606」等が新名側に残っていないか
5. 6経路完全性：①〜⑥のうち改名対象経路で実行漏れがないか

9-4. レポート出力

• ✅ 全経路一致：何もしない
• 🟡 軽微な揺れ（NFC 等）：WorkFlowy「1日1新およびToDo」ノートに追記
• 🔴 重大な揺れ（装飾語残存・経路間不整合）：Slack DM @takumakudo

9-5. Code 宛 HANDOFF

HANDOFF-validate-naming-consistency-setup.md を別途生成： - スクリプト本体 - LaunchAgent plist - 初回テスト実行手順 - Slack Webhook URL 設定（kudo-context-routing 経由）

---

§10 関連スキル

上流（本スキルを呼ぶ側）

• kudo-context-routing：新規案件着手時に本スキルの aliases を参照
• kudo-persist-settings：本スキルの規則を運用ルールとして参照

下流（本スキルから呼ぶ側）

• kudo-cowork-code-handoff-protocol §16 v1.10：環境分担マトリクスの実装根拠
• kudo-html-publish v0.4：工藤さん手動向け HTML 手順書の生成エンジン
• kudo-ai-error-watchlist Entry #9 #10：先延ばし禁止 SOP / MCP 機能仮定禁止 SOP

横（同期して稼働）

• kudo-workflowy-double-save §1.1〜§1.3：WorkFlowy 書込ルールとの整合（命名統一は「C. 案件別蓄積系」分類への影響大）

---

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

• core-principle — §1 概要・Postel's law 思想
• triggers — §2 起動トリガー
• naming-rule-v03 — §3 命名規則 v0.3 SSOT
• decoration-removal — §3-2 装飾語削除ルール
• decoration-exception — §3-3 装飾語削除の例外
• six-route-mapping — §4 6経路マッピング
• five-stage-protocol — §5 5 Stage プロトコル
• unicode-normalization — §6 文字正規化チェックプロトコル
• fuzzy-search — §7 ファジー検索プロトコル
• handoff-templates — §8 Phase 別 HANDOFF テンプレ
• persistence — §9 validate_naming_consistency.py

---

§12 改訂履歴

• v2.4（2026-05-15・集中原則ガバナンス Phase 3 Part B-1）：§9-2 配置の「マスター名簿パス」を ~/Downloads/ から ~/working/_claude_workspace_global/master-lists/ に移行。kudo-shared-storage-protocol v1.2 §5.5 および CLAUDE.md §3.1 に準拠。Phase 2 grep 監査（reports/2026-05-15-phase2-grep-report.md）で唯一の Pattern 1 実質違反として検出された箇所の解消。validate スクリプト本体（v3 化時）の XLSX パス定数も同方針で更新する。

• v2.3（2026-05-15・Cowork v7 + Code v3 報告後）：実証フィードバック 3 点を反映：

• §3-2-D に適用範囲を明記：v0.3.2 装飾記号削除ルールを #project タグ付き案件ノードのみに限定。日次ログ系・自動生成セクション見出しは対象外。Cowork v7 で発覚した「絵文字ノード大半が日次ログ起源」という構造的事実を反映
• §4-3 経路の役割の違いを新設：Mac/Drive（包括）vs claude.ai Project/NotebookLM/WorkFlowy（選択的）の非対称性を明文化。判定マトリクスを追加
• §6-2-A 末尾スペース問題、§6-2-B xlsx 生成時の全角カッコ統一を新設：Cowork v7 の 04a4b097（末尾スペース）、Code v3 の リスクマネジメント（全角カッコ揺れ）の発見を恒久的プロトコルとして永続化

• 関連：kudo-ai-error-watchlist Entry #12（ログ系改名と案件ノード改名の混同）/ Entry #13（過去生成ログ ID 誤情報）/ Entry #14（Chat 出力ファイル保存先 = Desktop）を新規追加

• v2.2（2026-05-15・命名統一プロジェクト Cowork v3 報告後）：WorkFlowy 実証で 📚 Kudo Canon書籍プロジェクト ノードを発見し、工藤さんの判断「作業に関係しないなら、シンプルが一番だから変な記号とかは削除したほうがいいよ」を起点に §3-2-D を新設：

• §3-2-D 装飾記号・絵文字削除ルール（v0.3.2）：装飾的絵文字（📚 ✨ 🎯 等）と装飾的記号を削除する規則を明文化
• 削除対象 vs 保持例外（連番・チェック状態・固有名の一部）の判断マトリクスを内蔵
• §3-2-C を更新：「v0.3.x 拡張提案」のフィードバックループに「新規装飾記号・絵文字の発見」（v0.3.1 → v0.3.2 の進化軌跡）を追加

• 核心原則「作業に関係しないなら、シンプルが一番」を §3-2-D に永続化

• v2.1（2026-05-15・命名統一プロジェクト Cowork v2 報告後）：WorkFlowy 実証フィードバックを §3 に反映：

• §3-2 装飾語リストを v0.3 → v0.3.1 へ拡張（リニューアル／ブランドリニューアル／リブランド／VIリニューアル 追加）
• §3-2-A 階層原則を新設：「親レベル＝装飾語削除／子レベル＝装飾語OK（役割名として機能）」を明文化
• §3-2-B 装飾語のグラデーション可視化（純度別の判断基準）
• §3-2-C 命名規則の進化トリガー（実運用で判断不能になった事例を v0.3.x 拡張に変換するフィードバックループ）

• 工藤さんの判断「リニューアルとかは、プロジェクト名の下のフォルダで創るのはいいけど、ネーミングからは排除がいいね」を起点として階層原則を発見

• v2.0（2026-05-15）：実体ファイル消失中の v1.1 から完全再構築。命名統一プロジェクト（2026-05-14〜15）の実証経験を全反映：

• §3 命名規則 v0.3 を SSOT として明文化（Q1-Q9 合意・装飾語削除ルール）
• §4 6経路マッピング新設（kudo-cowork-code-handoff-protocol §16 v1.10 と連動）
• §5 5 Stage プロトコル新設（棚卸し→規則策定→マスター名簿→経路別実行→永続化）
• §6 文字正規化チェックプロトコル新設（フォートレス問題教訓・NFC/NFD・半角全角カッコ）
• §7 ファジー検索プロトコル新設（Postel's law）
• §8 HANDOFF テンプレ 3種類整理（Code / Cowork / 工藤さん手動 HTML）
• §9 validate_naming_consistency.py 永続化スクリプト構造設計
• kudo-ai-error-watchlist Entry #9 / #10 教訓を §10 関連スキルとして相互参照

• 2026-05-15 実証：Drive 81件中66件 Code 経由で改名完了・1件フォートレス問題発覚→§6 として永続化

• v1.1（2026-04-27・実体消失）：ミツカン・TOHAKU・SmartNews・YAMAP・Text・TOKYOPRIMEの5案件で4経路統一＋20以上のファイルリネームを完遂・ファジー検索プロトコル追加。v2.0 起草時点で実体ファイル消失中、本 v2.0 で全面再構築。

• v1.0（2026-04-27 以前）：Postel's law 原則・統一プロトコル＋ファジー検索プロトコルの両輪構造を初期確立。