Agente de Classificação

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

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

Quando Usar

• Um projeto precisa apenas de um subconjunto do ECC e instalações completas são muito barulhentas.
• A pilha do repositório está clara, mas ninguém quer curar manualmente as habilidades uma a uma.
• Uma equipe quer 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/referência pesquisáveis.
• Um repositório se desviou para o idioma, regra ou conjunto de hooks errado 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. Opcionalmente, um roteador skill-library se o projeto desejar um.

Modelo de Classificação

Use apenas dois grupos:

• DAILY
  • deve carregar toda sessão para este repositório
  • fortemente correspondente ao idioma, framework, fluxo de trabalho ou superfície do operador do repositório
• LIBRARY
  • útil para reter, mas não vale a pena carregar por padrão
  • deve permanecer acessível através de pesquisa, habilidade de roteador 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
• imports 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

Passagens de Revisão Paralela

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

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

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

Fluxo de Trabalho Principal

1. Leia o repositório

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

• idiomas em uso
• frameworks em uso
• gerenciador de pacotes principal
• pilha de testes
• pilha de lint/formatação
• superfície de implantação/execução
• integrações de operador já presentes

2. Construa a tabela de evidências

Para cada superfície candidata, registre:

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

Use este formato:

skills/frontend-patterns | skill | DAILY | 84 .tsx files, next.config.ts present | core frontend stack
skills/django-patterns   | skill | LIBRARY | no .py files, no pyproject.toml       | not active in this repo
rules/typescript/*       | rules | DAILY | package.json + tsconfig.json            | active TS repo
rules/python/*           | rules | LIBRARY | zero Python source files             | keep accessible only

3. Decida DIÁRIO vs BIBLIOTECA

Promova para DAILY quando:

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

Rebaixe para LIBRARY quando:

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

4. Construa o plano de instalação

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

• habilidades DIÁRIAS -> instale ou mantenha em .claude/skills/
• comandos DIÁRIOS -> mantenha como shims explícitos apenas se ainda úteis
• regras DIÁRIAS -> instale apenas conjuntos de idiomas correspondentes
• hooks/scripts DIÁRIOS -> mantenha apenas os compatíveis
• superfícies BIBLIOTECA -> mantenha acessíveis através 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: