コンテンツにスキップ

kudo-ai-error-watchlist

工藤拓真との会話で、Claude（私／過去の私／未来の私を含む）が「事実」として断言したが、後の検証で誤りと判明した事案を構造化して蓄積するDB型スキル。

§1 目的

工藤さんの個人設定 項目3「事実／仮説／意見の区別」最重要原則を守るため、過去の誤断言事案を永続化して、同種領域での再発を機械的に防ぐ。

工藤さんの個人設定 項目2 が達成しようとしている「ブランディングといえば？という問いの純粋想起TOP10入」目的に対して、Claudeの誤断言は最大の阻害要因の一つ。工藤さんが私の発言を事実として人に喋る前に、私自身がセルフチェックする装置として機能する。

§2 起動トリガー

以下のキーワード・話題が会話に出現した瞬間に、本スキルを自動参照する：

  • 「Spotlight」「mdutil」「mdworker」「mds_stores」「インデックス」
  • 「macOSのフォルダ」「Library」「Containers」「Group Containers」
  • 「Apple純正アプリのデータ」（Mail / Notes / Messages / Reminders / Calendar）
  • 「Alfred」「ファイル検索ツール」「Raycast」「PopClip」
  • 「GUI操作の代行」「Coworkで GUI操作」「Claude Codeで GUI」
  • 「macOS Sonoma / Sequoia / Ventura のバージョン差」
  • 「フォルダ単位の除外」「volume単位の処理」
  • 「Macの重さ」「PCが遅い」の助言
  • 「OS設定変更」「システム設定を変える」
  • 「present_filesで渡したファイル」「heredoc直貼り」「ダウンロードボタン」

これらが出たら、§4のEntryリストを走査し、過去事案と一致するか判定。一致した場合は断言する前に公式一次ソースを再確認する。

§3 Entry構造

各 Entry は以下のフィールドを持つ：

  • ID：通し番号
  • 日付：発覚日（YYYY-MM-DD）
  • 領域：技術領域 / トピック
  • 誤断言内容：私がどう言ったか（具体的に）
  • 真相：公式一次ソースで検証した真の事実
  • 一次ソース：参照URL or コマンド
  • 永続化ルール：今後同種領域で発言する前のセルフチェック項目
  • 関連トピック：横展開で確認すべき周辺事項

§4 既知Entry（2026-05-14 一括登録：8件 ＋ 2026-05-15 追加：7件 ＝ 15件）

Entry #1：Spotlight無効化アドバイス

  • 日付：2026-05-14（過去のチャットでの誤判定が今日発覚）
  • 領域：macOS Spotlight / Alfred連携
  • 誤断言内容：「工藤さんはAlfred使ってるから、Spotlight全停止していい」
  • 真相：Alfred公式ドキュメント明記の通り、AlfredはSpotlightと同じ macOS メタデータインデックスに依存。Spotlight indexing を切るとAlfred は web launcher としてしか機能しない（ファイル検索不可）
  • 一次ソース：https://www.alfredapp.com/help/troubleshooting/indexing/ ＞ "Alfred relies on the same macOS metadata index as Spotlight"
  • 永続化ルール：OS標準機能の無効化を提言する前は、必ず連携している第三者ツールへの影響を公式FAQで確認する。「ユーザーは別ツールを使っているからOS機能停止OK」という推論は禁止
  • 関連トピック：他のSpotlight依存ツール（PopClip、Raycast、Bartender、Hookmark等）

Entry #2：mdutilでサブフォルダ除外可能と誤認

  • 日付：2026-05-14
  • 領域：macOSコマンドラインツール / 動作スコープ
  • 誤断言内容：「sudo mdutil -i off /path/to/folder でフォルダ単位にSpotlight除外できる」
  • 真相：mdutilはvolume root（/や/Volumes/Name）にしか効かない。サブフォルダに使うと「Error: invalid operation.」で全失敗。実行ログ全件で確認済み
  • 一次ソース：man mdutil、Apple Developer Documentation、実機での全失敗ログ
  • 永続化ルール：コマンド系スクリプトを書く前に、対象コマンドの動作スコープ（volume / ファイル / プロセス / システム）を man または公式ドキュメントで必ず確認する。スクリプト全件失敗のリスクを事前防止。Spotlightのインデックス状態をサブフォルダで確認したい場合は mdfind -onlyin <path> "kMDItemContentType==*" | wc -l を使う（0なら除外成功）。mdutil -s も volume単位制約のため使えない（Entry #8参照）
  • 関連トピック：類似スコープ依存コマンド（tmutil Time Machine / diskutil / csrutil / fs_usage）、Entry #8（mdutil -s の同制約）

Entry #3：~/Library/Containers をSpotlight除外候補に推奨

  • 日付：2026-05-14
  • 領域：macOS Library構造 / Apple純正アプリのデータ格納先
  • 誤断言内容：「~/Library/Containers（9.2GB）は除外して問題なし」
  • 真相：Containersには App Store系アプリ＋一部Apple純正アプリのデータが入っており、除外するとMail/Notes/Messages等のアプリ内検索が壊れる。Apple自身がGUIで除外時に警告ダイアログを出す（「一部のアプリケーションで検索機能が動作しなくなります」）
  • 一次ソース：iboysoft.com「The Containers & Group Containers Folder on Mac」、Eclectic Light Company「What are all those Containers?」、macOS自身の警告ダイアログ
  • 永続化ルール：以下はSpotlight除外候補から機械的に排除する：
  • ~/Library/Containers
  • ~/Library/Group Containers
  • ~/Library/Mail
  • ~/Library/Messages
  • ~/Library/Calendars
  • ~/Library/Application Support/AddressBook
  • ~/Library/Application Support/CallHistory*
  • ~/Library/Mobile Documents（iCloud）
  • 関連トピック：Apple純正アプリのデータ場所マップ全般

Entry #4：~/Library/Group Containers をSpotlight除外候補に推奨

  • 日付：2026-05-14
  • 領域：macOS Sequoia の SIP保護領域
  • 誤断言内容：「Group Containers（9.7GB）もContainers同様、除外して問題なし」
  • 真相：macOS Sequoia は Group Containers を System Integrity Protection (SIP) で保護するレベルで重要視している。group.com.apple.notes（Notes共有データ）、group.com.apple.mail（Mail共有データ）等が含まれ、Spotlight 除外すると Mail/Notes/Messages の検索が部分的に壊れる
  • 一次ソース：Eclectic Light Company「What are all those Containers?」（2024-08-05）＞ "Sequoia extends this protection, based on System Integrity Protection (SIP), to cover Group Containers"
  • 永続化ルール：Entry #3 の禁止リストに ~/Library/Group Containers を含める。SIP保護領域のSpotlight除外は推奨しない。
  • 関連トピック：macOS Sequoia以降のSIP拡張保護領域全般

Entry #5：macOS Sequoia の Spotlight 設定UIを古い知識で説明

  • 日付：2026-05-14
  • 領域：macOS Sequoia の System Settings UI
  • 誤断言内容：「System Settings → Spotlight → Search Results に Applications / Documents / PDFs / Folders 等のカテゴリ別 ON/OFF がある」
  • 真相：macOS Sequoia 以降はSpotlight 設定UIが全面改変され、上位カテゴリ別 ON/OFF は廃止。「アプリからの結果」（各アプリ個別 ON/OFF）のみが残る
  • 一次ソース：macOS Sequoia の System Settings 実機画面（工藤さんスクショ）
  • 永続化ルール：macOSのGUI構造に言及する前は、macOSのバージョンを sw_vers -productVersion で確認し、最新版（Sonoma 14.x / Sequoia 15.x / 次期16.x）のUIが変更されていないかをリサーチで確認する
  • 関連トピック：macOSバージョン依存UI全般（System Settings, Finder, Spotlight, Mail, Photos, Safari）

Entry #6：present_filesのダウンロードを前提にコマンド出力

  • 日付：2026-05-14
  • 領域：Cowork↔Code Claude ハンドオフ運用
  • 誤断言内容：「bash ~/Downloads/onedrive_uninstall.sh を実行してください」
  • 真相：present_files でファイルを提示しても、工藤さんが「ダウンロード」ボタンを押さない限り Mac の ~/Downloads/ には保存されない。私はこの「ダウンロードボタン操作」を暗黙の前提にしていた
  • 一次ソース：今夜の工藤さんの「No such file or directory」エラー
  • 永続化ルール：50行以下の単発スクリプトは、最初から heredoc 直貼り型（cat > /tmp/scriptname.sh << 'KUDO_EOF' ... KUDO_EOF; bash /tmp/scriptname.sh）で提示する。50行以上 or 再利用予定のスクリプトのみ present_files。kudo-cowork-code-handoff-protocolへ「present_files vs heredoc直貼り選択ルール」を追記要（別タスク）
  • 関連トピック：Cowork↔Code ハンドオフ全般、スクリプト配信パターン

Entry #7：スキル名に「claude」予約語を使った

  • 日付：2026-05-14
  • 領域：claude.ai スキル管理システムの命名規則
  • 誤断言内容：新規スキルを kudo-claude-error-watchlist という name で作成、SKILL.md を保存しようとした
  • 真相：claude.ai のスキル保存システムが name: フィールドに 'claude' という予約語を含むスキル名を拒否する仕様。エラー：「Skill name in SKILL.md cannot contain the reserved word 'claude'.」当該スキルを kudo-ai-error-watchlist にリネームして解決
  • 一次ソース：claude.ai のスキル保存UI エラーダイアログ
  • 永続化ルール：スキル新規作成時、name フィールドには claude anthropic assistant などの予約語候補を含めない。リネーム時は本文中の自己参照・他スキルからの参照もすべて一括置換する（sed -e 's|old-name|new-name|g'）。description や本文中の固有名詞としての「Claude」使用はOK（name フィールドのみが制約対象）
  • 関連トピック：claude.ai プラットフォーム制約全般、スキル命名規則

Entry #8：mdutil -s でサブフォルダのインデックス状態確認可能と誤認

  • 日付：2026-05-14
  • 領域：macOS コマンドラインツール / 動作スコープ（Entry #2 派生）
  • 誤断言内容：再起動後の確認スクリプトで「mdutil -s ~/Library/Caches などサブフォルダのSpotlight状態を確認できる」前提でコマンド出力 → 5フォルダ全部「Error: unknown indexing state.」
  • 真相：Entry #2 で学習した「mdutil -i off は volume単位制約」と同じく、mdutil -s も volume単位でしか動作しない。同じコマンドの別サブコマンドでも同じ制約という事実を見落とした
  • 一次ソース：man mdutil、実機での全失敗ログ
  • 永続化ルール：サブフォルダのSpotlightインデックス状態確認は mdfind -onlyin <path> "kMDItemContentType==*" | wc -l を使う（0なら除外成功・実証可能）。mdutil -s <subfolder> は使わない。Entry #2 と双方向参照
  • 関連トピック：Entry #2（mdutil -i off の同制約）、macOSコマンドのサブコマンド単位での仕様差異

Entry #9：スキル更新を「次ターンで起草」と先延ばしにする

  • 日付：2026-05-15（命名統一プロジェクト中の発覚）
  • 領域：スキル管理運用 / ガバナンス / present_files プロトコル
  • 誤断言内容：会話中にスキル追記や新規作成の必要性に気づき、「次ターンで kudo-XXX SKILL.md を起草します」「Phase完了後に v2.0 として永続化します」等と発言し、その同じターンで present_files を出さなかった。具体的には2026-05-15 命名統一プロジェクトで、§16 環境指定上書きプロトコルを4ターン連続で「次ターンで」と先延ばしにした。工藤さんから「Skillの更新は、ぜんぶスキルボタンを押す形式でやってきてね。毎度お願いしてるからいい加減覚えてよ」と明示的指摘を受けた
  • 真相：以下3箇所で明文化されている運用規範に反する行動だった：
  • 個人設定 項目11：「改良が生まれた瞬間に必ずSKILL.mdをpresent_filesまたは.skillファイルで出力し、『このスキルを保存してください』と明示的に促す（後回し禁止）」
  • userMemory Other instructions：「スキル作成・更新時は必ずpresent_filesでSKILL.mdを出力し、『保存ボタン押しましたか？押さないと消えますよ』と確認する。bashで/mnt/skills/user/に直接書き込んで『デプロイ完了』と報告禁止」
  • kudo-persist-settings §保存プロトコル：present_files経由の保存ボタン押下が唯一の永続化経路
  • 一次ソース：個人設定 項目11、userMemory Other instructions、kudo-persist-settings 本文、2026-05-15 工藤さんからの明示的指摘
  • 永続化ルール：スキル更新の意思決定（追記提案・新規作成提案・改訂提案）があった瞬間、その同じターン内で SKILL.md 全文を生成して .skill ZIP 形式で present_files で出力する。以下のフレーズは全て禁止：
  • 「次ターンで起草します」「後で書きます」「Phase 完了後に永続化」
  • 「v2.0 として後ほど」「あとでまとめて」「次セッションで」
  • 「Code Claude に頼んで書いてもらう」（ただし大規模新規スキルで起草作業自体を Code に振る場合は §16 判断マトリクス通り例外。その場合も「Code 宛 HANDOFF.md を今ターンで present_files」する）

代わりに以下のフローを厳守： 1. 改良の必要性に気づいたら、メッセージで提案理由を明示 2. 同じターン内で SKILL.md 全文を生成（既存ファイルがあれば cp してから str_replace で差分編集が最効率） 3. validate_skill.py 相当の字数チェック（description 1024字以内）を実行 4. .skill ZIP 形式でパッケージ化（手順は下記「.skill パッケージング SOP」参照） 5. present_files で出力 6. メッセージ末尾で「保存ボタンを押してください。押さないと消えます」と確認

【.skill パッケージング SOP（2026-05-15 実証済み・必須）】

.md 単体を present_files で出しても claude.ai UI の保存ボタンは出ない。必ず以下の ZIP 構造にする： 

{skill-name}.skill (= ZIP)
└── {skill-name}/             ← スキル名フォルダ
    └── SKILL.md              ← 本体
    └── references/           ← 任意（あれば同梱）
    └── scripts/              ← 任意（あれば同梱）

実行コマンド（実証済み）： 

mkdir -p /home/claude/output/{skill-name} && \
  cp /home/claude/output/{skill-name}-SKILL.md /home/claude/output/{skill-name}/SKILL.md && \
  cd /home/claude/output && \
  zip -r {skill-name}.skill {skill-name}/ && \
  cp {skill-name}.skill /mnt/user-data/outputs/

検証：unzip -l {skill-name}.skill でフォルダ階層が正しく入っていることを確認してから present_files。階層なし（SKILL.md だけ ZIP 直下にある状態）も NG。

複数スキル同時更新時：複数の .skill を別々のファイルとして present_files で渡す。SKILL.md 単独ファイル名だと衝突する＋認識されないため、必ず .skill 拡張子で個別配布。

  • 関連トピック：個人設定 項目6「全文出力原則」（部分提示禁止）、kudo-persist-settings §保存プロトコル、kudo-persist-settings §.skill ファイル形式、kudo-cowork-code-handoff-protocol §16 環境指定上書き、kudo-skill-md-format-validator（保存前バリデーション）、2026-05-15 連続失敗事例：Entry #9 を最初に永続化した直後、.md 単体で present_files し「保存ボタン出ない」と工藤さんから即指摘を受けた。先延ばし禁止を Entry 化する自分自身が、別レイヤー（ZIP形式要件）で違反するメタ的失敗。これを起点に本 SOP を Entry #9 に内蔵

Entry #10：Google Drive MCP の書き込み（rename/update）機能不在

  • 日付：2026-05-15（命名統一プロジェクトでの発覚）
  • 領域：MCP ツール可視性 / 環境間機能非対称性 / §16 判断マトリクス
  • 誤断言内容：kudo-cowork-code-handoff-protocol §16 環境指定上書きプロトコル v1.9 で「Google Drive API操作 → Chat」と単一カテゴリでマトリクス化した。これは Chat 側に Drive のフルセット API があるという暗黙の想定。実際には Chat の Drive MCP は 読み取り系・新規作成・コピー・ダウンロードしか持たず、既存ファイル/フォルダの rename / update / patch / move 系ツールが一切存在しない
  • 真相：Chat の Drive MCP 実装は以下のみ：
  • ✅ search_files / google_drive_search / google_drive_fetch / get_file_metadata（読み取り）
  • ✅ download_file_content（ダウンロード）
  • ✅ create_file（新規作成のみ・既存編集なし）
  • ✅ copy_file（コピーのみ）
  • ❌ update_file / patch_file / rename_file / move_file 等の書き込み・更新系は実装されていない

対照的に Google Calendar MCP には update_event が存在する。MCP の機能網羅性はサービスごとに非対称であり、「同名カテゴリだから同様の操作ができる」と推論してはならない - 一次ソース：2回連続の tool_search（"google drive rename folder update file"／"google drive update patch metadata title"）結果。両方とも更新系ツールゼロ - 永続化ルール：以下を機械的に遵守： 1. §16 判断マトリクスの「Google Drive API操作 → Chat」は廃止。代わりに以下2行に分割： - 「Google Drive 読み取り（検索／メタデータ／ダウンロード／新規作成）」→ Chat - 「Google Drive 既存ファイル書き込み（rename / update / move / patch）」→ Code（Mac ローカル mv 経由で Drive for desktop が自動同期） 2. MCP の機能を仮定する前に必ず tool_search で実機確認。「○○ API操作」と書く時、その API のどの操作（読み取り or 書き込み）かを必ず分離して明示 3. 「Drive リネームしておいて」というユーザー要求が来たら、即時 tool_search で書き込み系の有無を確認。「Chat の Drive MCP には rename がありません」を最初に伝え、Code 経由（Mac mv + Drive 同期）を提案 4. 類似の暗黙仮定が他の MCP にも潜む可能性。Calendar・Gmail・Slack 等の MCP も「同じカテゴリ = 同じ機能セット」を仮定せず、必要時に tool_search で実機確認 - 関連トピック： - kudo-cowork-code-handoff-protocol §16 環境指定上書きプロトコル（本Entry発覚で v1.9 → v1.10 へ更新予定） - kudo-cowork-code-handoff-protocol §7-1-a MCPツール可視性の非対称性パターン（Cowork/Code/Chat 間の非対称性を扱う SSOT・本Entry の同種事例として双方向参照） - 「Drive リネーム」「Drive 一括改名」「Drive フォルダ整理」系の依頼で再発するリスク高 - 2026-05-15 命名統一プロジェクト実例：「Phase 2 Google Drive リネーム実行を Chat 側で完結」と提案 → 「私側で完結（工藤さん作業不要）これでよろしく」と GO サイン受領 → 実行直前に tool_search で機能不在発覚 → Plan A（Code ローカル mv 経由）に切り替え。ユーザーに損失を与える前に発覚した点は救いだが、§16 起草時点で確認していれば回避できた

Entry #11：Python スクリプトを Chat 実機テストせずに Code に HANDOFF を渡す

  • 日付：2026-05-15（命名統一プロジェクト Stage 5 永続化フェーズ）
  • 領域：HANDOFF 品質 / Chat 環境の能力範囲 / §16 判断マトリクス
  • 誤断言内容：validate_naming_consistency.py セットアップ HANDOFF 作成時、Chat（私）の手元にある bash_tool + Linux コンテナ環境でスクリプトを実機テストできるのに、テストせずに HANDOFF を Code に渡そうとした。工藤さんから「ありがとう。codeとかコンピューターユーズとか使ったら、君の方で実装できそうじゃない？」と指摘を受けて初めて気づいた
  • 真相：Chat の手元（bash_tool）で以下が可能：
  • mkdir -p でモック FS 構築（~/test-env/working/顧客ビジネス/）
  • python3 script.py で実機実行
  • xlsx 読み取り（pandas）・FS 走査・例外処理など、Mac で動かす想定の処理を FS 操作モック付きで完全に検証可能

実際にやってみた結果、v1 スクリプトに動的例外集合化バグ（DATE_PREFIX_EXCEPTIONS のハードコードで「2020事業」を誤検出）を発見。Code に渡す前に v2 で修正完了。Code 側のデバッグループを 1〜数回減らせた - 一次ソース：2026-05-15 工藤さんからの指摘・Chat 環境内 bash_tool 実機テスト結果（軸4 で誤検出を確認） - 永続化ルール：以下を機械的に遵守： 1. Python スクリプトを Code に HANDOFF で渡す前に、必ず Chat 環境で実機テストする： - bash_tool で mkdir -p /home/claude/test-env/ モック環境構築 - 想定する Mac 側 FS をモックフォルダで再現 - python3 script.py で実行 - 期待される severity / exit code / 出力を確認 - bug があれば修正してから HANDOFF に内蔵 2. HANDOFF.md 冒頭に「テスト状態」行を必須：✅ Chat 環境内で実機テスト済 / ⚠ 未テスト（テストできない理由を明記） の二択 3. §16 判断マトリクスの「Python スクリプトのロジックテスト → Chat（Linux コンテナ）」行（v1.11 で新設）を必ず参照 4. FS 操作以外も同様：HTTP リクエスト・データ整形・正規表現マッチング等、外部副作用のないロジックは Chat で完全にテスト可能 5. Chat 環境で完結できないもの：macOS 固有 API（osascript / launchctl / Spotlight / Drive for desktop UI 等）は除外。これらは依然 Code か工藤さん手動 - 関連トピック： - kudo-cowork-code-handoff-protocol §16 v1.11（本Entry を起点に判断マトリクスへ「Chat スクリプトテスト」行を新設） - 「君の方で実装できそうじゃない？」「Chat 完結できないか？」系の指摘で再発するリスク - 2026-05-15 連続気付き事例：Entry #9（先延ばし禁止）/ Entry #10（MCP 機能仮定禁止）と同じ命名統一プロジェクトで連続発覚した3つ目の構造的盲点。「自分の手元の能力を過小評価する」というメタ的失敗。今後は「これは Chat で完結できるか？」を常に最初に問う

Entry #12：「改名」の2層構造（案件ノード改名 vs ログ表記統一）の混同

  • 日付：2026-05-15（命名統一プロジェクト Cowork v7 完了後）
  • 領域：WorkFlowy 改名作業 / 命名統一プロトコル / Cowork 報告解釈
  • 誤断言内容：Cowork v2 完了報告で「SNKRDUNK統合 9件」「問読プロジェクト統合 8件」等を案件ノードの統合と解釈していたが、Cowork v7 の Task 2 ブロッカー報告で実態が判明：9件すべて「📂進行中プロジェクト」スナップショット内＝日次ログ系のセクション見出しであり、独立した案件ノード（正準ノード）は存在しなかった
  • 真相：WorkFlowy 改名作業には意味の異なる 2 つのレイヤーが存在：
  • レイヤー A：案件管理ノード改名（#project タグ付き・人間管理下のノード）→ 名前統一が「案件の同一性確保」につながる
  • レイヤー B：ログ内表記統一（日次ログのセクション見出し・自動生成・スナップショット）→ 名前統一は表面的（次回 automation で復活する可能性あり）

v2 報告の「SNKRDUNK統合9件」は実はレイヤー B だった。これは真の案件統合ではない - 一次ソース：Cowork v7 Task 2 ブロッカー報告（2026-05-15）。「SNKRDUNK_スニーカーダンク #project は9件すべてが『📂進行中プロジェクト』スナップショット内」 - 永続化ルール： 1. Cowork 改名報告を受領したとき、件数だけでなくノード種別（レイヤー A / B）を必ず確認 2. レイヤー B（ログ系）の改名は表面的処理。次回 automation で復活する可能性を念頭に置く 3. 「○○統合 N件」と報告されたら、「親はどこにあるのか？」を必ず追問 4. kudo-naming-unification-protocol v2.3 §3-2-D 適用範囲（#project タグ付きノードのみ）の根拠として本 Entry を引用 - 関連トピック： - kudo-naming-unification-protocol v2.3 §3-2-D 適用範囲・§4-3 経路の役割の違い - 「件数」だけでなく「ノードの意味的階層」を確認する基本姿勢

Entry #13：永続化された誤情報の修正（WorkFlowy「過去生成ログ」ID）

  • 日付：2026-05-15（命名統一プロジェクト Cowork v7 報告で発覚）
  • 領域：userMemory / SKILL / 永続化ルールの正確性
  • 誤断言内容：私（Chat Claude）の userMemory・SKILL内に「過去生成ログ（過去やりとりはすべてここにあるのでclaude読んでね！）」ノード ID を 8cfc1d50-7222-e2ce-79d0-8fc9faf6a6c2 と複数箇所で記述していた。これに基づいて Cowork v7 Task 8 完了サマリーノードの親ID指定を行った
  • 真相：Cowork v7 報告で訂正：
  • 8cfc1d50 = 「[1日1新およびToDo]」ノード
  • 正しい「過去生成ログ」のID = 54f53941
  • Cowork は意図（過去生成ログ配下に作る）に従って正しい ID で作成してくれた
  • 一次ソース：Cowork v7 完了報告（2026-05-15）。「指示書の訂正点：Task 8 の親ID誤り — 指示書は 8cfc1d50 を『過去生成ログ』としていましたが、実際は 8cfc1d50=「[1日1新およびToDo]」。「過去生成ログ」の正しいIDは 54f53941」
  • 永続化ルール：
  • memory_user_edits に「WorkFlowy主要ノードID（正・2026-05-15確定）」エントリを追加済（2026-05-15）
  • kudo-workflowy-double-save §1 SSOT で「過去生成ログ」を 8cfc1d50 と記述している箇所があれば修正必要
  • 同種の永続化された誤情報を発見したら、memory に追記＋関連SKILLを更新の2段階で対処
  • 「永続化された誤情報は、ユーザーが偶発的に検知してくれない限り、永続的に再生産される」という構造的リスクを認識
  • 関連トピック：
  • kudo-workflowy-double-save §1 SSOT の参照ID修正
  • userMemory の generated_summary 部分は手動編集不可、memory_user_edits での補正が必要

Entry #14：Chat 出力ファイルのデフォルト保存先＝Desktop（~/Downloads/ではない）

  • 日付：2026-05-15（Code v3 HANDOFF 逸脱報告で発覚）
  • 領域：HANDOFF プロトコル / Chat 出力ファイルの取り扱い前提
  • 誤断言内容：HANDOFF-validate-naming-consistency-setup-v2.md および HANDOFF-code-finalize-v3.md で ~/Downloads/naming-master-list-v0.5.xlsx をデフォルト参照パスとして指定。実際には工藤さんの運用は ~/Desktop/ 保存だった
  • 真相：Code v3 完了報告：「v0.5 ファイル不在：~/Downloads/naming-master-list-v0.5.xlsx が存在せず、~/Desktop/naming-master-list-v0.4.xlsx のみ存在」
  • 工藤さんは Chat から DL したファイルを Desktop に保存する運用
  • 私は一般的な「Downloads」フォルダを勝手に仮定していた
  • 加えて、私が「v0.5」を出力したのに対し工藤さんが保存・命名したのは「v0.4」のままだった
  • 一次ソース：Code v3 HANDOFF 逸脱報告（2026-05-15）。「~/Desktop/naming-master-list-v0.4.xlsx のみ存在」
  • 永続化ルール：
  • Chat 出力ファイルのデフォルト保存先 = ~/Desktop/ を前提として HANDOFF を書く
  • または、HANDOFF で両方探索するロジックを書く（~/Downloads/ と ~/Desktop/ の両方を確認）
  • latest symlink パターンを推奨：工藤さんがどこに保存しても latest シンボリックリンクを張り替える運用にする
  • Code に渡す HANDOFF で「ファイルがなければ作業を停止して報告」とする原則を維持（Code v3 は v0.5 不在を発見して v0.4 で代用＋報告した。この挙動が正解）
  • 関連トピック：
  • kudo-cowork-code-handoff-protocol §16 v1.12 で「reasonable assumption での補正＋報告」原則を明文化
  • latest symlink パターンの横展開価値（kudo-brand-tokens.json 等にも応用可）

Entry #15：memory_user_edits の500字制限を作業前に把握せず立ち往生

  • 日付：2026-05-15
  • 領域：memory_user_edits 運用 / 作業前の制約確認
  • 誤断言内容：control 引数の文字数を見積もらずに add を実行し、500字超過エラーで同ターン内の作業が中断。工藤さんが同じメッセージを再送する手間が発生した
  • 真相：memory_user_edits の control フィールドは最大500字（日本語マルチバイト計算）。事前に文字数チェックをすれば回避できた
  • 一次ソース：2026-05-15 add 実行時の "String should have at most 500 characters" エラー
  • 永続化ルール：
  • memory add 前に必ず文字数を数える（len(control_string) または wc -m <<< "$control"）
  • 450字を超えそうなら圧縮版を準備してから add（バッファを確保）
  • 長い内容は memory に全部書かず、SKILL.md を一次ソースにして memory は要約＋参照に留める（SSOT 階層化原則）
  • 関連トピック：
  • Entry #9 と同じ「作業前の確認不足」系
  • kudo-persist-settings §設定ファイル所在マップ SSOT（v3.8 で参照腐敗フラグ追加）と整合：「長文の本体は SKILL.md、要約は memory」の役割分担

§5 利用プロトコル（断言前のセルフチェック）

工藤さんに何かを断言する前に、以下のチェックリストを通す：

  1. 領域マッチ：起動トリガー §2 のキーワードが文脈に含まれるか？YESなら次へ
  2. 過去事案チェック：§4 のEntryにマッチする領域か？YESなら、そのEntryの「永続化ルール」を読む
  3. 一次ソース確認：永続化ルールが「公式ソースで確認」を要求していれば、web_search で公式ドキュメントを引いてから断言する
  4. ★マーカー判定：確認できない場合は、断言ではなく★仮説マーカーを冠して提示する

§6 能力境界マップ（GUI操作の代行可能性）

工藤さんが「Codeで／Coworkで代行できない？」と聞いたとき、以下のマトリクスを参照：

操作 claude.ai chat Claude Code Cowork 半自動化
ターミナルコマンド実行 ✗ ✓ Mac直 ✗ ✓
ファイル作成・編集 bash_toolはLinux container内 ✓ Mac直 ✓ ファイル系のみ ✓
GUIボタンクリック ✗ ✗ ✗ △ AppleScript（リスク中）
GUIドラッグ&ドロップ ✗ ✗ ✗ △ AppleScript（リスク中）
System Settings操作 ✗ ✗ ✗ △ AppleScript（リスク中・脆弱）
MCP経由の操作 ✓ ✗ ✓ -
present_filesでファイル渡し ✓ - - -
heredoc直貼りスクリプト ✓ ✓ ✓ -

→ GUI操作の完全代行は原則不可。半自動化（System Settingsの特定ペインをopenコマンドで開く + Finderで対象フォルダを開く + 工藤さんがドラッグ）が最大圧縮。

ワンライナー半自動化テンプレ： 

open "x-apple.systempreferences:com.apple.<paneID>" && sleep 2 && open <target_folders>

§7 横展開・運用

  • 本スキルは kudo-persist-settings の補完実装子として位置付ける
  • 新規誤判定が判明した瞬間に Entry 追加（即時永続化原則）
  • 月初の月次棚卸し会議で過去Entry をレビュー、不要な Entry は archive する
  • Entry数が30を超えたら領域別に分割スキルを検討（macOS系 / Web系 / Cloud系など）
  • Entry追加時のフォーマット：このSKILL.md §4 のテンプレート踏襲

§8 関連スキル

  • kudo-persist-settings：スキル運用ガバナンス（親）
  • kudo-mac-health-check：Mac診断SOP（領域別実装子・本スキルと連携）
  • kudo-cowork-code-handoff-protocol：Cowork↔Code連携プロトコル（Entry #6 関連、追記要）
  • 個人設定 項目3「事実／仮説／意見の区別」最重要原則
  • 個人設定 項目8「忖度不要・本質を突く」

§9 メタ原則

本スキルは 「Claudeを使う側の工藤さん」が私（Claude）の誤判定リスクを管理する装置 であり、同時に 「Claude自身が自分の誤判定パターンを学習する装置」 でもある。両面性が本スキルの本質。

工藤さんの本来の業務時間を「私の誤判定の検証」に費やすコストを最小化することが、本スキルの究極目的である。