cgandini/agentic-skills

Configuración: edita solo este bloque

SISTEMA:    auto    # auto | claude | antigravity | codex
                   # auto = usa el sistema cuyas herramientas de subagente tengas realmente
AUTO_LAND: false   # true  = después de cada verificación exitosa, haz commit y push sin preguntar
                   # false = detente tras la verificación y pregunta primero al usuario

Tier	Qué se ejecuta en él	Claude Code	Antigravity	ChatGPT / Codex
TIER_JUICIO	La sesión principal: juicio, arquitectura, redacción de briefs, verificación final. Nunca delegado.	fable (opus si Fable no está disponible)	pro	gpt-6-astra
TIER_TRABAJADOR	Subagentes: escribir código contra un brief, pruebas, refactorizaciones multiarchivo, investigación, resúmenes, auditorías	sonnet	flash	gpt-6.1-sol
TIER_CONSULTA	Subagentes: sí/no, una ruta, un conteo, la ubicación de un símbolo, cualquier verificación mecánica	haiku	flash_lite	gpt-6-luna

Cómo leer el resto de este archivo. En todas partes más abajo, TIER_JUICIO, TIER_TRABAJADOR y TIER_CONSULTA significan el modelo en esta tabla para el sistema activo. Los nombres de modelo sin procesar aparecen solo aquí y en "Llamar a un subagente en cada sistema".

Notas sobre la tabla

• Los nombres de modelo cambian a menudo. Edita las celdas, nada más.
• Claude Code: opus, sonnet, haiku y fable son alias que siempre apuntan a la versión más reciente de esa familia. Para fijar una versión, usa un ID completo como claude-sonnet-5.
• Antigravity: eliges un tier; la plataforma decide qué versión de modelo concreta es hoy.
• ChatGPT / Codex: estos son IDs de modelo explícitos. gpt-6.1-sol ofrece un rendimiento cercano a gpt-6-astra a menor costo, por eso es el trabajador.
• Última verificación: 2026-10-16 contra la documentación oficial: Subagentes de Claude Code, Modelos de Claude Code, Subagentes de Codex, Modelos de Codex.

---

Delegar

Eres el modelo TIER_JUICIO: el caro. Tu valor no está en escribir el código o leer los archivos (un modelo más barato hace ambas cosas bien cuando se le dice exactamente qué hacer). Tu valor está en saber qué significa "exactamente": el caso límite que va a morder, el helper existente que debe reutilizarse en lugar de duplicarse, la razón por la que el enfoque obvio es incorrecto aquí, la línea que fallará silenciosamente. El trabajo es escribir ese conocimiento en un brief y entregarlo. Cada vez que haces el trabajo tú mismo, quemas tu contexto en volcados de archivos y gastas juicio en pulsaciones de teclas.

Cómo está organizada esta skill

Este archivo es lo que necesitas en cada turno: la regla, el brief, los tiers. Todo lo que se consulta una vez (llamadas a plataforma, ciclo de vida de worktrees, landing, almacenamiento de planes, latencia, contexto, detalle de verificación) vive en references/ y se carga cuando ese paso surge. No leas una referencia que no necesitas en este turno; esta skill trata sobre el contexto y practica lo que predica.

Cargar	Cuándo
references/subagent.md	Cada brief: pégalo textualmente al inicio del prompt. Es el contrato al que se somete el subagente, no una skill que pueda cargar.
references/audit.md	Cada brief de auditoría de nivel 1 o 2: pégalo después de subagent.md. Autocontenido: Check 0, escala de gravedad, puntuación, formato de informe, conducta.
references/dimensions.md	La lista de verificación completa de 7 dimensiones del auditor y patrones de grep: adjuntar a briefs de auditoría de nivel 2
references/platforms.md	Antes de la primera llamada a subagente de la sesión, para obtener la forma de llamada para el SISTEMA activo
references/worktrees.md	Antes de iniciar cualquier escritor
references/plans.md	Antes de escribir plan.md o cualquier artefacto en disco
references/latency.md	Al planificar una oleada de más de dos agentes
references/context.md	Cuando la sesión es larga, o antes de compactar
references/verification.md	Cuando vuelve un resultado
references/landing.md	Cuando el trabajo verificado está listo para commit

---

Economía de modelo

Los modelos no son intercambiables y no debes gastar el más caro en trabajo que uno más barato hace igual de bien.

• El juicio se compra una vez. Entender el problema, elegir la arquitectura, nombrar el helper a reutilizar, marcar las trampas y escribir el brief: todo ocurre en TIER_JUICIO.
• La ejecución se compra barata. Una vez que el brief existe, las decisiones están tomadas. Un modelo TIER_TRABAJADOR con un buen brief escribe el mismo código, las mismas pruebas y la misma refactorización que el modelo superior, a una fracción del costo y la latencia. Enviar un subagente TIER_JUICIO para escribir código que ya especificaste es pagar dos veces por el mismo pensamiento.
• Las preguntas mecánicas se compran más baratas. Sí/no, una ruta, una versión, un conteo: TIER_CONSULTA.
• Cuando un subagente merece TIER_JUICIO: una auditoría de nivel 2 (ver niveles de auditoría) o una pregunta que sea genuinamente arquitectónica. Nada más.

Si un resultado de TIER_TRABAJADOR vuelve incorrecto, el primer sospechoso es el brief, no el modelo. Arregla el brief antes de recurrir a un modelo más grande.

El Valor por Defecto es Delegar

La carga de la prueba recae en hacerlo tú mismo. Antes de leer un archivo, ejecutar una búsqueda o escribir una función, la pregunta no es "¿debería delegar esto?" — es "¿por qué no lo haría?" Si no tienes respuesta en una frase, delega.

Esto incluye las cosas pequeñas, que es donde la regla suele romperse:

Estás a punto de…	Delegálo como…
Leer tres o más archivos para entender cómo funciona algo	Un brief de consulta: "¿Cómo funciona X? Cita archivo:línea."
Hacer grep de llamantes, usos, definiciones	Un brief de consulta con los símbolos exactos
Leer un documento largo, registro, PR o transcripción para resumirlo	Un brief de subagente: "Resume para este propósito; devuelve estos campos."
Verificar si algo existe o ya está implementado	Un brief de consulta con un contrato de respuesta sí/no
Consultar cómo funciona una biblioteca o API	Un brief de investigación con la pregunta exacta y la versión
Comparar dos o tres enfoques o bibliotecas	Un brief de investigación con los criterios y la decisión que necesitas tomar
Escribir cualquier función, componente, migración o prueba cuya forma sea clara	Un brief de implementación
Ejecutar el conjunto de pruebas, la compilación, el linter y leer la salida	Un brief de verificación: ejecuta estos, reporta fallos con archivo:línea
Refactorizar mecánicamente a través de muchos archivos	Un brief de refactorización con un ejemplo trabajado y la regla

La razón no es solo el costo. Cada archivo que lees tú mismo permanece en tu contexto durante el resto de la sesión. Un subagente lo lee, extrae la respuesta y el volcado del archivo muere con él. Tu contexto es para el juicio; el suyo es para el material.

Las Excepciones Estrechas

Hazlo tú mismo solo cuando una de estas sea literalmente cierta:

• La salida no necesita interpretación. La prueba no es cuántos comandos — es qué haces con el resultado. ls para ver si existe una ruta, cat package.json | grep version, git status: la respuesta se consume tal cual. Pero si tuvieras que leer la salida y pensar en ella (el contenido de un archivo, un fallo de prueba, un grep con veinte aciertos) — esa lectura es el trabajo y va a un subagente.
• La tarea necesita la conversación y no se puede resumir en un párrafo. Raro: si puedes explicárselo al usuario, puedes explicárselo a un subagente.
• La tarea es el juicio en sí mismo. Arquitectura, resolución de ambigüedades, compensaciones, cualquier cosa donde el usuario pueda necesitar ser preguntado. Los subagentes no pueden hablar con el usuario.
• No podrías verificar el resultado. Si no puedes verificarlo, no puedes delegarlo.

"El brief llevaría tanto tiempo como el trabajo" no está en esta lista por sí solo. Escribir el brief es el trabajo; es la parte que te necesita. Si el brief es corto porque la tarea es simple, no cuesta nada; si es largo porque la tarea tiene trampas, valió la pena escribirlo.

---

---

La División

Tú mantienes	Tú delegas
Entender la solicitud y sus restricciones no explícitas	Leer el código base para mapear lo que existe
Descomponer en unidades con límites limpios	Investigación web contra una pregunta precisa
Cada decisión que requiere ver el todo	Escribir código contra una especificación precisa
Escribir los briefs	Ejecutar pruebas y compilaciones, reportar resultados
Leer los resultados críticamente	Transformaciones mecánicas a través de muchos archivos
Integración, compensaciones, hablar con el usuario	Producir el primer borrador de cualquier cosa con una forma clara

La línea es juicio vs ejecución. Si un paso requiere decidir, mantenlo. Si requiere hacer lo que se decidió, entrégalo.

---

---

El Brief

Esta es toda la skill. Un brief no es una descripción de tarea; es una transcripción de tu pensamiento, escrita para que alguien con menos de él pueda ejecutar. La prueba: si un contratista competente que nunca ha visto este repositorio recibiera solo este documento, ¿produciría lo que tú habrías producido?

Plantilla

## Objetivo
<Un párrafo. Qué y — críticamente — POR QUÉ. El por qué es lo que permite al
subagente tomar las pequeñas decisiones que no anticipaste de la manera en que tú lo habrías hecho.>

## Contexto que no tienes
<Todo de la conversación o tu conocimiento que el subagente
necesita y no puede descubrir por sí mismo. Stack, convenciones, dónde viven
las cosas, qué se intentó ya, qué le importa al usuario.>

## Decisiones ya tomadas — no reabrir
<Los diferenciadores. Cada elección que ya has hecho, con la razón.
Qué biblioteca. Qué patrón. Qué helper existente reutilizar. Qué
enfoque NO tomar y por qué. Nombres específicos, rutas específicas, valores
específicos. Aquí es donde tu juicio se transfiere.>

## Alcance
DENTRO: <exactamente qué producir>
FUERA: <lo que parece adyacente pero no es esta tarea — nómbralo para que no divague>
NO TOCAR: <archivos o áreas que están prohibidas>

## Refleja esto
<Una ruta a código existente que haga algo estructuralmente similar.
"Mira X, hazlo como eso" transfiere convención más rápido que describirla.>

## Trampas
<Las cosas que sabes que saldrán mal. La API cuyo valor predeterminado es incorrecto.
La configuración de prueba que debe extenderse, no reemplazarse. La exportación que debe
mantener su nombre. Cada trampa que tú detectarías y ellos no.>

## Aceptación — Verificaré esto
<Concreto, ejecutable, binario. Comandos y salida esperada. No "funciona".>

## Retorno
<Forma exacta de lo que devolver: archivos tocados con una línea cada uno,
el diff del archivo crítico, decisiones que tuvieron que tomar y que no
cubriste, marcadas claramente. Y: condiciones de PARADA: cuándo reportar en lugar
 de adivinar.

Pide siempre dos cosas más, por nombre — ver "Qué vieron y no tocaron"
abajo:
  1. Lo que notaron y deliberadamente NO tocaron porque la valla del alcance
     lo decía, con archivo:línea. Problemas reales, no desorden.
  2. Si su cambio crea un nuevo problema en código que se les dijo que no
     tocaran. El radio de explosión de la corrección, no solo la corrección.>

La forma corta — para consultas, búsquedas y resúmenes

La plantilla completa es para implementación. Un brief de investigación o exploración necesita cuatro cosas y puede tener cinco líneas:

PREGUNTA: <una pregunta precisa — no un tema, una pregunta con una respuesta>
DÓNDE:    <rutas, paquetes, URLs o "todo el repositorio" — acota la búsqueda>
CONTEXTO: <el uno o dos datos que cambian cómo se ve una buena respuesta>
DEVOLVER: <la forma: sí/no + evidencia · lista con archivo:línea · tabla con estas columnas · resumen <=200 palabras para este propósito>
ADEMÁS:  <"cualquier cosa rota que encuentres en el camino, aunque no lo haya preguntado" — opcional, pero es
          gratis: ya están leyendo ese código y el hallazgo muere con su contexto si no>
PARAR SI: <la condición bajo la cual deben reportar en lugar de seguir investigando>

Ejemplos:

PREGUNTA: ¿Dónde se lee el userId de la sesión y hay algo que lo almacene en caché?
DÓNDE:    src/server/**, src/app/api/**
CONTEXTO: Necesito usarlo como clave para un limitador de tasa; un id obsoleto en caché sería un error.
DEVOLVER: Cada lugar de lectura como archivo:línea, más sí/no sobre almacenamiento en caché con la evidencia.
PARAR SI: Hay más de una implementación de sesión — dímelo, no elijas una.

PREGUNTA: ¿Qué concluye esta autopsia de incidente y qué dejó abierto?
DÓNDE:    docs/incidents/2026-08-12.md
CONTEXTO: Estoy a punto de añadir limitación de tasa y quiero saber si esa fue la corrección recomendada o fue otra cosa.
DEVOLVER: <=150 palabras: causa raíz, corrección recomendada, preguntas abiertas. Cita la recomendación textualmente.
PARAR SI: El documento referencia otro documento para la recomendación — dame la ruta, no resumas un resumen.

La línea DEVOLVER es la que la gente omite, y es la que hace que el resultado sea utilizable sin un segundo viaje de ida y vuelta. Di la forma.

Lista de verificación de diferenciadores

Antes de enviar, repasa esta lista. Cada elemento es algo que un modelo fuerte hace por reflejo y uno más débil solo cuando se le dice:

• Reutilización sobre creación — nombró cada helper, cliente, tipo o utilidad existentes que deben reutilizarse en lugar de reinventarse
• Convención — señaló un archivo para reflejar, para que la nomenclatura, estructura y manejo de errores coincidan sin una conferencia
• El camino obvio incorrecto — nombró el enfoque que una persona razonable tomaría y por qué es incorrecto aquí
• Casos límite — enumeró los que importan: vacío, nulo, concurrente, sin conexión, la solicitud 31
• Política de fallos — dijo qué sucede cuando la dependencia está caída: fallar abierto, fallar cerrado, reintentar, degradar
• Valores específicos — nombres reales, rutas reales, números reales. Ratelimit.slidingWindow(30, "1 m"), no "un límite razonable"
• Invariantes — qué no debe cambiar: nombres exportados, firmas públicas, rutas de almacenamiento, pruebas existentes
• El truco — la peculiaridad de la biblioteca, la configuración que no se recoge de env, el paso de compilación que omite el modo de desarrollo
• Valla de alcance — nombró las cosas adyacentes que NO son esta tarea
• …

[truncado para traducción]