agent-sort

Agent Sort (Clasificador de Agentes)

Usa este skill cuando un repositorio necesite una superficie de ECC específica para el proyecto en lugar de la instalación completa predeterminada.

El objetivo no es adivinar "qué parece útil". El objetivo es clasificar los componentes de ECC con evidencia del código base real.

Cuándo Usarlo

• Un proyecto solo necesita un subconjunto de ECC y las instalaciones completas son demasiado ruidosas.
• La pila del repositorio es clara, pero nadie quiere curar habilidades manualmente una por una.
• Un equipo quiere una decisión de instalación repetible respaldada por evidencia de grep en lugar de opiniones.
• Necesitas separar las superficies de trabajo diario siempre cargadas de las superficies de biblioteca/referencia buscables.
• Un repositorio ha derivado hacia un conjunto incorrecto de lenguaje, regla o hook y necesita limpieza.

Reglas No Negociables

• Usa el repositorio actual como fuente de verdad, no preferencias genéricas.
• Cada decisión DIARIO debe citar evidencia concreta del repositorio.
• BIBLIOTECA no significa "eliminar"; significa "mantener accesible sin cargar por defecto".
• No instales hooks, reglas o scripts que el repositorio actual no pueda usar.
• Prefiere superficies nativas de ECC; no introduzcas un segundo sistema de instalación.

Resultados

Produce estos artefactos en orden:

1. Inventario DIARIO
2. Inventario BIBLIOTECA
3. Plan de instalación
4. Informe de verificación
5. Enrutador opcional skill-library (biblioteca de habilidades) si el proyecto lo desea

Modelo de Clasificación

Usa solo dos cubos:

• DIARIO
  • debe cargarse en cada sesión para este repositorio
  • fuertemente emparejado con el lenguaje, framework, flujo de trabajo o superficie operativa del repositorio
• BIBLIOTECA
  • útil de conservar, pero no vale la pena cargarlo por defecto
  • debe permanecer accesible mediante búsqueda, skill enrutador o uso manual selectivo

Fuentes de Evidencia

Usa evidencia local del repositorio antes de hacer cualquier clasificación:

• extensiones de archivo
• gestores de paquetes y archivos de bloqueo
• configuraciones de framework
• configuraciones de CI y hooks
• scripts de compilación/prueba
• importaciones y manifiestos de dependencias
• documentación del repositorio que describa explícitamente la pila

Los comandos útiles incluyen:

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

Pasos de Revisión Paralela

Si hay subagentes paralelos disponibles, divide la revisión en estos pasos:

1. Agentes
   • clasificar agents/*
2. Habilidades
   • clasificar skills/*
3. Comandos
   • clasificar commands/*
4. Reglas
   • clasificar rules/*
5. Hooks y scripts
   • clasificar superficies de hooks, verificaciones de salud de MCP, scripts auxiliares y compatibilidad con SO
6. Extras
   • clasificar contextos, ejemplos, configuraciones de MCP, plantillas y documentos de guía

Si los subagentes no están disponibles, ejecuta los mismos pasos secuencialmente.

Flujo de Trabajo Principal

1. Leer el repositorio

Establece la pila real antes de clasificar nada:

• lenguajes en uso
• frameworks en uso
• gestor de paquetes principal
• pila de pruebas
• pila de lint/formato
• superficie de despliegue/ejecución
• integraciones operativas ya presentes

2. Construir la tabla de evidencia

Para cada superficie candidata, registra:

• ruta del componente
• tipo de componente
• cubo propuesto
• evidencia del repositorio
• justificación breve

Usa este formato:

skills/frontend-patterns | skill | DIARIO  | 84 archivos .tsx, next.config.ts presente | pila frontend principal
skills/django-patterns   | skill | BIBLIOTECA | sin archivos .py, sin pyproject.toml       | no activo en este repositorio
rules/typescript/*       | reglas | DIARIO | package.json + tsconfig.json            | repositorio TS activo
rules/python/*           | reglas | BIBLIOTECA | cero archivos fuente Python             | mantener solo accesible

3. Decidir DIARIO vs BIBLIOTECA

Promover a DIARIO cuando:

• el repositorio usa claramente la pila coincidente
• el componente es lo suficientemente general para ayudar en cada sesión
• el repositorio ya depende del tiempo de ejecución o flujo de trabajo correspondiente

Degradar a BIBLIOTECA cuando:

• el componente está fuera de la pila
• el repositorio podría necesitarlo más tarde, pero no todos los días
• añade sobrecarga de contexto sin relevancia inmediata

4. Construir el plan de instalación

Traduce la clasificación en acción:

• habilidades DIARIO -> instalar o mantener en .claude/skills/
• comandos DIARIO -> mantener solo como shims explícitos si aún son útiles
• reglas DIARIO -> instalar solo conjuntos de lenguaje coincidentes
• hooks/scripts DIARIO -> mantener solo los compatibles
• superficies BIBLIOTECA -> mantener accesibles mediante búsqueda o skill-library

Si el repositorio ya usa instalaciones selectivas, actualiza ese plan en lugar de crear otro sistema.

5. Crear el enrutador de biblioteca opcional

Si el proyecto quiere una superficie de biblioteca buscable, crea:

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

Ese enrutador debe contener:

• una breve explicación de DIARIO vs BIBLIOTECA
• palabras clave de activación agrupadas
• dónde residen las referencias de la biblioteca

No dupliques el cuerpo de cada habilidad dentro del enrutador.

6. Verificar el resultado

Después de aplicar el plan, verifica:

• cada archivo DIARIO existe donde se espera
• las reglas de lenguaje obsoletas no quedaron activas
• no se instalaron hooks incompatibles
• la instalación resultante realmente coincide con la pila del repositorio

Devuelve un informe compacto con:

• conteo DIARIO
• conteo BIBLIOTECA
• superficies obsoletas eliminadas
• preguntas abiertas

Transferencias

Si el siguiente paso es la instalación interactiva o la reparación, transfiere a:

• configure-ecc

Si el siguiente paso es la limpieza de superposiciones o la revisión del catálogo, transfiere a:

• skill-stocktake

Si el siguiente paso es la reducción más amplia del contexto, transfiere a:

• strategic-compact

Formato de Salida

Devuelve el resultado en este orden:

PILA
- resumen de lenguaje/framework/tiempo de ejecución

DIARIO
- elementos cargados siempre con evidencia

BIBLIOTECA
- elementos de referencia/búsqueda con evidencia

PLAN DE INSTALACIÓN
- qué debe instalarse, eliminarse o enrutarse

VERIFICACIÓN
- comprobaciones realizadas y brechas restantes