agent-sort

Agent Sort

Use esta skill quando um repositório precisar de uma superfície ECC específica para o projeto, em vez da instalação completa padrão.

O objetivo não é adivinhar o que "parece útil". O objetivo é classificar os componentes do ECC com evidências do código real.

Quando Usar

• Um projeto precisa apenas de um subconjunto do ECC e instalações completas são muito ruidosas
• A pilha do repositório é clara, mas ninguém quer fazer curadoria manual de skills uma a uma
• Uma equipe deseja uma decisão de instalação repetível, apoiada por evidências de grep, em vez de opiniões
• Você precisa separar superfícies de fluxo de trabalho diário (sempre carregadas) de superfícies de biblioteca/pesquisa
• Um repositório se desviou para o conjunto errado de linguagem, regra ou hook e precisa de limpeza

Regras Inegociáveis

• Use o repositório atual como fonte da verdade, não preferências genéricas
• Toda decisão DIÁRIA deve citar evidências concretas do repositório
• BIBLIOTECA não significa "excluir"; significa "manter acessível sem carregar por padrão"
• Não instale hooks, regras ou scripts que o repositório atual não possa usar
• Prefira superfícies nativas do ECC; não introduza um segundo sistema de instalação

Saídas

Produza estes artefatos em ordem:

1. Inventário DIÁRIO
2. Inventário BIBLIOTECA
3. Plano de instalação
4. Relatório de verificação
5. Roteador opcional skill-library se o projeto desejar um

Modelo de Classificação

Use apenas dois baldes:

• DIÁRIO
  • deve carregar a cada sessão para este repositório
  • fortemente correspondente à linguagem, framework, fluxo de trabalho ou superfície operacional do repositório
• BIBLIOTECA
  • útil para reter, mas não vale a pena carregar por padrão
  • deve permanecer acessível por meio de pesquisa, roteador de skill ou uso manual seletivo

Fontes de Evidência

Use evidências locais do repositório antes de fazer qualquer classificação:

• extensões de arquivo
• gerenciadores de pacotes e arquivos de bloqueio
• configurações de framework
• configurações de CI e hooks
• scripts de build/teste
• importações e manifestos de dependência
• documentação do repositório que descreve explicitamente a pilha

Comandos úteis incluem:

rg --files
rg -n "typescript|react|next|supabase|django|spring|flutter|swift"
cat package.json
cat pyproject.toml
cat Cargo.toml
cat pubspec.yaml
cat go.mod

Passadas de Revisão Paralelas

Se subagentes paralelos estiverem disponíveis, divida a revisão nestas passadas:

1. Agentes
   • classificar agents/*
2. Skills
   • classificar skills/*
3. Comandos
   • classificar commands/*
4. Regras
   • classificar rules/*
5. Hooks e scripts
   • classificar superfícies de hook, verificações de integridade MCP, scripts auxiliares e compatibilidade com SO
6. Extras
   • classificar contextos, exemplos, configurações MCP, modelos e documentos de orientação

Se subagentes não estiverem disponíveis, execute as mesmas passadas sequencialmente.

Fluxo de Trabalho Principal

1. Leia o repositório

Estabeleça a pilha real antes de classificar qualquer coisa:

• linguagens em uso
• frameworks em uso
• gerenciador de pacotes principal
• pilha de testes
• pilha de lint/format
• superfície de implantação/runtime
• integrações operacionais já presentes

2. Construa a tabela de evidências

Para cada superfície candidata, registre:

• caminho do componente
• tipo do componente
• balde proposto
• evidência do repositório
• justificativa curta

Use este formato:

skills/frontend-patterns | skill | DIÁRIO | 84 arquivos .tsx, next.config.ts presente | pilha frontend principal
skills/django-patterns   | skill | BIBLIOTECA | nenhum arquivo .py, nenhum pyproject.toml       | não ativo neste repositório
rules/typescript/*       | rules | DIÁRIO | package.json + tsconfig.json            | repositório TS ativo
rules/python/*           | rules | BIBLIOTECA | zero arquivos fonte Python             | manter apenas acessível

3. Decida DIÁRIO vs BIBLIOTECA

Promova para DIÁRIO quando:

• o repositório usa claramente a pilha correspondente
• o componente é geral o suficiente para ajudar em toda sessão
• o repositório já depende do runtime ou fluxo de trabalho correspondente

Rebaixe para BIBLIOTECA quando:

• o componente está fora da pilha
• o repositório pode precisar dele mais tarde, mas não todos os dias
• ele adiciona sobrecarga de contexto sem relevância imediata

4. Construa o plano de instalação

Traduza a classificação em ação:

• skills DIÁRIAS -> instalar ou manter em .claude/skills/
• comandos DIÁRIOS -> manter como shims explícitos apenas se ainda forem úteis
• regras DIÁRIAS -> instalar apenas os conjuntos de linguagem correspondentes
• hooks/scripts DIÁRIOS -> manter apenas os compatíveis
• superfícies BIBLIOTECA -> manter acessíveis por meio de pesquisa ou skill-library

Se o repositório já usa instalações seletivas, atualize esse plano em vez de criar outro sistema.

5. Crie o roteador de biblioteca opcional

Se o projeto desejar uma superfície de biblioteca pesquisável, crie:

• .claude/skills/skill-library/SKILL.md

Esse roteador deve conter:

• uma breve explicação de DIÁRIO vs BIBLIOTECA
• palavras-chave de gatilho agrupadas
• onde as referências da biblioteca estão localizadas

Não duplique o corpo de cada skill dentro do roteador.

6. Verifique o resultado

Após o plano ser aplicado, verifique:

• se todo arquivo DIÁRIO existe onde esperado
• se regras de linguagem obsoletas não foram deixadas ativas
• se hooks incompatíveis não foram instalados
• se a instalação resultante realmente corresponde à pilha do repositório

Retorne um relatório compacto com:

• contagem DIÁRIO
• contagem BIBLIOTECA
• superfícies obsoletas removidas
• perguntas em aberto

Transferências

Se o próximo passo for instalação interativa ou reparo, transfira para:

• configure-ecc

Se o próximo passo for limpeza de sobreposições ou revisão de catálogo, transfira para:

• skill-stocktake

Se o próximo passo for redução de contexto mais ampla, transfira para:

• strategic-compact

Formato de Saída

Retorne o resultado nesta ordem:

PILHA
- resumo da linguagem/framework/runtime

DIÁRIO
- itens sempre carregados com evidências

BIBLIOTECA
- itens de pesquisa/referência com evidências

PLANO DE INSTALAÇÃO
- o que deve ser instalado, removido ou roteado

VERIFICAÇÃO
- verificações realizadas e lacunas restantes