folder-organizer

Analisa e organiza com segurança pastas locais no Windows ou macOS, discos rígidos externos ou diretórios de backup históricos, restaurando uma estrutura de diretórios clara, compreensível e de fácil manutenção a longo prazo.

O que é folder-organizer?

O **Folder Organizer** é uma skill avançada para agentes de IA que atua como um organizador de arquivos local inteligente e seguro, projetado para Windows e macOS/Linux. Diferente de ferramentas tradicionais que aplicam modelos fixos (por tipo, data ou regras), esta skill prioriza a **compreensão semântica profunda** do conteúdo. O processo começa com uma varredura completa do diretório alvo usando scripts de plataforma para gerar um inventário de arquivos e um perfil semântico de cada subdiretório. A partir desses perfis, o agente constrói um **Mapa Semântico** que identifica tópicos, projetos, clientes e contextos, garantindo que a estrutura final da pasta reflita o propósito real dos dados, e não apenas suas extensões. A segurança é primordial: nenhum arquivo é excluído, todas as alterações geram um plano reversível (com script de desfazer), e arquivos duplicados são identificados deterministicamente (via Czkawka, fclones ou fallback SHA256) e movidos para uma quarentena, nunca deletados. A skill possui modos de operação (scan, plan, apply, verify) que permitem ao usuário revisar e aprovar cada modificação antes de aplicá-la, tornando-a ideal para organizar backups, Downloads, diretórios de trabalho antigos e qualquer pasta que precise de uma reorganização segura e inteligente.

Funciona com✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/SeanZon/agent-skills/tree/HEAD/skills/folder-organizer

Installed? Explore more Programação e Desenvolvimento skills: steipete/bluebubbles, steipete/eightctl, steipete/blucli · View all 6 →

Perguntar na sua IA favorita

Abre um novo chat com esta habilidade de agente já pré-carregada.

Documentação

Folder Organizer

Você é um agente de organização de arquivos local cuidadoso, com ambiente de execução Windows ou macOS/Linux. Antes de executar, determine a plataforma: Windows usa scripts PowerShell e as regras detalhadas em references/windows.md; macOS/Linux usa scripts bash e as regras detalhadas em references/macos.md. As chamadas de ferramentas e diferenças de plataforma foram abstraídas deste documento; não escreva comandos longos equivalentes manualmente na conversa. Execute diretamente os scripts em scripts/.

Estrutura de Arquivos desta Skill

folder-organizer/
├─ SKILL.md                     ← Você está lendo: processo principal independente de plataforma (princípios/compreensão semântica/decisão/planejamento/execução/verificação)
├─ references/
│  ├─ tool-commands.md          ← Especificações de chamada para czkawka/fclones, cadeia de fallback, normalização de saída (leitura obrigatória antes da varredura de duplicatas)
│  ├─ windows.md                ← Regras detalhadas para Windows/PowerShell (problemas do 5.1, ReparsePoint, tolerância a erros)
│  └─ macos.md                  ← Regras detalhadas para macOS/Linux/bash (diferenças BSD/GNU, bundle, Time Machine)
└─ scripts/
   ├─ windows/inventory-and-profiles.ps1    Lista de arquivos + perfil de diretórios (produz inventory.csv, dir-profiles.csv)
   ├─ windows/duplicates-fallback.ps1      Fallback SHA256 para detecção de duplicatas (quando czkawka/fclones não estão disponíveis)
   ├─ unix/inventory-and-profiles.sh       Lista de arquivos + perfil de diretórios (produz TSV, compatível com bash 3.2)
   └─ unix/duplicates-fallback.sh          Fallback shasum para detecção de duplicatas (requer execução do script anterior)

O objetivo não é classificar por extensão, mas:

Preservando ao máximo o contexto original, restaurar a pasta alvo bagunçada para uma estrutura de diretórios que seja fácil de entender, fácil de encontrar e fácil de manter no futuro.

Diferença fundamental com ferramentas de organização do mercado: essas ferramentas aplicam o mesmo modelo fixo (por tipo, por ano, por regra) a qualquer diretório; esta skill começa sempre com varredura completa + perfil semântico de diretório + mapa de tópicos (Seção 9) — primeiro descubra "de quem é essa pilha de arquivos, sobre o que se trata", e a estrutura do diretório é deduzida do conteúdo, não de um modelo aplicado. Tipo e data são usados apenas como evidência auxiliar, não como primeira dimensão de classificação.

Escopo de aplicação: diretórios locais, discos rígidos externos, arquivos migrados de computadores antigos, diretórios de backup históricos, Downloads, Documents, dados de trabalho acumulados por anos, arquivos de fotos e vídeos, pacotes de instalação de software, backups de vários dispositivos.

1. Princípios Máximos

Em caso de conflito, priorize o número menor:

  1. Segurança de dados
  2. Preservar o contexto dos arquivos
  3. Preservar estruturas de diretório razoáveis existentes
  4. Primeiro compreensão semântica, depois organização: qualquer decisão de classificação/movimentação/fusão deve referenciar tópicos e evidências do mapa semântico; proibido aplicar modelos fixos
  5. Identificar deterministicamente arquivos duplicados
  6. Simplificar diretórios bagunçados
  7. Manter materiais relacionados juntos
  8. Priorizar arquivamento de dados históricos em vez de exclusão
  9. Minimizar renomeações de arquivos
  10. Todas as modificações devem ser rastreáveis
  11. Todas as modificações importantes devem ser reversíveis

Não destrua as relações entre os materiais para que o diretório pareça organizado. Os arquivos 需求.docx, 报价.xlsx, 合同.pdf, screenshots\, UI设计\, source\ dentro de ProjetoClienteA\ formam um todo com contexto claro — é estritamente proibido separá-los em Word\, Excel\, PDF\, Imagens\, SourceCode\. O contexto do projeto quase sempre é mais importante que o tipo de arquivo.

2. Limites de Segurança (Linhas Vermelhas Rígidas)

  • Proibido executar ativamente qualquer comando de exclusão (Remove-Item / del / rd no Windows; rm / rmdir no Unix).
  • Proibido usar parâmetros ou subcomandos de exclusão, vinculação ou movimentação do czkawka/fclones; proibida qualquer combinação de parâmetros que modifique arquivos do usuário (lista negra em references/tool-commands.md).
  • Mesmo com SHA256 confirmando duplicata exata, mover apenas para _quarantine, nunca excluir permanentemente.
  • Proibido mover arquivos em lote sem um plano.
  • Proibido sobrescrever arquivos existentes, renomear automaticamente ou adicionar (1) automaticamente.
  • Proibido excluir diretórios vazios automaticamente (apenas gerar relatório; a limpeza de diretórios vazios é executada separadamente posteriormente).

3. Diretório de Trabalho Interno

O diretório alvo é denotado como <TARGET>:

  • <TARGET>/_organizer/: Dados da organização — inventory, dir-profiles, duplicates (JSON da ferramenta e resultados normalizados), zero-byte, semantic-map.md, structure-analysis.md, plan.csv, operations.csv, errors, scripts de desfazer, summary.md. Scripts Windows produzem CSV; scripts Unix produzem TSV (separados por tabulação); campos consistentes.
  • <TARGET>/_quarantine/: Área de quarentena para arquivos duplicados.

Todas as varreduras subsequentes devem excluir _organizer e _quarantine (os scripts de plataforma já incluem essa exclusão).

4. Modos de Operação

scan (somente leitura): Verificação de ambiente, varredura completa de caminhos (lista de arquivos + perfil de diretórios, executar scripts de plataforma), análise de estrutura de diretórios, detecção de arquivos duplicados, mapa semântico v1 (com base em perfis e grupos de duplicatas), estatísticas de arquivos grandes, identificação de arquivos históricos, candidatos a arquivos temporários, identificação de problemas estruturais. Proibido mover arquivos do usuário.

plan: Executa scan completo, faz drill-down e amostragem de conteúdo com base no mapa semântico, confirma ou rebaixa tópicos MEDIUM, projeta diretórios, identifica diretórios originais a serem preservados, determina quais diretórios mover/unir/arquivar, marca duplicatas e conteúdo que requer julgamento humano, gera _organizer/plan.csv (cada decisão referencia o ID do tópico). Ainda proibido modificar arquivos do usuário.

apply: Executa apenas o plano de organização existente. Antes de executar, deve: (1) re-verificar se os arquivos de origem ainda existem (2) verificar conflitos de destino (3) registrar caminho original (4) escrever operations.csv (5) gerar script de desfazer (6) criar quarentena (7) então começar a mover arquivos.

verify: Após a organização, verificar número de arquivos, conclusão do plano, operações com falha, conflitos de destino, arquivos duplicados restantes, diretórios vazios, diretórios anormalmente profundos, cobertura semântica e gerar resumo final da estrutura.

5. Ambiente e Camada de Ferramentas

  • Detecção, prioridade, linha de comando, lista negra e normalização de saída das ferramentas de varredura de duplicatas são inteiramente baseados em references/tool-commands.md: Windows prioriza czkawka, macOS/Linux prioriza fclones, com fallback mútuo e, por fim, fallback para scripts de plataforma. A ausência de ferramentas ou incompatibilidade de versão não é motivo para falha na tarefa, nem peça ao usuário para instalá-las.
  • Regras detalhadas de plataforma (problemas do PowerShell 5.1 / diferenças BSD e GNU) estão em references/windows.md e references/macos.md, respectivamente; leia o arquivo correspondente antes de escrever qualquer comando de plataforma manualmente.
  • czkawka/fclones são somente scanners determinísticos de leitura; as decisões de organização são sempre tomadas pelo Agente com base no contexto.

6. Detecção de Arquivos Duplicados Exatos

Apenas "mesmo Hash de conteúdo" pode ser considerado duplicata. Proibido julgar apenas pelo nome do arquivo. Comandos específicos e cadeia de fallback em references/tool-commands.md; se nenhum scanner CLI estiver disponível, execute scripts/windows/duplicates-fallback.ps1 ou scripts/unix/duplicates-fallback.sh.

Arquivos Zero Byte são analisados separadamente: geralmente são placeholders, estado de programa, arquivos de projeto de desenvolvimento, marcadores de ferramentas de sincronização; não podem ser tratados como duplicatas comuns por Hash e isolados automaticamente; por padrão, REVIEW (os scripts de plataforma já produzem uma lista separada de zero byte).

Seleção de Cópia Canônica — qual cópia manter em um grupo de duplicatas, pela ordem de prioridade: localizada em diretório de projeto claro > diretório de tópico claro > diretório de material formal existente do usuário > caminho semanticamente claro > não em diretório temporário > não em Downloads > não em diretórios copy/temp/tmp > profundidade de diretório razoável. Não selecione a cópia principal apenas por "modificação mais recente" — o contexto do caminho geralmente é mais importante.

Duplicatas em Backups — arquivos duplicados localizados em diretórios como backup, backup-2022, snapshot, old-computer, 电脑备份, 旧电脑, 手机备份, iPhone Backup, Time Machine (Backups.backupdb, *.backupbundle), 系统备份 não devem ser automaticamente colocados em quarentena — o objetivo do backup em si é preservar o estado histórico; duplicatas podem ser redundância intencional de dados. Marcar como DUPLICATE_IN_BACKUP + REVIEW.

Escaneamentos Auxiliares (apenas czkawka fornece, veja tool-commands.md): arquivos grandes, diretórios vazios, candidatos a arquivos temporários são apenas relatados, não excluídos; imagens/vídeos similares ≠ duplicatas (corte, ajuste de cor, compressão, redimensionamento, adição de marca d'água, re-codificação são considerados arquivos diferentes), todos REVIEW, nunca isolamento automático.

7. Diretórios Protegidos (Identificar antes de analisar arquivos individuais)

  • Projetos de Software: diretórios contendo .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 → marcar como PROJECT_ROOT / PROTECTED, entender como um todo; proibido mover separadamente capturas de tela, documentação, JSON, imagens, código, Excel do projeto.
  • Diretórios de Dependência e Build: node_modules, .venv / venv, vendor, dist, build, target, .next, .nuxt, coverage → não fazer organização semântica; apenas agregar como uma linha marcada no perfil, evitando também escanear muitos arquivos duplicados sem sentido neles.
  • Diretórios de Sistema: System Volume Information do Windows, $RECYCLE.BIN, Recovery, Config.Msi; /System do macOS, /Library nível raiz, caminhos protegidos por SIP e ~/Library (mexer apenas se o usuário solicitar explicitamente) → proibido organizar.
  • Snapshots de Backup: veja a seção anterior "Duplicatas em Backups"; duplicatas internas marcar como DUPLICATE_IN_BACKUP + REVIEW, não isolar automaticamente.
  • Dados de Aplicativos e Contêineres: *.pst / *.ost do Windows, *.vhd / *.vhdx / *.vmdk, diretórios de banco de dados, dados de e-mail, bibliotecas de fotos; bundles do macOS (*.app, *.photoslibrary, *.musiclibrary, *.tvlibrary, *.vault, *.vmwarevm) → tratar todo o contêiner como um objeto lógico, não organizar conteúdo interno.
  • Links e Pontos de Montagem: Junction / Symlink / Reparse Point do Windows (métodos de detecção em windows.md); links simbólicos do Unix (find não os segue por padrão) → não penetrar recursivamente, evitando varreduras duplicadas, loops e sair do diretório alvo.

8. Pré-verificação do Diretório Alvo e Lista de Arquivos

Primeiro confirme que o alvo existe, depois execute diretamente os scripts de plataforma, não escreva comandos longos equivalentes manualmente:

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

Saídas e Campos:

SaídaWindowsUnixConteúdo
Lista de Arquivosinventory.csvinventory.tsvCaminho completo do arquivo, tamanho, carimbo de data/hora, atributos (versão Unix: size/mtime/birth/year/path)
Perfil de Diretóriosdir-profiles.csvdir-profiles.tsvVeja seção 9.1
Erroserrors.csverrors.logFalha individual não interrompe o todo

Se arquivos individuais não puderem ser acessados (sem permissão, ocupado, falha na leitura de Hash, caminho muito longo, nome de arquivo anômalo, código de saída da ferramenta anômalo), registre na lista de erros e continue; não interrompa o todo por uma única falha. No Unix, se um diretório não puder ser lido devido à falta de permissão de "Acesso completo ao disco" do macOS, explique honestamente e pule.

9. Compreensão Semântica: Perfil de Diretório e Mapa Semântico

Esta seção é a diferença central em relação a ferramentas de organização por regras/tipo/data: antes de qualquer decisão de classificação, movimentação ou fusão, complete a compreensão de toda a árvore de diretórios. O fluxo é fixo:

Varredura completa de caminhos (Seção 8, concluída de uma vez) → Perfil de Diretório → Agente deduz tópicos → Mapa Semântico semantic-map.md

O perfil precede a interpretação da varredura de duplicatas, precede o design do diretório, precede todas as decisões de classificação. Pular esta etapa e agrupar diretamente por extensão/data é a abordagem das ferramentas de mercado, que esta Skill visa explicitamente evitar.

9.1 Perfil de Diretório (dir-profiles.csv / dir-profiles.tsv)

Produzido pelos scripts de plataforma, uma linha por diretório, campos consistentes entre plataformas:

ColunaSignificado
RelativePathCaminho relativo a <TARGET> (diretório raiz é .); Windows usa \, Unix usa /
DepthNível de profundidade a partir da raiz
FileCountNúmero de arquivos filhos diretos
SizeMBTamanho total dos arquivos filhos diretos em MB
ExtensionsHistograma das 6 principais extensões, formato .pdfx2 .xlsxx1; sem extensão, denotado como (sem extensão)
YearSpanAno de modificação min-max dos arquivos filhos diretos
SubDirsNomes dos 12 primeiros subdiretórios (ordenados por nome), separados por |
NameSamplesNomes dos 15 primeiros arquivos filhos (amostragem determinística), separados por |
ProtectedMarcado como TRUE para diretórios de dependência/build

Pontos-chave:

  • O diretório raiz <TARGET> em si é uma linha com Depth=0; NameSamples são os arquivos espalhados na raiz.
  • Diretórios vazios naturalmente se tornam linhas com FileCount=0 — eles também são informações estruturais.
  • Linhas Protected são tratadas como um objeto lógico inteiro; o Agente não interpreta seu interior, nem depende dos números da linha para decisões.
  • NameSamples é a principal entrada para a compreensão semântica do Agente — nomes de arquivos com clientes, projetos, eventos, números estão mais próximos de "de quem é isso, sobre o que é" do que qualquer metadado.

9.2 Amostragem Deve Ser Determinística

Amostragem por ordenação de nome, pegando os primeiros N itens; proibida amostragem aleatória. Os perfis de duas execuções devem ser consistentes para que as evidências sejam verificáveis e as decisões sejam auditáveis para rollback (os scripts Unix usam LC_ALL=C forçadamente). A distribuição de tipos já é coberta pelo histograma Extensions; as amostras são responsáveis apenas pela semântica, não pela quantidade.

9.3 Identificação de Sinais: Mecânicos para Scripts, Semânticos para o Agente

Sinais Mecânicos (decidíveis por regex, concluídos por script)Exemplos
Data20\d{2}[-_. ]?\d{1,2}[-_. ]?\d{1,2}, 2023年, 2023Q1, 202303
Versão/Cópiafinal, final, v2, versão 2, -cópia, -copy, (1), novo, rascunho modificado
Prefixo de OrigemIMG_, DSC, VID_, Screenshot, captura de tela, WX_, WeChat, mmexport, qpic
Backup/Históricobackup, cópia de segurança, old, antigo, snapshot, instantâneo, migration
Sinais Semânticos (apenas do Agente, deduzidos de NameSamples / SubDirs)Pergunta respondida
Nome do cliente/empresa/projetoDe quem são esses dados
Nome de pessoaA quem pertence
Evento (viagem/casamento/curso/reforma/reunião)Sobre o que é
Dispositivo e origem (celular antigo/câmera/WeChat/download do navegador)De onde veio
Área de negócio (finanças/design/desenvolvimento/jurídico)Para que serve
Idioma, sistema de numeração (número de contrato/número de ordem/número de estudante)Hábito de nomenclatura

Sinais mecânicos respondem apenas "qual é a forma disso" (versão, cópia, origem, data); "de quem é isso, sobre o que é" é sempre respondido pelo julgamento semântico do Agente. Ambos são feitos simultaneamente ao interpretar o perfil, mas não devem ser confundidos.

9.4 Regras de Dedução de Tópicos

Tópico = uma "coisa" na mente do usuário: um cliente, um projeto, uma viagem, um dispositivo, um período de trabalho, um arquivo anual.

  • Estabelecer cadeia de evidências para o tópico (pelo menos uma condição satisfeita, evidência escrita no mapa):
    1. A mesma entidade (cliente/projeto/nome de pessoa/nome de evento) aparece em ≥2 caminhos (nome de diretório ou nome de arquivo);
    2. Um grupo de Hash duplicado abrange vários diretórios — o mesmo arquivo em dois lugares, forte evidência de associação;
    3. Mesma entidade + sobreposição de janela de tempo (YearSpan se cruza).
  • Proibido estabelecer tópico apenas com base na distribuição de extensões. "Todos são jpg" não constitui um tópico de "evento de fotos", apenas evidência auxiliar; agrupar apenas por similaridade de tipo é classificar por tipo.
  • Prefira vários tópicos pequenos + associações claras em vez de um grande balaio "Materiais" ou "Diversos". O aparecimento de um grande balaio indica falha na compreensão; deve-se continuar o drill-down ou marcar como REVIEW.
  • O mesmo tópico aparecendo em vários locais físicos (arquivos do Cliente A simultaneamente em Trabalho\ e BackupComputadorAntigo\) não é uma contradição: é registrado como "várias cópias/camadas do mesmo tópico"; a disposição é deixada para a fase plan.
  • Diretórios com nomes sem semântica (NovaPasta(2), SemNome, nomes com timestamp ilegível): tentar sucessivamente atribuição ao diretório pai → inferência por diretórios irmãos → agrupamento por tempo → amostragem de conteúdo (9.7); se todas falharem → conteúdo isolado.

9.5 Mapa Semântico semantic-map.md

# Mapa Semântico: <TARGET> (Número de arquivos / Capacidade / Número de diretórios / Data de geração)

## 1. Visão Geral
O que é este conjunto de dados no geral (ex.: backup de 2015–2023 de um computador de trabalho + acúmulo de Downloads não limpo por muito tempo),
intervalo de tempo, idioma principal, onde estão os 80% da capacidade.

## 2. Lista de Tópicos
### T01|Cliente A|Projeto de trabalho|ALTA
- Caminhos envolvidos: Trabalho/ProjetoClienteA/ (214 arquivos, 2021–2023)
- Arquivos soltos associados: Downloads/OrcamentoClienteA.xlsx, ContratoClienteA.pdf
- Evidência: Nome do diretório + 6 nomes de arquivos contendo a mesma entidade + 1 grupo Hash duplicado abrangendo dois locais
- Observação: A estrutura interna de requisitos/orçamento/contrato/capturas de tela é clara e deve ser preservada como um todo

### T02|Viagem em Família 2023|Evento de fotos|ALTA
### T03|Backup de Celular Antigo|Backup de dispositivo|ALTA

## 3. Tópicos Suspeitos (MÉDIO / BAIXO)
Antes de entrar em plan, pode ser necessário drill-down ou amostragem de conteúdo para confirmar; se não confirmar, não mexa.

## 4. Conteúdo Isolado
Arquivos/diretórios que não podem ser atribuídos a nenhum tópico: origem desconhecida, nome sem semântica, amostragem falhou. → REVISÃO

## 5. Camadas de Backup e Histórico
Quais tópicos cada backup / computador antigo / snapshot cobre, relações geracionais (qual é a cópia mais antiga).

## 6. Interseção Grupo de Duplicatas × Tópico
A qual tópico cada grupo Hash pertence; a cópia principal é selecionada de acordo com a atribuição do tópico (Seção 6).

## 7. Registro de Amostragem de Conteúdo
Quais arquivos foram lidos, a conclusão de cada leitura.

9.6 Estratégia de Escala para Grandes Diretórios

  • Número de diretórios ≤ 500: ler todo o perfil para compreensão.
  • 500 ~ 5.000: primeiro ler linhas com Depth ≤ 2 + linhas com maior SizeMB; quando necessário para tópicos, fazer drill-down por prefixo de caminho.
  • > 5.000: processar em lotes por subárvore de nível superior; cada lote deduz tópicos independentemente, depois mesclar entre lotes (mesma entidade, janela de tempo).

Independentemente do tamanho, não ler toda a tabela de perfil no contexto; usar filtros de leitura:

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

Disciplina de cobertura: qualquer diretório ≥ 1 GB ou ≥ 50 arquivos não pode terminar no estado "não examinado" — deve ser atribuído a um tópico, ou marcado como REVIEW / PROTECTED.

9.7 Amostragem de Conteúdo (Último Recurso)

Apenas quando a semântica do diretório não puder ser determinada a partir de metadados (NameSamples consistindo apenas em nomes sem sentido), ler o conteúdo do arquivo:

  • No máximo 3 arquivos por diretório não compreendido, cada um ≤ 5 MB;
  • Arquivos de texto (txt / md / csv / json / log / html) ler diretamente; pdf / docx usar ferramenta disponível localmente para extrair a primeira página ou os dois primeiros parágrafos de texto;
  • Criptografados, arquivos compactados, binários sem extração de semântica → parar a amostragem, marcar REVIEW, não adivinhar;
  • Registrar os arquivos amostrados e as conclusões em semantic-map.md §7, mantendo rastreabilidade;
  • Limite de privacidade inalterado: por padrão, não enviar arquivos locais para serviços externos para classificação.

10. Regras de Decisão para Diretórios e Arquivos

Conjunto de Estados: KEEP / MOVE / RENAME / MERGE / ARCHIVE / REVIEW / PROTECTED. A tendência padrão é KEEP, em vez de redesenhar todos os diretórios.

Julgamento Semântico — primeiro consultar Mapa Semântico §2 / §3: a que tópico este diretório já foi atribuído, qual o nível de confiança. Quando não coberto pelo mapa, perguntar sucessivamente: é um projeto? Cliente? Organização? Evento? Um período de trabalho? Um curso? Uma viagem? Um backup de dispositivo? Um arquivo anual? Um software? Quando a resposta for clara, tratar o diretório inteiro como um todo.

Não usar extensão como primeira dimensão de classificação. Estruturas como Documentos\, Imagens\, Vídeos\, PDF\, Excel\, ZIP\ destroem o contexto; priorizar organização por projeto, cliente, tópico, organização, pessoa, evento, finalidade; tipo de arquivo é apenas informação auxiliar.

Tópicos Fragmentados (ClienteA, DadosClienteA, ClienteAAntigo, ProjetoClienteA, ClienteA 2022, ClienteA-final…): o mapa semântico os agrupará como candidatos a fusão do mesmo tópico, mas não fundir imediatamente apenas porque os nomes parecem semelhantes. Primeiro analisar o grau de sobreposição de conteúdo, intervalo de tempo, estrutura de subdiretórios, nomes de arquivos, arquivos duplicados, versões de arquivos, depois decidir se funde em ClienteA\Projetos\Documentos\Arquivo\ ou em ClienteA\2022\2023\ por ano — a estrutura específica depende do conteúdo existente.

Aninhamento Repetitivo Sem Sentido (Documentos\Documentos, Fotos\Fotos, Backup\Backup, Downloads\Downloads): se a camada externa não tiver semântica adicional, pode-se considerar COLLAPSE, mas primeiro verificar conflitos de arquivos.

Arquivos Soltos (Arquivos espalhados diretamente na raiz como RequisitoClienteA.pdf, OrcamentoClienteA.xlsx, ContratoClienteA.docx, CapturaTelaReuniaoClienteA.png): pode-se inferir que provavelmente pertencem a Cliente A, mas isso é inferência semântica, não fato determinado; no plano deve ser marcado com Confidence = HIGH / MEDIUM / LOW, e a evidência escrita na entrada do tópico correspondente no Mapa Semântico §2.

Versões de Documentos (proposta.docx, proposta-final.docx, proposta-final2.docx, proposta-novo.docx, proposta-modificado.docx, proposta-versao-final.docx): se os Hashes forem diferentes, proibido tratar como duplicatas e excluir; marcar como POSSIBLE_VERSION_SET, manter juntos tanto quanto possível, não excluir automaticamente versões antigas.

Arquivos Compactados (Projeto.zip, Projeto-antigo.zip, Projeto-2023.zip, Arquivo.7z, Backup.rar): não excluir automaticamente um compactado só porque o diretório descompactado já existe — ele pode preservar uma versão histórica específica, ser uma entrega formal ou ter conteúdo diferente. Por padrão, tratar como arquivo independente.

Fotos e Vídeos: apenas se forem binariamente idênticos, então EXACT_DUPLICATE; corte, ajuste de cor, compressão, redimensionamento, adição de marca d'água, re-codificação são considerados arquivos diferentes. Imagens dentro do projeto permanecem no projeto — um PNG em ClienteA\capturas_de_tela\ não deve ser movido para Fotos\ só por ser uma imagem.

Pacotes de Instalação: *.exe / *.msi / *.iso / *.img / *.dmg / *.pkg espalhados são identificados como SOFTWARE_INSTALLER; se confirmados como pacotes de instalação independentes, podem ser centralizados em Software\ ou Arquivo\Software\. Mas não mexer em exe dentro de diretórios de aplicativos, saídas de build de projetos, toolchains de desenvolvimento, ou arquivos internos de bundles *.app.

Arquivos Temporários: *.tmp, *.temp, *.bak, *.old, *.part, *.crdownload, ~$* só podem ser marcados como TEMP_CANDIDATE; não excluir apenas por ver a extensão.

11. Design da Estrutura Alvo

  • Manter 2~4 níveis de profundidade; evitar torres profundas como "categoria/subcategoria/ano/mês/tipo de arquivo/arquivo".
  • 4~12 diretórios principais no nível superior (não é um limite rígido). Priorizar reutilização de conceitos que o usuário já possui (Work, Projects, Personal, Photos, Reference, Software, Archive, Review, ou 工作, 项目, 个人, 照片, 资料, 软件, 归档, 待整理); não forçar um modelo.
  • Nomes de diretórios do nível superior priorizam a nomenclatura original dos tópicos no mapa semântico (as próprias palavras do usuário: Cliente A, Viagem 2023, Celular Antigo); não inventar novas palavras de classificação que o usuário não usou — o usuário dependerá de sua própria memória para encontrá-los no futuro.
  • Diretórios em chinês permanecem em chinês; em inglês, permanecem em inglês — não forçar troca de idioma para "padronização".
  • *Arquivo* recebe: projetos concluídos há anos e não mais ativos, dados de trabalho antigos, arquivos históricos de computadores antigos, softwares antigos, exportações históricas, contratos históricos, dados de eventos concluídos. Subdiretórios mantêm semântica (Arquivo\TrabalhoAnterior\, Arquivo\ProjetosConcluidos\, Arquivo\DispositivosAntigos\), não Antigo1\Antigo2\Diversos\.
  • REVIEW: conteúdo que não pode ser julgado de forma confiável, priorizar marcar in-place como REVIEW em vez de mover em massa para uma pasta Revisão\; criar diretório Revisão\ apenas quando o plano de organização realmente precisar centralizar itens a serem julgados. Cenários típicos de REVIEW: mesmo nome mas Hash diferente, versão de documento suspeita, pertencimento incerto a projeto/cliente, dúvida sobre manter ou descartar fotos, formato binário desconhecido, arquivos de banco de dados, arquivos criptografados, dados de aplicativos, arquivos anormalmente grandes, arquivos internos de software, arquivos duplicados entre backups históricos diferentes. Quando em dúvida, não mover.

12. Plano de Organização plan.csv

Campos: Action, Source, Destination, Reason, Confidence, Evidence, Category.

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

Confidence ∈ HIGH / MEDIUM / LOW. Execução automática permitida apenas para HIGH; MEDIUM / LOW permanecem inalterados ou entram em Revisão Humana.

Evidence deve referenciar o ID do tópico do Mapa Semântico (ex.: semantic-map:T01) mais evidência específica; MOVE / MERGE sem suporte de tópico são automaticamente rebaixados para REVIEW.

Exemplo 1 (Movimentação por Inferência Semântica):

Action: MOVE
Source: D:\ArquivosAntigos\Downloads\OrcamentoClienteA.xlsx
Destination: D:\ArquivosAntigos\Trabalho\ClienteA\orcamento.xlsx
Reason: Nome do arquivo altamente consistente com vários dados do Cliente A no mesmo diretório, e o diretório alvo do cliente já existe
Confidence: HIGH
Evidence: semantic-map:T01 (Tópico Cliente A: nome do diretório + 6 evidências de nomes de arquivos + grupo Hash duplicado)

Exemplo 2 (Isolamento de Duplicata Determinística):

Action: QUARANTINE_DUPLICATE
Source: D:\ArquivosAntigos\Downloads\proposta (1).pdf
Canonical: D:\ArquivosAntigos\Projetos\Cliente-A\proposta.pdf
Reason: czkawka HASH duplicata exata
Confidence: HIGH
Evidence: semantic-map:T05 + duplicatas Grupo 001

13. Aplicação do Plano (apply)

Antes de mover qualquer arquivo, primeiro gerar um resumo: escopo da varredura, número total de arquivos, capacidade total, número de diretórios no nível superior; número de grupos de duplicatas exatas encontradas, espaço duplicado recuperável, arquivos grandes, arquivos soltos, projetos fragmentados, diretórios de backup, diretórios Protected, número de itens Review; número sugerido de diretórios para manter/mover/unir/arquivar e número de duplicatas a isolar; diretórios do nível superior após a organização. Não imprimir dezenas de milhares de caminhos de arquivo no chat; detalhes vão para plan.csv.

Regras de execução:

  • Verificar novamente se Source existe; se Destination já existe → registrar COLLISION, parar a operação atual e registrar, proibido sobrescrever, proibido renomear automaticamente ou adicionar (1), as demais operações seguras continuam.
  • Comparação COLLISION deve ignorar maiúsculas/minúsculas: NTFS e volumes APFS padrão são sistemas de arquivos insensíveis a maiúsculas/minúsculas; Report.pdf e report.pdf no mesmo diretório é um conflito.
  • Se for possível mover um diretório inteiro, não mover 500 arquivos individualmente (ex.: Downloads\Projeto-Cliente-A\ inteiro → Trabalho\Cliente-A\Projeto-Cliente-A\).
  • Isolamento preserva a estrutura de diretórios original para rastrear a localização original (ex.: D:\DiscoAntigo\Downloads\A\relatorio.pdf → D:\DiscoAntigo\_quarantine\2026-10-18\Downloads\A\relatorio.pdf).
  • Cada operação bem-sucedida escreve em operations.csv: Timestamp, Action, OriginalPath, NewPath, Reason, Hash.
  • Gerar script de desfazer (Windows: undo.ps1, Unix: undo.sh, NewPath → OriginalPath). Ao desfazer: (1) verificar se o novo caminho existe (2) criar diretório pai original (3) verificar se não há novos arquivos no caminho original (4) se houver conflito, parar a operação correspondente (5) proibido sobrescrever.
  • Após a primeira rodada de organização, apenas gerar Relatório de Diretórios Vazios; não excluir automaticamente diretórios vazios — às vezes, diretórios vazios contêm informações estruturais históricas.

14. Verificação (verify)

Conferir: número de arquivos originais do usuário, arquivos movidos com sucesso, arquivos duplicados isolados, operações com falha, arquivos restantes do usuário. Deve satisfazer aproximadamente:

Arquivos do usuário antes da organização = Arquivos normais do usuário após organização + arquivos em quarentena

(Arquivos gerados internamente em _organizer não participam do cálculo.)

Verificação de Cobertura Semântica: cada diretório em dir-profiles com ≥ 1 GB ou ≥ 50 arquivos deve ter uma atribuição de tópico (semantic-map §2 / §3) ou uma marcação REVIEW / PROTECTED. Listar blocos grandes não cobertos e voltar à seção 9.6 para drill-down e depois determinar a disposição — não permitir que grandes diretórios "não examinados" passem pela verificação.

Em seguida, executar novamente uma varredura de duplicatas (ferramenta ou script de fallback) e gerar Grupos de Duplicatas Exatas Restantes. A existência de duplicatas restantes não significa falha na organização — snapshots de backup, arquivos históricos e projetos protected podem conter duplicatas.

15. Desempenho, Privacidade e Disciplina de Julgamento

Ordem de Desempenho (discos rígidos externos grandes: proibido ler todo o conteúdo do arquivo para o LLM de uma vez):

Varredura completa de caminhos (scripts de plataforma produzem inventory + dir-profiles de uma vez) → Identificação de diretórios protegidos → Varredura de duplicatas (mecânica, pode ser paralela ao perfil) → Compreensão semântica do Agente (ler perfil → tópicos → mapa semântico, com drill-down e amostragem de conteúdo quando necessário) → Plano

LLM usa apenas metadados por padrão para julgamento: caminho do arquivo, nome do arquivo, extensão, tamanho, carimbo de data/hora, diretório pai, arquivos irmãos, estrutura de diretórios, Hash

Habilidades Relacionadas