agent-sort

Agent Sort

Usa esta habilidad cuando un repositorio necesite una superficie ECC específica del proyecto en lugar de la instalación completa predeterminada.

El objetivo no es adivinar "lo que 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 está clara, pero nadie quiere seleccionar manualmente una por una las habilidades
• Un equipo quiere una decisión de instalación repetible respaldada por evidencia de grep, en lugar de opiniones
• Necesitas separar las superficies de flujo de trabajo diario siempre cargadas de las superficies de biblioteca/referencia buscables
• Un repositorio se ha desviado hacia un conjunto incorrecto de idiomas, reglas o hooks 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 cargarlo 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 de skill-library si el proyecto lo desea

Modelo de Clasificación

Usa solo dos categorías:

• DIARIO
  • debe cargarse cada sesión para este repositorio
  • fuertemente relacionado 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 a través de búsqueda, skill de 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

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

Revisiones Paralelas

Si hay subagentes paralelos disponibles, divide la revisión en estas pasadas:

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

Si los subagentes no están disponibles, ejecuta las mismas pasadas de forma secuencial.

Flujo de Trabajo Principal

1. Leer el repositorio

Establece la pila real antes de clasificar cualquier cosa:

• 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
• categoría propuesta
• 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/*       | rules | DIARIO | package.json + tsconfig.json            | repositorio TS activo
rules/python/*           | rules | BIBLIOTECA | cero archivos fuente Python             | mantener solo accesible

3. Decidir DIARIO vs BIBLIOTECA

Promover a DIARIO cuando:

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

Degradar a BIBLIOTECA cuando:

• el componente está fuera de la pila
• el repositorio podría necesitarlo más adelante, 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 acciones:

• skills DIARIO -> instalar o mantener en .claude/skills/
• comandos DIARIO -> mantener como shims explícitos solo si aún son útiles
• reglas DIARIO -> instalar solo los conjuntos de lenguaje coincidentes
• hooks/scripts DIARIO -> mantener solo los compatibles
• superficies BIBLIOTECA -> mantener accesibles a través de 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 desea 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 skill dentro del enrutador.

6. Verificar el resultado

Después de aplicar el plan, verifica:

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

Devuelve un informe compacto con:

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

Traspasos

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

• configure-ecc

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

• skill-stocktake

Si el siguiente paso es el recorte de contexto más amplio, traspasa a:

• strategic-compact

Formato de Salida

Devuelve el resultado en este orden:

PILA
- resumen del lenguaje/framework/runtime

DIARIO
- elementos siempre cargados con evidencia

BIBLIOTECA
- elementos buscables/de referencia con evidencia

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

VERIFICACIÓN
- comprobaciones realizadas y brechas restantes