Claude cambió. 15 comandos para dominar

El modelo ya escribe bien, organiza la información y evita el texto robótico sin recetas. Una skill larga repite lo que ya sabe y ocupa contexto. Solo debe guardar lo que hace mal y el conocimiento que solo tú tienes.

1. Haz la tarea sin ninguna skill, en una sesión limpia.
2. Anota solo lo que salió mal o fue distinto de cómo lo haces tú.
3. La skill se convierte en esta lista: correcciones, nombres, rutas y excepciones de tu negocio.
4. Revísala cada vez que cambies de modelo: quita de la skill lo que ahora hace bien.

Una buena skill mejora el resultado. La comparación es sencilla: la misma tarea con la skill y sin ella. Si no mejora, recórtala o elimínala.

1. Escribe de 3 a 5 casos reales de la tarea e indica qué cuenta como un buen resultado.
2. Ejecuta la misma tarea con la skill y sin ella (la evaluación del plugin ya se encarga de la versión «sin»).
3. Compara la puntuación: si baja o empata, recorta líneas; si sigue empatando, elimínala.
4. Guarda los casos: serán la prueba de la próxima versión de la skill.

En vez de escribir la skill, haces la tarea una vez y el agente observa. Como solo registra lo que no podría saber por sí mismo, la skill queda breve.

1. En la aplicación de escritorio, usa la grabación de skills y haz la tarea como siempre.
2. Si no tienes esa función: haz la tarea con el agente y al final pídele «enumera solo lo que tuve que corregir».
3. Lee la skill generada y quita lo obvio.
4. Sigue el consejo 2 antes de adoptarla.

Cada modelo guarda su propia caché de la conversación. Cambiar a mitad de camino obliga a volver a leer todo el historial, sin descuento, y otra vez al regresar. Un modelo más pequeño también puede necesitar más intentos: que sea barato por token no significa que sea barato por tarea.

1. Elige el modelo al empezar el trabajo y quédate con él.
2. ¿Una pregunta fácil a mitad de camino? Pide «una respuesta rápida, sin pensarlo demasiado» en vez de cambiar de modelo.
3. ¿Necesitas otro modelo? Abre otra sesión para esa tarea.
4. Vigila el consumo con /context y /usage.

En vez de cambiar a un modelo inferior, baja el nivel de esfuerzo. Un esfuerzo alto no siempre es mejor: el modelo puede pensar demasiado y gastar de más.

1. Deja el esfuerzo predeterminado para la mayor parte del trabajo.
2. Tarea sencilla y repetitiva: esfuerzo bajo.
3. Súbelo solo cuando un problema difícil te atasque y luego vuelve a bajarlo.
4. Para toda la sesión: claude --effort low|medium|high.

Un modelo más barato hace el trabajo y consulta a uno más potente solo en decisiones difíciles: antes de elegir el rumbo, cuando se repite el mismo error y antes de decir que terminó. Activar advisor no rompe la caché de la sesión.

1. En una sesión con un modelo intermedio, activa advisor con el modelo potente.
2. Deja que el agente decida cuándo consultar.
3. Función experimental: comprueba si te conviene según tu plan.
4. Con una suscripción, suele ser más sencillo quedarse con un solo modelo.

El modelo, el esfuerzo, los permisos y el momento de compactar ya vienen ajustados para cada modelo. Quien cambia todo «para mejorarlo» suele empeorarlo.

1. Empieza con los valores predeterminados.
2. Cambia una configuración solo cuando algo salga mal y anota el motivo.
3. ¿Hiciste un cambio? Mide antes y después (el consejo 2 también sirve aquí).
4. Revisa lo que cambiaste hace meses: quizá ya no haga falta.

El modelo ya planifica bien sin el modo de planificación. Lo que sigue siendo útil es el plan para ti: definir el objetivo, los límites y qué significa terminar. Cambiar un plan cuesta mucho menos que deshacer cien líneas.

1. Trabajo grande o confuso: pídele al agente que te haga preguntas y guarde el plan en un archivo.
2. Empieza a construir en una sesión nueva, leyendo ese archivo.
3. Trabajo que cabe en un párrafo: omite el plan y escribe solo el objetivo, qué significa terminar y los límites.
4. ¿Quieres bloquear los cambios hasta aprobarlos? En ese caso, el modo de planificación todavía ayuda.

/goal hace que el agente continúe hasta cumplir una condición. Pero quien verifica solo lee la conversación: no abre archivos ni ejecuta pruebas. Si el agente dice «terminé», le cree.

1. Primero, pídele al agente un script de verificación con reglas objetivas (por ejemplo, checa.sh).
2. Escribe la condición con pruebas: «checa.sh pasa y muestras el resultado».
3. Incluye lo que no puede cambiar y un límite de iteraciones.
4. Ejemplo: /goal checa.sh pasa y el resultado aparece aquí; el modelo no cambia; detente después de 15 iteraciones.

El hook se ejecuta siempre en el momento adecuado, sin depender de la voluntad del modelo. Ahora puede ser un prompt o un agente: cuando Claude intenta detenerse, otro modelo revisa el trabajo y dice «puedes parar» o «no puedes, porque…». El motivo vuelve como la siguiente instrucción.

1. Pídele al propio Claude: «añade un hook de Stop que compruebe X antes de permitir que se detenga».
2. Tipo prompt: solo lee la conversación; es rápido y barato.
3. Tipo agente: abre archivos y verifica de verdad (experimental).
4. Úsalo para reglas que no pueden fallar: «nunca envíes correos al cliente; solo prepara borradores».

Tener espacio para un millón de tokens no significa recordarlo todo. Las pruebas de recuperación muestran que la precisión baja cuando se llena el contexto. Una ventana más grande también ofrece más espacio para perder detalles.

1. Guarda el contexto reutilizable en archivos pequeños, organizados en carpetas.
2. En CLAUDE.md, deja solo referencias: «para X, lee carpeta/x.md».
3. Trabajo largo: guarda un handoff, usa /clear y retómalo con /prime.
4. Usa /context para ver qué está ocupando espacio.

Un subagente empieza desde cero, recibe solo lo que le das y devuelve solo el resultado: así la conversación principal queda limpia. Un fork es una copia de la conversación: conoce todo lo que se dijo y aprovecha la misma caché. Claude ya elige entre los dos por su cuenta.

1. Tarea aislada (generar una imagen, buscar un dato): subagente.
2. Tarea paralela que necesita todo el historial: fork.
3. Deja que Claude elija; pide un fork solo cuando sepas que necesitas el historial.
4. Recuerda: es posible que el subagente no lea tu CLAUDE.md. Incluye las reglas en la solicitud.

Para una investigación en profundidad, Claude crea un flujo con varios agentes que buscan desde distintos ángulos, contrastan las fuentes y descartan lo que no se sostiene antes de mostrártelo.

1. Úsalo solo cuando la tarea lo requiera: investigación, comparación o verificación cruzada.
2. Primero, en /config, configura el tamaño del flujo como pequeño (menos de cinco agentes).
3. Define qué se considera una buena respuesta y qué fuentes se aceptan.
4. Comprueba el costo después de la primera ronda.

Las rutinas ejecutan Claude en la nube. Además de programarlas por horario, pueden iniciarse con una solicitud web o un evento de GitHub, como un pull request nuevo. Cualquier sistema que envíe una solicitud a la URL activa el agente.

1. Crea la rutina con un nombre, una solicitud, un repositorio y un activador.
2. Activador por API (compruébalo en tu versión): recibirás una URL y un token. Guarda el token como una contraseña.
3. Deja solo los conectores que use esta rutina.
4. Añade la verificación (consejos 9 y 10) antes de dejarla funcionar sola.

Cada tarea recibe una máquina en la nube. Puedes abrir varias, cerrar la laptop y ellas siguen trabajando. Después, recuperas la sesión completa en tu computadora.

1. Empieza con claude --cloud "descripción de la tarea".
2. Sigue el progreso desde el navegador o la aplicación.
3. Recupérala con claude --teleport.
4. Comprueba si tu plan reanuda la tarea automáticamente cuando se renueva el límite de uso: si es así, consumirá el siguiente período sin preguntar.