Mi flujo de 4 pasos con Claude Code: planear, construir, entender y continuar

El error más común al programar con IA es pedirle todo de golpe: "hazme el registro de usuarios con validación, el endpoint y las pruebas". Claude Code lo intenta, llena los huecos con supuestos y entrega mucho código que hay que revisar línea por línea para descubrir qué decidió por ti. Funciona mejor un flujo de trabajo con Claude Code por etapas: primero se decide, luego se construye, después se entiende lo construido y al final se deja todo listo para seguir. Sirve igual para frontend, backend, apps web, scripts o e-commerce.

Cada etapa usa una skill de Claude Code distinta. Una skill es una carpeta con un archivo SKILL.md de instrucciones que Claude carga cuando la llamas con /nombre. Este artículo no es una lista de skills: es el orden en que las uso y por qué. Si te interesa otra skill que cambia cómo trabaja Claude, también escribimos sobre Ponytail, que lo obliga a escribir menos código.

El ejemplo: un formulario de registro

Para que no quede en teoría, todo el artículo sigue un mismo caso: agregar a una app web un formulario de registro con validación en el frontend, un endpoint en el backend que crea la cuenta y pruebas automatizadas que cubran ambos. Es pequeño, pero toca las tres capas y tiene suficientes casos límite como para salir mal si nadie los piensa.

El flujo completo

El diagrama muestra cuatro etapas en fila, cada una con su skill y lo que entrega, y una flecha que regresa de la última a la primera:

1. Planear con /grill-me: todas las decisiones contestadas antes de escribir código.
2. Construir con /caveman: código y pruebas, con respuestas cortas.
3. Entender con /wait-what: puedes explicar el diff con tus palabras.
4. Continuar con /handoff: un resumen para abrir un chat nuevo, que vuelve a empezar en el paso 1 con la siguiente función.

Paso 1: planear con /grill-me

Qué hace

/grill-me, de Matt Pocock, cambia el orden de la conversación: en lugar de programar, Claude te entrevista una rama de decisión a la vez hasta que no queda nada ambiguo. El resultado es un plan con las reglas escritas, no un archivo con supuestos escondidos.

Cómo instalarla

npx skills@latest add mattpocock/skills

Cuando el instalador pregunte qué skills quieres, marca grill-me y también grilling: hoy grill-me solo llama a grilling, que es donde vive la entrevista. Para Claude Code, el README del repositorio ahora recomienda el plugin del marketplace oficial, que se actualiza solo e incluye las skills de Matt que usamos en este artículo, excepto claude-handoff:

claude plugin install mattpocock-skills@claude-plugins-official

Usa uno de los dos métodos, no ambos, o tendrás cada skill duplicada.

Las preguntas que hace en el ejemplo

/grill-me Quiero agregar un formulario de registro con validación,
un endpoint que cree la cuenta y pruebas automatizadas.

Estas son el tipo de preguntas que salen, agrupadas por tema:

• Campos: ¿nombre, correo y contraseña, o también teléfono? ¿Cuáles son obligatorios? ¿Hay que aceptar términos y condiciones?
• Reglas de validación: ¿longitud mínima de la contraseña? ¿Se valida el formato del correo solo en el navegador o también en el servidor? ¿La misma regla vive en un solo lugar?
• Manejo de errores: ¿qué ve el usuario si el correo ya existe? ¿Y si el servidor falla? ¿Se conservan los datos del formulario después de un error?
• Casos límite: ¿Ana@Mail.com y ana@mail.com son la misma cuenta? ¿Qué pasa con espacios al inicio o al final? ¿Y si alguien hace doble clic en "Crear cuenta"?
• Qué no debe romperse: ¿el inicio de sesión actual, las cuentas existentes, los eventos de analítica del formulario? ¿Qué pruebas ya existen y deben seguir pasando?

Cuando terminas de contestar, tienes las reglas por escrito. Ese texto es lo que le das a Claude en el paso 2.

Paso 2: construir con /caveman

Qué hace

Durante la construcción lees muchas respuestas de Claude, y la mayoría trae saludo, resumen y repetición de lo que pediste. Caveman, de Julius Brussee, le quita eso: frases cortas, la respuesta primero, y el código, los comandos y los errores intactos. Cuando hay una advertencia de seguridad o una acción irreversible, vuelve a escribir en frases completas.

Cómo instalarla

claude plugin marketplace add JuliusBrussee/caveman
claude plugin install caveman@caveman

En el ejemplo

Con el plan del paso 1, le pides a Claude que construya por partes: primero la validación, luego el endpoint, luego las pruebas. Una pieza clave del plan fue que la regla viva en un solo lugar y la usen el formulario y el endpoint:

type Signup = { email: string; password: string };

export function validateSignup({ email, password }: Signup) {
  const errors: Partial<Record<keyof Signup, string>> = {};
  const normalized = email.trim().toLowerCase();
  if (!/^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(normalized)) errors.email = "Correo no válido";
  if (password.length < 12) errors.password = "Mínimo 12 caracteres";
  return { normalized, errors };
}

Y cuando una prueba falla, en lugar de tres párrafos recibes algo así:

Test falla: endpoint compara email sin normalizar.
Usa normalized de validateSignup antes del lookup. Fix:

Cuánto ahorra de verdad

El ahorro de caveman es en tokens de salida, es decir, en lo que Claude escribe. La medición actual del propio proyecto, con diez preguntas de desarrollo en Claude Opus 5.5, da 6,983 tokens de salida sin ninguna instrucción, 4,119 con /caveman y 2,693 con /ultracave. El mismo README aclara que, frente a solo pedir "responde conciso", /caveman recorta 3% más y /ultracave 35% más, y que sus reglas cuestan unos 1,160 tokens de entrada.

En el costo total de una sesión el ahorro es menor que cualquiera de esos porcentajes, porque la mayor parte de lo que pagas es entrada: los archivos que Claude lee, la salida de los comandos y el historial de la conversación.

Cuándo no conviene

Cuando necesitas entender el porqué del código y no solo el qué. Si Claude toma una decisión de diseño que no esperabas, una respuesta de dos líneas no te la explica. Apágalo con stop caveman o pasa al paso 3. Tampoco conviene cuando Claude escribe para otra persona: documentación, la descripción de un PR o un correo.

Paso 3: entender con /wait-what

Qué hace

Si no entiendes el código que se va a quedar en tu proyecto, no lo terminaste. /wait-what, también de Matt Pocock, le dice a Claude que se detenga y vuelva a explicar su último mensaje con el contexto que te falta, en lenguaje simple. La skill pide inglés técnico simplificado (ASD-STE100); si lo quieres en español, agrégalo junto al comando.

Cómo instalarla

npx skills add mattpocock/skills --skill wait-what

Si instalaste el plugin de Matt en el paso 1, ya la tienes.

En el ejemplo: explicación confusa contra explicación clara

Le preguntas a Claude cómo maneja el endpoint un correo repetido y contesta:

"El handler normaliza el email antes del lookup para evitar colisiones por casing y devuelve 409 en conflicto para preservar la semántica del retry del cliente."

Todo es correcto, pero si no conoces esos términos no te dice nada. Escribes:

/wait-what en español, por favor

Y la respuesta queda así:

"Antes de buscar si el correo ya existe, el endpoint lo pasa a minúsculas y le quita los espacios. Así, Ana@Mail.com y ana@mail.com cuentan como la misma cuenta. Si ya existe, responde con el código 409, que significa conflicto, en lugar de un error 500. Con eso el formulario sabe que debe mostrar 'Ese correo ya tiene cuenta' y no 'Algo salió mal'."

Ahora sí puedes revisar el diff sabiendo qué buscar, y explicárselo a quien revise tu PR.

Paso 4: continuar con /handoff

Por qué hace falta

Después de planear, construir y revisar, la conversación ya es larga: el contexto está lleno, Claude empieza a olvidar decisiones del principio y cada respuesta cuesta más. Lo sano es abrir un chat nuevo para la siguiente función, por ejemplo la confirmación por correo, sin perder lo que ya se decidió.

claude-handoff, de Matt Pocock

claude-handoff escribe un resumen de la conversación y además lanza un agente en segundo plano con claude --bg que sigue el trabajo de inmediato. Está en desarrollo: no viene en el plugin y el autor avisa que puede cambiar o desaparecer sin aviso.

npx skills add mattpocock/skills --skill claude-handoff

Si prefieres algo estable, el plugin de Matt incluye handoff, que solo escribe el documento de traspaso en la carpeta temporal de tu sistema.

Alternativa: tu propia /handoff

Yo prefiero algo más simple: un resumen para copiar y pegar en un chat nuevo, sin archivos ni agentes. Crea ~/.claude/skills/handoff/SKILL.md con este contenido:

---
name: handoff
description: Resume la conversación actual en un bloque listo para pegar en un chat nuevo y continuar el trabajo.
argument-hint: "[en qué se va a enfocar el siguiente chat]"
disable-model-invocation: true
---

Escribe un resumen para continuar esta conversación en un chat nuevo.
No crees archivos ni lances agentes: entrega el resumen en un solo bloque
de código para que el usuario lo copie.

Incluye, en este orden:

1. Objetivo: qué estamos haciendo y para qué, en dos frases.
2. Estado: qué ya está hecho y comprobado, y qué no.
3. Decisiones: lo que ya se decidió y por qué, para no volver a discutirlo.
4. Archivos y comandos: rutas, ramas y comandos relevantes, tal cual.
5. Siguiente paso: la próxima acción concreta.
6. Pendientes: dudas abiertas y cosas que no se comprobaron.

Reglas:

- Máximo 300 palabras.
- No copies código que ya está en archivos; menciona la ruta.
- Quita claves de API, contraseñas y datos personales.
- Si el usuario pasó argumentos, enfoca el resumen en eso.

La línea disable-model-invocation: true hace que solo se active cuando escribes /handoff. Claude Code detecta la skill nueva sin reiniciar; si la carpeta skills no existía cuando abriste la sesión, ejecuta /reload-skills.

En el ejemplo, el resumen diría que el registro ya valida en el formulario y en el endpoint con la misma función, que el correo se normaliza, que un correo repetido responde 409, qué pruebas pasan y que el siguiente paso es la confirmación por correo. Lo pegas en un chat nuevo y vuelves al paso 1.

Cómo se adapta a tu tipo de proyecto

Frontend

En el paso 1, las preguntas se van a estados y accesibilidad: carga, error, vacío, foco después de enviar, mensajes de error asociados a cada campo. En el paso 3, /wait-what sirve mucho con efectos y renders inesperados, que es donde una explicación corta suele quedarse corta.

Backend

El paso 1 cubre contratos y fallos: qué devuelve el endpoint en cada caso, qué pasa con peticiones duplicadas, qué cambia en la base de datos y cómo se revierte. En el paso 2, pide primero las pruebas del contrato y luego la implementación.

E-commerce

En un tema de Shopify, el paso 1 pregunta qué settings y bloques necesita la sección, qué debe poder editar el comerciante y qué no debe romperse: el checkout, los eventos de analítica y las secciones que ya usa la tienda. En el paso 2, valida cada cambio con shopify theme check y prueba en local con shopify theme dev antes de subir nada.

Checklist para tu siguiente proyecto

Copia esto en tus notas o en la descripción de tu tarea:

[ ] 1. Planear: /grill-me hasta que no queden preguntas abiertas
[ ]    Reglas, errores, casos límite y "qué no debe romperse" por escrito
[ ] 2. Construir: /caveman, por partes y con pruebas en cada parte
[ ]    Correr las pruebas y el linter después de cada parte
[ ] 3. Entender: /wait-what sobre cualquier decisión que no puedas explicar
[ ]    Revisar el diff completo antes de aceptarlo
[ ] 4. Continuar: /handoff y abrir un chat nuevo para la siguiente función

Preguntas frecuentes

¿Tengo que usar las cuatro skills siempre?

No. En un cambio pequeño y claro puedes saltarte el paso 1, y en una sesión corta no necesitas el paso 4. El orden es lo importante: no construyas sin haber decidido, y no aceptes código que no entiendes.

¿Funciona con cualquier lenguaje o framework?

Sí. Las skills cambian cómo trabaja Claude, no el código que genera. El mismo flujo sirve para una app de React, una API en Python, un script de automatización o un tema de Shopify.

¿Las skills gastan tokens aunque no las use?

Poco. El nombre y la descripción ocupan algo de contexto para que Claude sepa que existen, y el contenido completo solo se carga cuando las usas. Caveman, que cambia el estilo de toda la sesión, sí tiene un costo fijo de unos 1,160 tokens de entrada según su propio README.

¿Dónde se guardan las skills que instalo?

Las tuyas van en ~/.claude/skills/<nombre>/SKILL.md para todos tus proyectos, o en .claude/skills/<nombre>/SKILL.md para un solo repositorio. npx skills instala en el proyecto actual por defecto; agrega -g para todos tus proyectos. Los plugins los administra Claude Code.

¿Es seguro instalar skills de otras personas?

Tanto como cualquier código que ejecutas: una skill le dice a Claude qué hacer con tus permisos. Lee el SKILL.md antes de instalarla y usa solo el repositorio oficial de su autor.

Sigue aprendiendo

Publico tips cortos de Claude Code, Shopify y desarrollo web en Instagram. Sígueme en @lgmdevtl para ver este flujo funcionando en video.