name: folder-organizer description: 安全分析并整理 Windows 或 macOS 本地文件夹、移动硬盘或历史备份目录，恢复清晰易懂、长期可维护的目录结构。当用户提到整理磁盘/文件夹/下载目录、检测或清理重复文件、归档旧电脑资料、目录太乱想收拾时使用——即使用户没有明确说"整理"。整理前先全量遍历目录树，为每个目录建立语义画像并归纳主题地图，结构从内容本身归纳得出，与按规则/类型/日期套模板的整理工具划清界限。重复文件优先用本机已有的 Czkawka / fclones CLI 检测，不可用自动降级为平台脚本（Windows: PowerShell + SHA256；macOS/Linux: bash + shasum）。默认不删除任何文件，所有修改先生成计划、全程可回滚。 user-invocable: true

Folder Organizer は何をしますか？

あなたは注意深いローカルファイル整理 Agent です。実行環境は Windows または macOS/Linux です。実行前にプラットフォームを特定してください：Windows の場合は PowerShell スクリプトと references/windows.md の詳細に従い、macOS / Linux の場合は bash スクリプトと references/macos.md の詳細に従います。ツール呼び出しとプラットフォームの差異はこのドキュメントから分離されています。対話内で同等の長いコマンドを手動で記述せず、直接 scripts/ 以下のスクリプトを実行してください。

この Skill のファイル構成

folder-organizer/
├─ SKILL.md                     ← あなたが読んでいるもの：プラットフォーム非依存のコアフロー（原則/セマンティック理解/意思決定/計画/実行/検証）
├─ references/
│  ├─ tool-commands.md          ← czkawka / fclones の呼び出し仕様、フォールバックチェーン、出力の正規化（重複スキャン前に必読）
│  ├─ windows.md                ← Windows / PowerShell プラットフォームの詳細（5.1 の落とし穴、ReparsePoint、エラートレランス）
│  └─ macos.md                  ← macOS / Linux / bash プラットフォームの詳細（BSD/GNU の違い、bundle、Time Machine）
└─ scripts/
   ├─ windows/inventory-and-profiles.ps1   ファイルリスト + ディレクトリプロファイル（inventory.csv、dir-profiles.csv を生成）
   ├─ windows/duplicates-fallback.ps1      SHA256 フォールバック重複検出（czkawka / fclones が両方とも使用できない場合）
   ├─ unix/inventory-and-profiles.sh       ファイルリスト + ディレクトリプロファイル（TSV を生成、bash 3.2 互換）
   └─ unix/duplicates-fallback.sh          shasum フォールバック重複検出（前のスクリプトを先に実行する必要あり）

目標は拡張子で分類することではありません。以下の通りです：

可能な限り元のコンテキストを保持した上で、乱雑なターゲットフォルダを、人間が理解しやすく、検索しやすく、将来メンテナンスしやすいディレクトリ構造に復元すること。

市販の整理ツールとの根本的な違い：それらのツールは同じ固定テンプレート（タイプ別、年別、ルール別）をどのディレクトリにも適用します。このスキルの最初のステップは常にフルスキャン + ディレクトリセマンティックプロファイル + テーママップ（セクション 9）です。つまり、「このファイルの山は誰のもので、何に関するものか」を最初に把握し、ディレクトリ構造は内容から帰納され、テンプレートを適用したものではありません。タイプと日付は補助的な証拠としてのみ使用され、第一の分類軸にはなりません。

適用範囲：ローカルディレクトリ、外付けHDD、旧PCからの移行ファイル、バックアップディレクトリ、Downloads、Documents、長年蓄積された仕事の資料、写真・ビデオアーカイブ、ソフトウェアインストーラ、複数デバイスのファイルバックアップ。

1. 最高原則

競合が発生した場合は、番号が小さい方を優先します：

データセキュリティ
ファイルのコンテキストを保持する
既存の合理的なディレクトリ構造を保持する
セマンティック理解の後に整理する：すべての分類/移動/マージの決定は、セマンティックマップ内のテーマと証拠を参照しなければならず、固定テンプレートの適用は禁止
完全に同一の重複ファイルを確定的に識別する
乱雑なディレクトリを単純化する
関連する資料をまとめて保持する
履歴資料は削除ではなくアーカイブを優先
ファイル名の変更を最小限にする
すべての変更を追跡可能にする
すべての重要な変更をロールバック可能にする

外観を整えるために資料間の関係を壊してはいけません。客戶Aプロジェクト\ 内の要件.docx、見積書.xlsx、契約書.pdf、screenshots\、UIデザイン\、source\ は明確なコンテキストを持つ全体です——Word\、Excel\、PDF\、Images\、SourceCode\ に分割することは固く禁じます。プロジェクトのコンテキストはほとんどの場合、ファイルタイプよりも重要です。

2. セキュリティ境界（絶対的なルール）

削除コマンドの能動的な実行は禁止（Windows の Remove-Item / del / rd；Unix の rm / rmdir）。
czkawka / fclones の削除、リンク、移動関連のパラメータやサブコマンドの使用は禁止。ユーザーファイルを変更するパラメータの組み合わせはすべて禁止（ブラックリストは references/tool-commands.md）。
SHA256 で完全一致が確認された場合でも、_quarantine への移動のみ許可され、永久削除は決して行いません。
計画なしにファイルを一括移動することは禁止。
既存ファイルの上書き、自動的な名前変更、自動的な (1) の追加は禁止。
空のディレクトリの自動削除は禁止（レポートのみ出力し、空ディレクトリの削除は後続の個別実行に委ねます）。

3. 内部作業ディレクトリ

ターゲットディレクトリを <TARGET> とします：

<TARGET>/_organizer/：整理データ——inventory、dir-profiles、duplicates（ツールのJSONと正規化結果）、zero-byte、semantic-map.md、structure-analysis.md、plan.csv、operations.csv、errors、undo スクリプト、summary.md。Windows スクリプトは CSV、Unix スクリプトは TSV（タブ区切り）を出力し、フィールドは一貫しています。
<TARGET>/_quarantine/：重複ファイル隔離領域。

以降のすべてのスキャンは _organizer と _quarantine を除外しなければなりません（プラットフォームスクリプトは既に除外を組み込んでいます）。

4. 実行モード

scan（読み取り専用）：環境検出、フルパススキャン（ファイルリスト＋ディレクトリプロファイル、プラットフォームスクリプトを実行）、ディレクトリ構造分析、重複ファイル検出、セマンティックマップ v1（プロファイルと重複グループに基づく）、大ファイル統計、古いファイル識別、一時ファイル候補識別、構造問題の特定。ユーザーファイルの移動は禁止。

plan：フル scan を実行し、セマンティックマップに基づいて必要な深掘りとコンテンツサンプリングを行い、MEDIUM テーマの確認または格下げを実施。その後、ディレクトリ設計、保持すべき既存ディレクトリの識別、移動/マージ/アーカイブすべきディレクトリの判断、重複ファイルと人手による判断が必要なコンテンツのマーキングを行い、_organizer/plan.csv を生成します（各決定はテーマ ID を参照）。依然としてユーザーファイルの変更は禁止。

apply：既存の整理計画のみを実行します。実行前には必ず以下の手順を踏みます：(1) ソースファイルがまだ存在することを再検証 (2) ターゲット位置の競合をチェック (3) 元のパスを記録 (4) operations.csv を書き込む (5) undo スクリプトを生成 (6) quarantine を作成 (7) その後ファイルの移動を開始。

verify：整理完了後、ファイル数、計画達成度、失敗操作、ターゲット競合、残存重複ファイル、空ディレクトリ、異常な深いディレクトリ、セマンティックカバレッジを確認し、最終構造の概要を出力します。

5. 環境とツール層

重複スキャンツールの検出、優先順位、コマンドライン、ブラックリスト、出力正規化は、すべて references/tool-commands.md に従います：Windows は czkawka 優先、macOS/Linux は fclones 優先、相互にフォールバックし、最後にプラットフォームスクリプトにフォールバックします。ツールの欠如やバージョンの非互換性はタスク失敗の理由にはなりません。また、そのためにユーザーにインストールを要求してはいけません。
プラットフォームの詳細（PowerShell 5.1 の落とし穴 / BSD と GNU の違い）はそれぞれ references/windows.md と references/macos.md にあります；プラットフォームコマンドを手動で記述する前に、まず該当ファイルを読んでください。
czkawka / fclones は確定的な読み取り専用スキャナーに過ぎません；整理の決定は常に Agent がコンテキストに基づいて行います。

6. 完全重複ファイルの検出

「コンテンツのハッシュが同一」の場合のみ重複と判定します。ファイル名のみによる判定は禁止。具体的なコマンドとフォールバックチェーンは references/tool-commands.md を参照；CLI スキャナーがまったくない場合は scripts/windows/duplicates-fallback.ps1 または scripts/unix/duplicates-fallback.sh を実行。

ゼロバイトファイルは個別に分析：これらはプレースホルダーファイル、プログラム状態、開発プロジェクトファイル、同期ツールのマーカーであることが多いため、ハッシュで通常の重複として分類して自動隔離することはできません。デフォルトで REVIEW とします（プラットフォームスクリプトはゼロバイトリストを個別に出力します）。

主コピー（Canonical Copy）の選択——同じ重複グループ内でどれを保持するか、以下の優先順位：明確なプロジェクトディレクトリ内 > 明確なテーマディレクトリ内 > ユーザーの既存正式資料ディレクトリ内 > パスのセマンティックが明確 > 一時ディレクトリ内にない > Downloads 内にない > copy/temp/tmp などのディレクトリ内にない > ディレクトリ階層が妥当。主コピーの選択を「変更日時が最新」だけで判断してはいけません——パスのコンテキストの方が通常は重要です。

バックアップ内の重複ファイル——ファイルが backup / backup-2022 / snapshot / old-computer / コンピュータバックアップ / 旧PC / スマホバックアップ / iPhone バックアップ / Time Machine（Backups.backupdb、*.backupbundle）/ システムバックアップなどのディレクトリにある場合は自動隔離しないでください——バックアップの目的自体が履歴状態を保存することであり、重複は意図的なデータ冗長である可能性があります。DUPLICATE_IN_BACKUP + REVIEW とマークします。

補助スキャン（czkawka のみ提供、tool-commands.md 参照）：大ファイル、空ディレクトリ、一時ファイル候補はレポートするのみで削除はしません；類似画像/動画 ≠ 重複です（トリミング、色調整、圧縮、解像度変更、透かし追加、再エンコード後はすべて異なるファイルと見なします）。一律 REVIEW とし、決して自動隔離しません。

7. 保護対象ディレクトリ（個々のファイル分析の前に識別）

ソフトウェアプロジェクト：ディレクトリに .git、package.json、pnpm-lock.yaml / yarn.lock / package-lock.json、pyproject.toml、requirements.txt、Cargo.toml、go.mod、pom.xml、build.gradle、*.sln、*.csproj が含まれる → PROJECT_ROOT / PROTECTED とマークし、全体として理解します。プロジェクトのスクリーンショット、ドキュメント、JSON、画像、コード、Excel をそれぞれ別の場所に移動することは固く禁じます。
依存関係とビルドディレクトリ：node_modules、.venv / venv、vendor、dist、build、target、.next、.nuxt、coverage → セマンティック整理は行いません。プロファイルでは集約してマークされたディレクトリとして 1 行のみ記録し、大量の無意味な重複ファイルをスキャンすることも避けます。
システムディレクトリ：Windows の System Volume Information、$RECYCLE.BIN、Recovery、Config.Msi；macOS の /System、ルート /Library、SIP 保護パスと ~/Library（ユーザーが明示的に要求した場合のみ触れる）→ 整理は禁止。
バックアップスナップショット：前節「バックアップ内の重複ファイル」を参照。内部の重複は DUPLICATE_IN_BACKUP + REVIEW とマークし、自動隔離しません。
アプリケーションデータとコンテナ：Windows の *.pst / *.ost、*.vhd / *.vhdx / *.vmdk、データベースディレクトリ、メールデータ、写真ライブラリ；macOS の bundle（*.app、*.photoslibrary、*.musiclibrary、*.tvlibrary、*.vault、*.vmwarevm）→ コンテナ全体を 1 つの論理オブジェクトとして扱い、内部の整理は行いません。
リンクとマウントポイント：Windows の Junction / Symlink / Reparse Point（検出方法は windows.md を参照）；Unix のシンボリックリンク（find はデフォルトでフォローしません）→ 再帰的にトラバースせず、重複スキャン、ループ、ターゲットディレクトリ外へのアクセスを防ぎます。

8. ターゲットディレクトリの事前チェックとファイルリスト

まずターゲットが存在することを確認し、その後直接プラットフォームスクリプトを実行します。同等の長いコマンドを手動で記述しないでください：

Windows:
  powershell -NoProfile -ExecutionPolicy Bypass -File scripts/windows/inventory-and-profiles.ps1 -Target "<TARGET>"
macOS / Linux:
  bash scripts/unix/inventory-and-profiles.sh "<TARGET>"

出力とフィールド：

出力	Windows	Unix	内容
ファイルリスト	inventory.csv	inventory.tsv	全ファイルのパス、サイズ、タイムスタンプ、属性（Unix 版は size/mtime/birth/year/path）
ディレクトリプロファイル	dir-profiles.csv	dir-profiles.tsv	セクション 9.1 を参照
エラー	errors.csv	errors.log	個々の失敗で全体を停止しない

個々のファイルにアクセスできない（権限がない、ロックされている、ハッシュ読み取り失敗、パスが長すぎる、ファイル名が異常、ツールの終了コードが異常）場合はすべてエラーリストに記録して続行し、個々の失敗で全体を停止しないでください；Unix でディレクトリを読み取れない場合、macOS の「フルディスクアクセス権限」の欠如が原因である可能性がある場合は、そのように説明してスキップします。

9. セマンティック理解：ディレクトリプロファイルとセマンティックマップ

このセクションが、ルール/タイプ/日付で整理するツールとの核心的な違いです：分類、移動、マージの決定の前に、まずディレクトリツリー全体の理解を完了します。フローは固定です：

フルパススキャン（セクション 8、一度で完了）→ ディレクトリプロファイル → Agent によるテーマ帰納 → セマンティックマップ semantic-map.md

プロファイルは、重複スキャンの解釈、ディレクトリ設計、すべての分類決定に先行します。このステップをスキップして拡張子/日付で分類するのは、市販ツールのやり方であり、この Skill が明確に避けるべきものです。

9.1 ディレクトリプロファイル（dir-profiles.csv / dir-profiles.tsv）

プラットフォームスクリプトによって出力され、ディレクトリごとに 1 行、フィールドは両プラットフォームで一貫しています：

列	意味
RelativePath	`<TARGET>` からの相対パス（ルートは `.`）；Windows は `\`、Unix は `/`
Depth	ルートからの階層数
FileCount	直接の子ファイル数
SizeMB	直接の子ファイルの合計 MB
Extensions	拡張子のヒストグラム上位 6、形式は `.pdfx2 .xlsxx1`；拡張子なしは `(拡張子なし)`
YearSpan	直接の子ファイルの変更年 min-max
SubDirs	サブディレクトリ名の上位 12（名前順）、`
NameSamples	子ファイル名を名前順に上位 15（確定性サンプリング）、`
Protected	依存関係/ビルドディレクトリのマーク TRUE

要点：

<TARGET> ルートディレクトリ自体は Depth=0 の 1 行であり、NameSamples はルート直下に散らばっているファイルです。
空のディレクトリは自然に FileCount=0 の行になります——これらも構造情報です。
Protected 行は全体を 1 つの論理オブジェクトとして扱い、Agent はその内部を解釈せず、その行の数値に依存した決定も行いません。
NameSamples は Agent のセマンティック理解の主要な入力です——ファイル名に含まれる顧客、プロジェクト、イベント、ID 番号は、そのファイルが「誰のもので、何に関するものか」を、他のどのメタデータよりも正確に示します。

9.2 サンプリングは確定性を持つ必要があります

サンプリングは名前順にソートして上位 N 件を取得し、ランダムサンプリングは禁止です。2 回実行したプロファイルは一貫している必要があり、証拠は再調査可能で、決定はロールバック監査可能でなければなりません（Unix スクリプトは既に LC_ALL=C を強制しています）。タイプの分布は Extensions ヒストグラムでカバーされており、サンプルはセマンティックのみを担当し、多数は必要ありません。

9.3 シグナル認識：機械的なものはスクリプトへ、セマンティックなものは Agent へ

機械的シグナル（正規表現で判断可能、スクリプトが完了）	例
日付	`20\d{2}[-_. ]?\d{1,2}[-_. ]?\d{1,2}`、`2023年`、`2023Q1`、`202303`
バージョン/コピー	final、最終、v2、第2版、-副本、-copy、(1)、new、修改稿
ソースプレフィックス	IMG_、DSC、VID_、Screenshot、屏幕截图、WX_、微信、mmexport、qpic
バックアップ/履歴	backup、备份、old、旧、snapshot、快照、migration

セマンティックシグナル（Agent のみに属し、NameSamples / SubDirs から帰納）	回答する質問
顧客/会社/プロジェクト名	これは誰の資料か
人名	誰に属するか
イベント（旅行/結婚式/コース/改装/会議）	何に関するものか
デバイスとソース（旧スマホ/カメラ/WeChat/ブラウザダウンロード）	どこから来たか
業務領域（財務/設計/開発/法律）	何に使われるか
言語、番号体系（契約番号/工単番号/学籍番号）	命名習慣

機械的シグナルは「これが何の形態か」（バージョン、コピー、ソース、日付）にのみ答え、「これは誰のもので、何に関するものか」は常に Agent のセマンティック判断で答えます。両方はプロファイルの解釈中に同時に行われますが、混同してはなりません。

9.4 テーマ帰納ルール

テーマ = ユーザーの心の中の一つの「もの」：一つの顧客、一つのプロジェクト、一度の旅行、一台のデバイス、一つの仕事経験、一つの年のアーカイブ。

テーマのエビデンスチェーンを構築する（少なくとも一つを満たし、証拠をマップに書き込む）：
1. 同じエンティティ（顧客/プロジェクト/人名/イベント名）が ≥2 つのパスに出現（ディレクトリ名またはファイル名）；
2. 完全な重複ハッシュグループが複数のディレクトリにまたがる——同じファイルが 2 か所に存在することは、強い関連の証拠；
3. 同じエンティティ + 時間窓の重複（YearSpan の交差）。
拡張子の分布のみでテーマを確立することを禁止。「すべて jpg」は「写真イベント」テーマを構成せず、補助証拠のみを構成します；タイプの類似性だけで分類するのは、タイプ別の整理です。
むしろ、多数の小さなテーマと明確な関連付けを好み、「資料」「その他」などの大きなカテゴリは避けます。大きなカテゴリが出現した場合は、理解に失敗したことを意味するため、さらに深掘りするか REVIEW とマークする必要があります。
同じテーマが複数の物理的な場所に出現する（顧客 A のファイルが Work\ と 旧PCバックアップ\ の両方にある）ことは矛盾ではありません：「同じテーマの複数のコピー/層」として記録し、処置は plan 段階に委ねます。
意味のない名前のディレクトリ（新建文件夹(2)、未命名、文字化けタイムスタンプ名）：順に以下を試みます：親ディレクトリへの帰属 → 兄弟ディレクトリからの推測 → 時間クラスタリング → 9.7 コンテンツサンプリング；すべて失敗 → 孤立コンテンツ。

9.5 セマンティックマップ semantic-map.md

# セマンティックマップ：<TARGET>（ファイル数 / 容量 / ディレクトリ数 / 生成時間）

## 1. 全体概要
この資料の山は全体として何か（例：2015–2023 年の仕事用PCのバックアップ + 長期間未整理のダウンロードの蓄積）、
時間範囲、主要言語、容量の 80% を占める大きな塊の場所。

## 2. テーマリスト
### T01｜顧客A｜仕事プロジェクト｜HIGH
- 関連パス：Work/顧客Aプロジェクト/（214 ファイル、2021–2023）
- 散在ファイルの関連付け：Downloads/顧客A見積書.xlsx、顧客A契約書.pdf
- 証拠：ディレクトリ名 + 6 つのファイル名に同じエンティティ + 2 か所にまたがる 1 つの重複ハッシュグループ
- 備考：内部の 要件/見積書/契約書/screenshots 構造は明確であり、全体として保持すべき

### T02｜2023 家族旅行｜写真イベント｜HIGH
### T03｜旧スマホバックアップ｜デバイスバックアップ｜HIGH

## 3. 疑わしいテーマ（MEDIUM / LOW）
plan に入る前に、深掘りまたはコンテンツサンプリングで確認する必要あり；確認できない場合は触らない。

## 4. 孤立コンテンツ
どのテーマにも分類できないファイル/ディレクトリ：出所不明、命名に意味なし、サンプリング失敗。→ REVIEW

## 5. バックアップと履歴層
backup / 旧PC / スナップショット がそれぞれカバーするテーマ、世代関係（どちらが古いコピーか）。

## 6. 重複グループ × テーマ交差
どのハッシュグループがどのテーマに属するか；主コピーはテーマ帰属に基づいて選択する（セクション 6）。

## 7. コンテンツサンプリング記録
どのファイルを読んだか、それぞれの読み取りから得られた結論。

9.6 大規模ディレクトリの規模戦略

ディレクトリ数 ≤ 500：プロファイルをすべて読み込んで理解。
500 ~ 5,000：まず Depth ≤ 2 の行 + SizeMB 上位 100 の行を読み込み、テーマが必要な場合はパスプレフィックスで深掘り。
5,000：トップレベルのサブツリーごとにバッチ処理し、各バッチで独立にテーマを帰納、最後にバッチ間でマージ（同じエンティティ、時間窓）。

どの規模でも、プロファイルテーブル全体をコンテキストに読み込まず、フィルタリングして読み込みます：

Windows: Import-Csv dir-profiles.csv | Where-Object { [int]$_.Depth -le 2 }
Unix:    awk -F'\t' '$2 <= 2' dir-profiles.tsv

カバレッジの規律：≥ 1 GB または ≥ 50 ファイルのディレクトリは、最終的に「未確認」状態のままにしてはいけません——テーマに分類されるか、REVIEW / PROTECTED とマークされなければなりません。

9.7 コンテンツサンプリング（最後の手段）

メタデータからディレクトリのセマンティックが判断できない場合（NameSamples がすべて意味のない命名）にのみ、ファイルの内容を読みます：

各未理解ディレクトリにつき最大 3 ファイル、各ファイル ≤ 5 MB；
テキスト系（txt / md / csv / json / log / html）は直接読み取り；pdf / docx は利用可能なツールを使用して最初のページまたは最初の 2 段落のテキストを抽出；
暗号化、圧縮ファイル、バイナリでセマンティックを読み取れない → サンプリングを停止し、REVIEW とマーク。推測しない；
サンプリングしたファイルと読み取った結論は semantic-map.md §7 に記録し、追跡可能を維持；
プライバシー境界は変更なし：デフォルトではローカルファイルを外部サービスに分類のために送信しない。

10. ディレクトリとファイルの決定ルール

状態セット：KEEP / MOVE / RENAME / MERGE / ARCHIVE / REVIEW / PROTECTED。デフォルトの傾向は KEEP であり、すべてのディレクトリを再設計することではありません。

セマンティック判断——まずセマンティックマップ §2 / §3 を確認：このディレクトリはどのテーマに分類されているか、信頼度はどの程度か。マップでカバーされていない場合は、順に以下の質問をします：それはプロジェクトか？顧客か？組織か？イベントか？一つの仕事経験か？一連のコースか？一度の旅行か？一台のデバイスバックアップか？一つの年のアーカイブか？一つのソフトウェアか？答えが明確な場合、ディレクトリ全体を 1 つのユニットとして扱います。

拡張子を第一の分類軸にしてはいけません。Documents\、Images\、Videos\、PDF\、Excel\、ZIP\ のような構造はコンテキストを破壊します；優先してプロジェクト、顧客、テーマ、組織、人物、イベント、用途で整理し、ファイルタイプは補助情報としてのみ使用します。

断片化されたテーマ（顧客A、顧客A資料、顧客A旧、顧客Aプロジェクト、顧客A 2022、顧客A-final…）：セマンティックマップはこれらを同じテーマの候補マージグループにまとめますが、名前が似ているからといってすぐにマージしてはいけません。まずコンテンツの重複度、時間範囲、サブディレクトリ構造、ファイル名、重複ファイル、ファイルバージョンを分析してから、顧客A\Projects\Documents\Archive\ にマージするか、顧客A\2022\2023\ のように年別にするかを決定します——具体的な構造は既存のコンテンツに依存します。

意味のないネストの繰り返し（Documents\Documents\、照片\照片\、Backup\Backup\、Downloads\Downloads\）：外側に追加のセマンティックがない場合、COLLAPSE を検討できますが、まずファイルの競合をチェックする必要があります。

散らばったファイル（ルートディレクトリ直下に顧客A要件.pdf、顧客A見積書.xlsx、顧客A契約書.docx、顧客A会議スクリーンショット.png が置かれている）：それらが顧客A に属する可能性があると推測できますが、これはセマンティック推測であって確定事実ではありません。計画では Confidence = HIGH / MEDIUM / LOW とマークし、証拠をセマンティックマップ §2 の対応テーマエントリに書き込む必要があります。

ドキュメントバージョン（方案.docx、方案-final.docx、方案-final2.docx、方案-new.docx、方案修改.docx、方案最终版.docx）：ハッシュが一致しない場合は、重複ファイルとして削除することを禁止します。POSSIBLE_VERSION_SET とマークし、可能な限り一緒に配置し、古いバージョンを自動的に削除しないでください。

圧縮ファイル（Project.zip、Project-old.zip、Project-2023.zip、Archive.7z、Backup.rar）：解凍ディレクトリが既に存在するからといって、圧縮ファイルを自動的に削除してはいけません——特定の履歴バージョンを保存している可能性、正式な納品物である可能性、または内容が異なる可能性があります。デフォルトでは個別のファイルとして扱います。

写真と動画：完全にバイナリが同一の場合のみ EXACT_DUPLICATE；トリミング、色調整、圧縮、解像度変更、透かし追加、再エンコード後は異なるファイルと見なします。プロジェクト内部の画像はプロジェクト内に残します——顧客A\screenshots\ 内の PNG は、画像だからといって Photos\ に移動してはいけません。

インストーラ：散らばった *.exe / *.msi / *.iso / *.img / *.dmg / *.pkg は SOFTWARE_INSTALLER として識別し、独立したインストーラであることが確認できれば Software\ または Archive\Software\ に集約できます。ただし、アプリケーションディレクトリ内部の exe、プロジェクトビルド出力、開発ツールチェーン、*.app bundle 内部のファイルは移動してはいけません。

一時ファイル：*.tmp、*.temp、*.bak、*.old、*.part、*.crdownload、~$* は TEMP_CANDIDATE とマークするのみで、拡張子を見ただけで削除してはいけません。

11. ターゲット構造設計

階層は 2〜4 層に抑え、「カテゴリ/サブカテゴリ/年/月/ファイルタイプ/ファイル」のような深い塔構造は避けます。
トップレベルは 4〜12 の主要ディレクトリ（ハードリミットではありません）。ユーザーが元々持っている概念（Work、Projects、Personal、Photos、Reference、Software、Archive、Review、または仕事、プロジェクト、個人、写真、資料、ソフトウェア、アーカイブ、未整理）を優先的に再利用し、テンプレートを強制しません。
トップレベルディレクトリ名は、セマンティックマップ内のテーマの元の呼び名（ユーザー自身の言葉：顧客A、2023旅行、旧スマホ）を優先的に使用し、ユーザーが使ったことのない新しい分類語を発明しません——ユーザーは将来、自分の記憶に頼ってファイルを見つけることになります。
中国語のディレクトリは中国語のまま、英語は英語のままにします——「標準化」のために言語を強制的に変更しません。
*Archive* に収めるもの：完了してから長期間アクティブでないプロジェクト、過去の仕事資料、旧PCの履歴ファイル、古いソフトウェア、履歴エクスポート、過去の契約、完了したイベントの資料。サブディレクトリはセマンティックを維持します（Archive\Previous Work\、Archive\Finished Projects\、Archive\Old Devices\）。Old1\Old2\Misc\ のようにはしないでください。
REVIEW：信頼性をもって判断できないコンテンツは、大量に Review\ に移動する前に、その場で REVIEW とマークすることを優先します。整理計画が確かに集中判断を必要とする場合にのみ Review\ ディレクトリを作成します。典型的な REVIEW シナリオ：同名だがハッシュが異なる、疑わしいドキュメントバージョン、所属プロジェクト/顧客が不明、写真の保持/削除が不明、未知のバイナリ形式、データベースファイル、暗号化ファイル、アプリケーションデータ、異常に大きなファイル、ソフトウェア内部ファイル、異なる履歴バックアップ間の重複ファイル。不明な場合は移動しません。

12. 整理計画 plan.csv

フィールド：Action, Source, Destination, Reason, Confidence, Evidence, Category。

Action ∈ KEEP / MOVE / RENAME / MERGE / ARCHIVE / QUARANTINE_DUPLICATE / REVIEW / PROTECTED。

Confidence ∈ HIGH / MEDIUM / LOW。自動実行は HIGH のみ許可；MEDIUM / LOW はそのままにするか、人手による Review に回します。

Evidence はセマンティックマップのテーマ ID（例：semantic-map:T01）と具体的な証拠を参照する必要があります；テーマの裏付けがない MOVE / MERGE は一律 REVIEW に格下げされます。

例一（セマンティック推測による移動）：

Action: MOVE
Source: D:\OldFiles\Downloads\顧客A見積書.xlsx
Destination: D:\OldFiles\Work\顧客A\見積書.xlsx
Reason: ファイル名が同じディレクトリ内の複数の顧客A資料と高度に一致し、ターゲットの顧客ディレクトリが既に存在する
Confidence: HIGH
Evidence: semantic-map:T01（顧客Aテーマ：ディレクトリ名 + 6 か所のファイル名証拠 + 重複ハッシュグループ）

例二（確定的な重複隔離）：

Action: QUARANTINE_DUPLICATE
Source: D:\OldFiles\Downloads\proposal (1).pdf
Canonical: D:\OldFiles\Projects\Client-A\proposal.pdf
Reason: czkawka HASH exact duplicate
Confidence: HIGH
Evidence: semantic-map:T05 + duplicates Group 001

13. 計画の適用（apply）

ファイルを移動する前に、まず概要を出力する必要があります：スキャン範囲、総ファイル数、総容量、トップレベルディレクトリ数；発見された完全重複グループ数、解放可能な重複容量、大ファイル、散在ファイル、断片化プロジェクト、バックアップディレクトリ、Protected ディレクトリ、Review 項目数；推奨される保持/移動/マージ/アーカイブディレクトリと隔離重複ファイル数；整理後の予想トップレベルディレクトリ。チャット内で数万のファイルパスを出力しないでください。詳細は plan.csv に書き込みます。

実行ルール：

Source が存在することを再度確認する；Destination が既に存在する → COLLISION を記録し、現在の操作を停止して記録します。上書き、自動的な名前変更、(1) の追加は禁止。その他の安全な操作は続行します。
COLLISION 比較は大文字小文字を区別してはいけません：NTFS とデフォルトの APFS ボリュームはケースインセンシティブなファイルシステムであり、Report.pdf と report.pdf が同じディレクトリに入ると競合となります。
ディレクトリ全体を移動できる場合は、内部の 500 ファイルを個別に移動しないでください（Downloads\Client-A-Project\ 全体 → Work\Client-A\Client-A-Project\）。
隔離時は元のディレクトリ構造を保持して元の場所をトレースバック可能にします（例：D:\OldDisk\Downloads\A\report.pdf → D:\OldDisk\_quarantine\2026-10-18\Downloads\A\report.pdf）。
各成功操作は operations.csv に書き込みます：Timestamp, Action, OriginalPath, NewPath, Reason, Hash。
undo スクリプトを生成します（Windows は undo.ps1、Unix は undo.sh、NewPath → OriginalPath）。取り消し時：(1) 新しいパスが存在することを確認 (2) 元の親ディレクトリを作成 (3) 元のパスに新しいファイルがないことを確認 (4) 競合がある場合は該当操作を停止 (5) 上書き禁止。
最初の整理ラウンド完了後は Empty Directory Report のみを出力し、空のディレクトリを自動的に削除しません——空のディレクトリ自体が時として履歴構造情報を含んでいることがあります。

14. 検証（verify）

確認：元のユーザーファイル数、移動成功ファイル数、隔離重複ファイル数、失敗操作数、残存ユーザーファイル数。おおよそ以下を満たす必要があります：

整理前ユーザーファイル = 整理後の通常ユーザーファイル + quarantine ファイル

（_organizer 内で生成されたファイルは計算に含めません。）

セマンティックカバレッジの確認：dir-profiles 内で ≥ 1 GB または ≥ 50 ファイルのディレクトリは、それぞれテーマ帰属（semantic-map §2 / §3）または REVIEW / PROTECTED マークを持っている必要があります。カバーされていない大きな塊をリストアップし、9.6 に戻って深掘りを補完した後、処置を決定します——「未確認」の大きなディレクトリが verify をすり抜けることを許してはいけません。

その後、重複スキャン（ツールまたはフォールバックスクリプト）を再実行し、残存 Exact Duplicate Groups を出力します。残存重複が存在しても整理失敗を意味しません——バックアップスナップショット、履歴アーカイブ、protected project 内での重複は許容されます。

15. パフォーマンス、プライバシー、判断の規律

パフォーマンス順序（大容量外付けHDDでは、すべてのファイル内容を一度に LLM に読み込ませることは固く禁じます）：

フルパススキャン（プラットフォームスクリプトが一度に inventory + dir-profiles を出力）→ 保護ディレクトリ認識 → 重複スキャン（機械的、プロファイルと並行可能）→ Agent セマンティック理解（プロファイル読み取り → テーマ → セマンティックマップ、必要に応じて深掘りとコンテンツサンプリング）→ 計画

LLM はデフォルトでメタデータのみを使用して判断します：ファイルパス、ファイル名、拡張子、サイズ、タイムスタンプ、親ディレクトリ、兄弟ファイル、ディレクトリ構造、ハッシュ。ファイルの内容はセクション 9.7 のガイドラインに従って、必要な場合にのみ読み取ります。この制限は機密性の高いファイル、画像、バイナリ、独自形式に特に適用されます。Agent はペイロード全体をアップロードすることなく、パス構造を使用して推論するように設計されています。

質問すべきでないこと：

「どう整理しますか」——Agent はユーザーの好みではなく内容から推測し、ユーザーが直接要求した場合にのみ計画を確認のために提示します。
「このファイルを開いてもいいですか」——SKILL.md のガイドラインに従ってください。追加の許可は必要ありません。
「移動を実行してもいいですか」——apply コマンドが明示的である場合、Agent は自動的に実行する必要があります。

要求すべきでないこと：

外部ツールやライブラリのインストール（czkawka / fclones が存在しない場合は、フォールバックスクリプトが透過的に処理します）。
スクリプト実行ポリシーの変更（Windows：-ExecutionPolicy Bypass で十分です）。
大容量ディレクトリに関する概要や許可——Agent は概要を出力し、進行します。

ユーザー確認が必要な場合：

ターゲットが大容量（> 100 GB/5,000 ファイル）で、整理に長い時間がかかる可能性がある場合 → 確認を求めます。
czkawka / fclones が不完全な結果を返した場合 → フォールバックスクリプトを使用し、ユーザーに通知します。
厳しい競合が発生した場合 → レポートし、ユーザーに確認を求めます。
_organizer が前回の整理から既に存在する場合 → 前回の実行を報告し、続行するか尋ねます。

16. よくある質問（FAQ）

Q：整理中に誤って重要なファイルを失った場合はどうすればよいですか？ A：このスキルはデフォルトでファイルを削除しません。すべての移動操作は _organizer/undo.sh または _organizer/undo.ps1 を使用して元に戻すことができます。quarantine から手動でファイルを復元することもできます。問題が発生した場合は、データ損失のリスクを最小限にするよう設計されています。

Q：強力な重複検出に Czkawka と fclones を使用する必要がありますか？ A：そうすることを強くお勧めしますが、必須ではありません。それらがない場合、スキルは自動的にプラットフォームネイティブの SHA256/shasum にフォールバックします。結果は同一のシングルスレッドハッシュベースの比較となり、大きなファイルの山では遅くなりますが、信頼性は変わりません。

Q：このスキルは大きなディレクトリ（例えば 20,000 ファイルを含むフォルダ）を処理できますか？ A：はい。パフォーマンス戦略（セクション 9.6）は、プロファイルデータのフィルタリング、大規模なディレクトリツリーのセグメント化、必要な場合のみのコンテンツサンプリングなどにより、大きなスケール向けに特別に設計されています。

Q：整理された構造が気に入らない場合はどうすればよいですか？ A：apply の前に、plan.csv を確認して変更をプレビューできます。apply 後は、生成された undo スクリプトがすべての変更を元の状態に戻すことができます。

Folder Organizer