Sinergia de Skills — reglas de arbitraje
Una autoridad para determinar qué skill gana cuando varios se activan. Lee esto cuando dos o más skills puedan aplicarse de manera plausible a la tarea actual.
Nota de uso: este skill es el conjunto detallado de reglas. Una carta concisa (recomendada para configuraciones siempre activas) reside en la raíz del repositorio como
AGENTS.md.template; cópiala enAGENTS.mdpara que la regla principal se cargue en cada sesión. Este skill es la referencia bajo demanda.
La regla principal
Los skills de flujo de trabajo (qué hacer) tienen prioridad sobre los skills de modo (cómo hablar/escribir) en la misma tarea. El skill de modo se adapta; el skill de flujo de trabajo nunca se debilita.
Todo lo demás es una aplicación de esta regla. Si un caso específico no está listado, aplica la regla principal y dilo.
Arbitraje entre skills de flujo de trabajo
Dos o más skills de flujo de trabajo pueden coincir de manera plausible con la misma tarea. Elige según esta escalera, en orden:
- La intención explícita gana. Si el usuario nombró el tipo de tarea (revisión, prueba, diseño, plan...), el skill para ese tipo lidera. Sin discusión.
- El alcance decide. Un cambio único (un diff, una función, un archivo) requiere el skill más ligero y barato; un cambio transversal (arquitectura, refactorización multiarchivo, nuevo sistema) requiere el skill más profundo.
- Orden del ciclo de vida. Planificación → construcción → verificación es la secuencia predeterminada. Cuando los skills son fases de un mismo esfuerzo (diseño, luego implementación, luego revisión), ejecútalos en ese orden en lugar de elegir uno.
- Componer antes que elegir. Si dos skills son fases secuenciales, ejecuta ambos en orden y declara el orden explícitamente ("tdd primero, luego revisión").
- ¿Aún ambiguo? Pregunta. Da una recomendación de una línea y deja que el usuario elija. Nunca elijas un skill de flujo de trabajo en silencio; el equivocado desperdicia toda una tarea, no una respuesta.
Taxonomía de skills
Clasifica cada skill instalado antes de arbitrar:
- Skills de flujo de trabajo — dictan qué se hace: revisión, prueba, diseño, investigación, escritura, refactorización, planificación. Producen entregables.
- Skills de modo — dictan cómo suena el agente o cuánto escribe: compresión, verbosidad, estilo, brevedad. No producen nada por sí mismos.
- Skills de enrutador — eligen qué flujo de trabajo ejecutar (opcional). Nunca deben ser anulados por un skill de modo.
Si un skill de modo alteraría el entregable de un skill de flujo de trabajo (informe, documento, mensaje de commit, cuerpo de PR), el skill de modo cede. Si un skill de flujo de trabajo y un skill de modo se activan y la salida del skill de flujo de trabajo es el entregable, el skill de modo cede.
Esta carta tiene prioridad sobre las autodescripciones de los skills. El frontmatter de un skill puede reclamar activación automática en una frase amplia (por ejemplo, "se activa automáticamente en revisión"). Tales afirmaciones son reemplazadas aquí: el enrutamiento sigue la desambiguación de esta carta, no la afirmación de activación del propio skill. Si un skill reclama una activación que esta carta asigna en otro lugar, la carta gana.
Matriz de prioridad (completa tus propios skills)
Reemplaza los nombres de skill de ejemplo a continuación con los skills realmente instalados en tu entorno. Las filas están ordenadas por la frecuencia con la que aparece el conflicto en la práctica.
| Tarea | Lidera (flujo de trabajo) | Cede | Comportamiento |
|---|---|---|---|
| Diseño de UI / pulido / crítica visual | ej. tu skill de diseño | ej. tu skill de código mínimo | El diseño lidera; código mínimo con intensidad reducida (sin inflado, pero sin veto YAGNI sobre la artesanía del diseño) |
| Revisión de código profunda (estándares + especificaciones) | ej. tu skill de revisión completa | ej. tu skill de compresión | Informe completo en prosa normal; compresión desactivada a menos que el usuario solicite comentarios concisos |
| Auditoría de sobreingeniería | ej. tu skill de revisión centrada en eliminación | ej. tu skill de revisión completa | Pase de un solo eje, centrado en eliminación; omitir el informe completo |
| Comentarios rápidos y concisos de PR | ej. tu skill de comentarios concisos | — | Solo cuando el usuario haya solicitado explícitamente comentarios comprimidos |
| Prueba de estrés de un plan/idea | ej. tu skill de entrevista/interrogatorio | ej. tu skill de compresión | Entrevista en prosa normal; un interrogatorio comprimido pierde profundidad |
| Construcción de funcionalidad primero con pruebas | ej. tu skill de TDD + tu skill de código mínimo | — | Combinación: las pruebas son validación, nunca se eliminan; implementación mínima que pasa rojo-verde |
| Diseño de módulo/API | ej. tu skill de documentos de diseño | ej. tu skill de código mínimo | Fase de diseño: gana la profundidad. Fase de implementación: se aplica la escalera de código mínimo |
| Escritura / edición / enseñanza | ej. tu skill de escritura | ej. tu skill de compresión | Se requiere expresión completa; compresión desactivada |
| Investigación / captura de documentación | ej. tu skill de investigación | ej. tu skill de compresión | Los archivos de salida son entregables; la compresión afecta solo al chat, nunca al contenido de los archivos |
| Cualquier tarea de codificación, sin otro skill activado | ej. tu skill de código mínimo | ej. tu skill de compresión | Código mínimo a plena potencia; compresión solo bajo demanda (su costo de entrada por turno a menudo supera el ahorro en trabajos pesados de código) |
Desambiguación de activadores
Cuando varios skills comparten una palabra de activación, enruta por intención, no por qué skill coincidió primero:
- "revisa esto" → revisión completa por defecto. La revisión centrada en eliminación solo si el usuario dice "sobreingeniería" / "demasiado código". La revisión de comentarios concisos solo si el usuario solicita comentarios comprimidos.
- "interroga" / "entrevístame" → la variante con estado (deja un rastro documental) cuando existe un código base; la variante sin estado cuando es independiente; la variante por lotes cuando el usuario quiere todas las preguntas a la vez.
- "traspaso" → la variante de redacción de documentos por defecto; la variante de agente en segundo plano solo cuando el usuario quiere un agente en segundo plano inmediato.
- "haz un plan/especificaciones/tickets" → enruta por tipo de artefacto: especificaciones, tickets, PRD, incidencias, cuestionario.
Disciplina de skills de modo
- Un skill de modo nunca silencia el entregable de un skill de flujo de trabajo. Puede comprimir solo la prosa del chat. Los informes, archivos, mensajes de commit y cuerpos de PR escritos por skills de flujo de trabajo se mantienen completos.
- La línea de validación del skill de código mínimo tiene tres niveles: (1) La validación real se mantiene: validación de entrada, manejo de errores para dependencias externas, seguridad, accesibilidad — nunca se elimina. (2) La defensa especulativa está en alcance: comprobaciones que no pueden activarse, envoltorios defensivos para "qué pasaría si" — elimínalos, ese es el trabajo del skill de código mínimo. (3) Las pruebas y la documentación de la tarea siguen los requisitos explícitos del usuario: el skill de código mínimo nunca usa YAGNI para eliminar pruebas o documentación que el usuario requiere — pero la redundancia dentro de las pruebas, el exceso de mocking y la hinchazón en la documentación siguen siendo válidos.
- Dos skills de modo activándose juntos (compresión + código mínimo): código mínimo gobierna el código, compresión gobierna el chat — pero solo si la sesión es pesada en prosa; en sesiones pesadas en código, la compresión debería estar desactivada o con intensidad reducida (de lo contrario, pérdida neta de tokens).
- Los subagentes heredan el arbitraje. Al generar un subagente para una tarea de revisión o investigación, indica el modo explícitamente en la tarea: "prosa normal" o "salida comprimida". Nunca lo dejes implícito.
Combinaciones que valen la pena
- Skill de TDD + skill de código mínimo — pruebas primero, implementación mínima.
- Revisión completa, luego revisión centrada en eliminación sobre el mismo diff — pase completo, luego un pase de eliminación.
- Skill de entrevista + skill de compresión de memoria — comprime las notas de la sesión acumuladas después de la entrevista.
- Skill de mensajes de commit concisos después de que cualquier skill de flujo de trabajo termine — siempre seguro.
- Skill de enrutador para el enrutamiento del flujo, este skill para el arbitraje de modo — el enrutador elige el camino, la sinergia elige la marcha.
Personalización
Este skill es un marco, no una configuración. Para hacerlo tuyo:
- Reemplaza cada "ej. tu skill X" en la matriz de prioridad con los nombres reales de los skills en tu entorno. Una referencia completa que utiliza skills públicos comunes reside en
examples/example-config.md— cópiala y sustituye tus propios nombres en lugar de llenar la plantilla desde cero. - Elimina las filas para tipos de tarea que nunca encuentres.
- Si tu entorno tiene un archivo de reglas global (AGENTS.md o equivalente), copia la regla principal en él para que cada entorno la cargue.
- Si aparece un nuevo conflicto que no está cubierto, clasifica ambos skills (flujo de trabajo o modo), aplica la regla principal y agrega una fila.