Introducción
Cuando trabajas con agentes como Claude Code o Codex, el problema no siempre es que el modelo “no sepa programar”. Muchas veces el problema real es que gastamos demasiados tokens explicando lo mismo, corrigiendo malentendidos o pidiendo cambios que pudieron haberse definido mejor desde el inicio.
Los Skills ayudan a resolver este problema porque convierten patrones repetitivos de trabajo en instrucciones reutilizables. En lugar de escribir cada vez un prompt largo como: “respóndeme más corto, hazme preguntas antes de programar, usa TDD, no cambies cosas innecesarias…”, puedes invocar una Skill y dejar que el agente siga una metodología específica.
El repositorio de Matt Pocock define estos Skills como herramientas pequeñas, adaptables y componibles para Claude Code, Codex y otros agentes de programación. El objetivo de este artículo es simple: usar menos tokens sin perder calidad técnica.
Resumen rápido
Ahorrar tokens no significa pedir menos calidad. Significa reducir ambigüedad, evitar retrabajo y usar instrucciones reutilizables para que el agente avance con menos conversación innecesaria.
1. Caveman: la Skill para cortar el desperdicio verbal
Caveman es probablemente la Skill más directa para ahorrar tokens. Su propósito es activar un modo de comunicación ultra comprimido, eliminando relleno, artículos, saludos, explicaciones largas y frases innecesarias, pero manteniendo la precisión técnica.
En la propia descripción de la Skill se menciona que puede reducir el uso de tokens aproximadamente 75%, especialmente cuando se usa para seguimiento técnico, debugging puntual o respuestas operativas.
Cuándo usar Caveman
Úsala cuando ya sabes qué necesitas y solo quieres respuestas compactas:
/caveman
Revisa este error y dame solo:
- causa probable
- archivo a modificar
- cambio exacto
- comando para validar
En Codex también puedes pedirlo de forma directa:
Use caveman mode. Be terse. No explanations unless needed.
Find why this test fails and return minimal fix.
Por qué ahorra tokens
Sin Caveman, el agente puede responder algo como:
Claro, el problema parece estar relacionado con la forma en que se está validando el token dentro del middleware de autenticación. Probablemente la condición no está considerando correctamente la expiración…
Con Caveman, la respuesta debería parecerse más a:
Bug auth middleware. Expiry check wrong. Uses < instead <=. Fix:
Menos texto. Menos vueltas. Menos costo.
Mejor uso práctico
Activa Caveman después de la fase de análisis o planeación. No lo uses desde el primer mensaje si todavía necesitas explorar requisitos complejos, porque demasiada compresión al inicio puede causar malentendidos.
2. Grill-me: gastar tokens antes para no desperdiciarlos después
Grill-me funciona al revés de Caveman. No busca responder más corto inmediatamente, sino evitar que el agente programe con supuestos incorrectos. Esta Skill hace que el agente te entreviste de forma insistente sobre un plan o diseño hasta que exista entendimiento compartido.
Cuándo usar Grill-me
Úsala antes de construir algo grande:
/grill-me
Quiero agregar login con roles admin, supervisor y operador.
Gríllame antes de escribir código.
El agente debería preguntar cosas como:
- ¿Qué acciones exactas puede hacer cada rol?
- ¿El login será local, OAuth, LDAP o SSO?
- ¿La sesión expira por tiempo, cierre de navegador o logout manual?
- ¿Qué pasa si un operador intenta abrir una pantalla de admin?
Por qué ahorra tokens
Sin Grill-me, el flujo típico suele ser:
Prompt inicial → código incorrecto → corrección → otro cambio → bug → nueva explicación → refactor.
Con Grill-me, el flujo mejora:
Preguntas → decisiones claras → implementación más pequeña → menos retrabajo.
Aunque gastes más tokens al inicio, reduces tokens de corrección, debugging y cambios innecesarios.
3. TDD: menos tokens porque el agente recibe feedback automático
La Skill TDD guía al agente con el ciclo red-green-refactor: primero escribe una prueba que falla, luego implementa lo mínimo para pasarla y finalmente refactoriza. Esta Skill enfatiza pruebas de comportamiento mediante interfaces públicas, no pruebas acopladas a detalles internos.
Prompt recomendado
/tdd
Implementa validación de órdenes de producción.
Reglas:
- Si el número de parte está activo, permitir continuar.
- Si está inactivo, bloquear.
- Si no existe, mostrar error claro.
Primero escribe una prueba de comportamiento.
Luego implementa solo lo mínimo.
No refactorices hasta que todo esté verde.
Por qué TDD ahorra tokens
Cuando no hay pruebas, el agente depende demasiado de tus explicaciones:
- “No, eso no era.”
- “Sigue fallando.”
- “Ahora rompiste otra pantalla.”
- “Ese método no se usa así.”
Con TDD, el agente tiene feedback directo:
Test falla → fix → test pasa → siguiente comportamiento.
Eso reduce conversaciones largas porque el propio entorno valida si el cambio funciona.
Regla importante
No le pidas al agente que escriba 20 pruebas antes de implementar. La Skill TDD recomienda trabajar en vertical slices: una prueba, una implementación y repetir. Es mejor para ahorrar tokens porque evita diseñar pruebas para comportamientos imaginados.
4. Grill-with-docs: documentar lenguaje del proyecto para no repetir contexto
Además de Grill-me, una Skill muy útil es grill-with-docs. Según el README del repositorio, esta variante ayuda a construir lenguaje compartido con la IA y documentar decisiones difíciles en archivos como CONTEXT.md y ADRs.
Por qué sirve para ahorrar tokens
Cada proyecto tiene palabras internas. Por ejemplo:
- WO
- PN
- RMA
- NCR
- SCAR
- QI
- FPY
- Station result
- Serial traceability
Si cada vez explicas qué significa cada término, quemas tokens. En cambio, puedes crear un archivo CONTEXT.md con un glosario del proyecto:
# CONTEXT.md
## Domain language
- WO: Work Order used to identify production order.
- PN: Part Number.
- FPY: First Pass Yield calculated by station result.
- NCR: Non-Conformance Report.
- QI: Quality Inspection hold area.
Después de documentarlo, el agente puede usar ese lenguaje sin pedirte explicación cada vez.
Prompt recomendado
/grill-with-docs
Ayúdame a documentar el lenguaje del proyecto en CONTEXT.md.
Quiero que Claude/Codex entienda mis términos de manufactura, calidad y trazabilidad.
Hazme preguntas solo sobre términos ambiguos.
5. Diagnose: no dejes que el agente adivine bugs
Otra Skill útil es Diagnose, pensada para seguir un ciclo disciplinado de debugging: reproducir, minimizar, formular hipótesis, instrumentar, corregir y agregar prueba de regresión. Es especialmente útil para bugs difíciles, fallas intermitentes o regresiones de rendimiento.
Prompt recomendado
/diagnose
Tengo este error en producción.
No propongas fix todavía.
Primero:
- reproduce mentalmente el flujo
- identifica punto exacto de falla
- lista 3 hipótesis
- dime qué logs o comandos necesito correr
Por qué ahorra tokens
Cuando el agente adivina, normalmente genera cambios grandes. Eso cuesta tokens y puede romper más cosas. Con Diagnose, obligas al agente a reducir el problema antes de tocar código.
Mal uso
Arregla este error.
Mejor uso
Diagnostica primero. No modifiques código hasta tener causa raíz probable.
6. Handoff: compactar contexto para continuar sin arrastrar todo el chat
La Skill Handoff sirve para convertir una conversación larga en un documento compacto para que otro agente pueda continuar el trabajo. Es ideal cuando el chat ya tiene demasiada información acumulada y empieza a ser costoso seguir cargando todo el historial.
Cuándo usarla
Úsala cuando el chat ya está muy largo:
/handoff
Resume este trabajo para continuar en otro chat.
Incluye:
- objetivo
- decisiones tomadas
- archivos modificados
- errores pendientes
- comandos usados
- siguiente paso recomendado
En vez de pegar 80 mensajes anteriores, generas un resumen operativo de una o dos páginas. Eso reduce costo y mejora continuidad.
7. Zoom-out: pedir contexto general antes de hacer cambios locales
La Skill Zoom-out hace que el agente explique una parte del código dentro del contexto del sistema completo. Es útil cuando Claude o Codex se enfocan demasiado en una función y pierden de vista el flujo general.
Prompt recomendado
/zoom-out
Antes de modificar este método, explícame:
- qué papel cumple en el sistema
- qué módulos dependen de él
- qué riesgo hay si lo cambiamos
- cuál sería el cambio mínimo seguro
Un buen zoom-out puede prevenir muchos mensajes de corrección después, porque evita cambios innecesarios en archivos equivocados o funciones críticas.
8. To-issues: dividir trabajo grande en tareas pequeñas
La Skill To-issues convierte planes o PRDs en issues independientes mediante vertical slices. Esto es útil porque los agentes funcionan mejor con tareas pequeñas, cerradas y verificables.
Prompt recomendado
/to-issues
Convierte este plan en issues pequeños.
Cada issue debe tener:
- objetivo
- alcance
- archivos probables
- criterio de aceptación
- prueba sugerida
Por qué ahorra tokens
Una tarea enorme genera respuestas enormes. Una tarea pequeña genera cambios pequeños.
Mal prompt
Haz todo el sistema de usuarios.
Mejor prompt
Crea solo el issue para validar login con usuario activo.
9. Setup-pre-commit: ahorrar tokens evitando errores tontos
La Skill Setup-pre-commit ayuda a configurar hooks como Husky, lint-staged, Prettier, type checking y tests antes de los commits.
Por qué ahorra tokens
Si el agente genera código con formato incorrecto, imports rotos o errores de tipo, tú terminas gastando tokens en correcciones menores. Con pre-commit, el sistema detecta fallas mecánicas antes de que el cambio avance.
Format → lint → typecheck → tests.
Prompt recomendado
/setup-pre-commit
Configura validaciones antes de commit:
- format
- lint
- typecheck
- tests
No cambies reglas existentes sin explicarme.
Flujo recomendado para ahorrar tokens
| Escenario | Flujo sugerido | Objetivo |
|---|---|---|
| Feature nueva | /grill-me → /to-prd o /to-issues → /tdd → /caveman → /handoff | Aclarar requisitos, dividir alcance, implementar con pruebas y compactar seguimiento. |
| Bug | /diagnose → /tdd → fix mínimo → /caveman | Encontrar causa raíz, agregar prueba de regresión y evitar cambios grandes. |
| Proyecto grande o legacy | /zoom-out → /grill-with-docs → CONTEXT.md → /improve-codebase-architecture → /to-issues | Entender arquitectura, documentar lenguaje y reducir riesgo antes de modificar código. |
Prompt maestro para Claude o Codex
Puedes usar este prompt como base para trabajar con menos ruido y mayor control:
Quiero ahorrar tokens y evitar retrabajo.
Reglas:
- Usa lenguaje técnico directo.
- No expliques lo obvio.
- Pregunta antes de implementar si hay ambigüedad.
- Prefiere cambios pequeños y verificables.
- Usa TDD cuando haya lógica crítica.
- No refactorices mientras los tests estén fallando.
- Si el problema es un bug, diagnostica antes de corregir.
- Si el chat crece mucho, genera handoff compacto.
Skills preferidas:
- caveman para respuestas cortas
- grill-me para aclarar planes
- tdd para implementar con pruebas
- diagnose para bugs
- handoff para resumir contexto
- zoom-out para entender arquitectura
Ejemplo completo de uso
Supongamos que quieres agregar una validación en una app de producción.
Prompt 1: Alinear
/grill-me
Quiero agregar validación para que una orden de producción solo pueda avanzar si:
- el PN existe
- el PN está activo
- la estación corresponde al flujo correcto
Hazme preguntas antes de escribir código.
Prompt 2: Convertir a tareas
/to-issues
Divide esta validación en issues pequeños.
Cada issue debe poder probarse de forma independiente.
Prompt 3: Implementar con pruebas
/tdd
Implementa el primer issue.
Primero escribe una prueba de comportamiento.
Luego implementa lo mínimo para pasar.
No agregues features no solicitadas.
Prompt 4: Compactar respuestas
/caveman
Desde ahora responde corto:
- archivo
- cambio
- prueba
- resultado
Errores comunes que desperdician tokens
| Error | Mal ejemplo | Mejor ejemplo |
|---|---|---|
| Pedir “hazlo todo” | Haz todo el módulo de usuarios. | Implementa solo validación de usuario activo al hacer login. |
| No definir criterio de aceptación | Arregla el FPY. | El FPY debe calcularse con 6 pruebas anteriores. Los defectos cosméticos deben sumarse como falla si ocurren antes de empaque. Dame fórmula y validación con ejemplo. |
| Permitir refactor sin control | Mejora este código. | No refactorices arquitectura. Solo corrige el bug. Mantén firmas públicas. |
| No usar contexto persistente | Te explico otra vez qué significa RMA… | Actualiza CONTEXT.md con este glosario y úsalo en futuras tareas. |
Combinación recomendada de Skills
Grill-me
Para entender bien antes de programar.
TDD
Para validar con pruebas y reducir conversación manual.
Caveman
Para reducir ruido y recibir respuestas compactas.
Diagnose
Para no adivinar bugs y encontrar causa raíz.
Handoff
Para no cargar chats eternos.
CONTEXT.md
Para no repetir lenguaje del proyecto.
Conclusión
Ahorrar tokens no significa escribir prompts más pobres. Significa diseñar mejor la conversación.
Claude y Codex trabajan mejor cuando el proceso está claro. Si reduces ambigüedad, reduces retrabajo. Si reduces retrabajo, ahorras tokens. Y si además usas Skills como Caveman, TDD y Grill-me, conviertes al agente en una herramienta mucho más precisa, barata y controlable.
La clave no está en hablar más con la IA, sino en hablarle mejor: con contexto claro, criterios verificables, tareas pequeñas y ciclos de validación.
